What is the standard deployment strategy for application and Couchbase?
In the RDBMS world usually the application sits on it’s own physical machine and the database on a separate physical machine. In RDBMS world stored procedures are usually used by the application to make one call to reduce network calls.
In Couchebase if an application requires to execute multiple operations it requires multiple network calls. Doesn’t this go against the whole premise of in-memory and the speed of Couchbase? Do people usually deploy their app with the Couchbase db on same machine to avoid the network calls?
Couchbase is very different than RDBMS architecture in so many ways. Our Client SDK’s retain persistent binary socket connections to each node of Couchbase in the cluster and send operations across the wire. While RDBMS operations tend to be heavy and compute intensive due to Normalization, CRUD operations on Couchbase aren’t nearly as burdensome (even that is being conservative, it’s more like a tiny fraction of the compute), and as such, having multiple operations in series or parallel is quite the norm.
A CRUD operation is a binary packet going directly to a particular node of Couchbase in the cluster, which then create/retrieve/update/delete the document value from RAM (basically a hash) on the corresponding node and return the result. No real computation needed for that, unlike JOIN’s.
I recommend the training-webinars at http://www.couchbase.com/training-webinars if you haven’t watched them.
Ok cool. I figure if I need to do different calculation based on same key I can always use RX or when.java or something to send queries in parallel.
CRUD operations are handled asynchronously under the hood in the Client SDK’s so you generally don’t have to worry about this on your end. In the Java Client you can decide in your app code whether to block or not as well, but underneath that of course it doesn’t block.
Ah cool I was referring to the fact that I want to query different views using the same key in parallel.