1

our web architecture is based on commercial products both for in memory caching and the relational backend database.

In the context of investigating moving the web stack into the cloud, we are looking at Couchbase both for the caching layer (which would also sit in the cloud, next to the apps) as well as potentially replacing the internal database with Couchbase as a document oriented NoSQL database (at least for the read portion).

That would mean that we would have to make the following changes:

  1. Asymmetric read/write...the apps would always read from the cache but write to the backend systems of record (read >> write). The backend systems of record would then update the internal NoSQL database which in turn would populate the cache
  2. Implement read through cache....apps in the cloud would always talk to the in memory caching layer (including XCDR). if objects are not found in the cache, the cache should automatically retrieve data from the internal backend couchbase db, without the application code being aware of it (not a side cache)

So, my questions are:

  1. Is having a cloud based caching layer plus a NoSQL internal backend database a valid pattern ?
  2. Is it possible to implement a read through cache with Couchbase, i.e. the CB caching layer would transparently retrieve the data from the backend db if not found in the cache ? If yes, what kind of backends would be supported for that (relational db's, NoSQL, couchbase itself)
  3. Regardless of whether implementing a side cache (i.e. the apps first talk to the cache and then to the backend) or a read through cache (i.e. the apps talk to the cache, and the cache talks to the backend), how to expose the couchbase data manipulation API via HTTP, or is it recommended to use the couchbase SDK even across WAN links (in terms of latency) ? How does the memcached API play into this ?

thx Nick

Improve this question

1 Answer 1

Reset to default
1

have a few questions and comments: For q#1, I'd question why you need a cache when you have couchbase already. given it can scale out and cache aggresively if you want that, what would a caching tier next to couchbase buys you? For #2, couchbase does not have a transperant auto population/write-through facility. your app would need to do that. For #3, SDKs give you the best option here. Couchbase has compatibility with memcached APIs but using the SDKs you would tap into the full power of couchbase with additional facilities natively available to you.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

sry, wasn't talking about the cache sitting next to the db, but the cache being co-located with the apps in the cloud while the actual backend db sits within our own dc (private cloud). Given that CB doesn't allow for a side cache, that means (in case of a cache miss) that the apps need to retrieve the data from the internal backend db. As the backend db sits behind the firewall, I don't see how the cloud web app could connect to it via the sdk using couchbase port 11210 (don't really want to poke holes into the firewall). I guess, a REST API would come handy.
to add to this: the actual "systems of record" for our key data items are vertical packaged apps "owning" just a subset of the data each. So in order to have an integrated data layer, data needs to be replicated from all these "systems of record" (think SAP, Siebel etc.) into a single integrated data store. For various reasons (security, shared usage by internal apps), this integrated data store needs to sit inside our firewall. But of course, we don't want our geo distributed web apps to call back home to our data center for every read (hence the couchbase caching layer in the cloud)

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.