Our development team has implemented Couchbase transactions in our application. During a discussion, a question came up regarding how KV operations are handled under a transaction.
Specifically, suppose we have two KV operations inside a single transaction:
The client performs the first KV operation (e.g., insert/update).
Then the client performs another KV operation in the same transaction.
In RDBMS systems, since both statements are wrapped in a single transaction, we typically don’t think of these as two separate calls to the database — they are considered part of the same transactional context until commit/rollback.
Our question:
In Couchbase, do these KV operations still result in separate calls to the server (one per KV operation)?
Or does Couchbase handle them internally in a way similar to RDBMS, where the operations are buffered until commit?
We’d like to confirm our understanding so that we can properly estimate performance and network overhead when using Couchbase transactions.
It will be separate network calls. One per document to stage them, one per document to unstage them (after the atomic commit).
This is a good thing as it means the SDKs leverage your full Couchbase cluster, sending network calls to the nodes that own each document. Our transactions are designed to be highly distributed in nature, which also means you can do your KV mutations operations in parallel.
We’d like to confirm our understanding so that we can properly estimate performance and network overhead when using Couchbase transactions.
That is going to be extremely difficult, as it depends on the operations in the transaction, the size of the documents, the client, the cluster, the network topology, the speed of the network and ,the load on the network. I would think it would easier, faster and more accurate to collect the actual time by calling System.currentTimeMillis() before and after the execution of the transaction.
That is not the case. In the example. in Table 12-1, there are four database round-trips (t9 through t12) for transaction sal_update2Transactions
Thanks @graham.pople .If two KV operations occur in one transaction, performing two network calls to the CB server will be costly since it requires two network trips instead of one. Please correct me if I am wrong.
Can you share some documents where we will clarify our theory.
@Debasis_Mallick it’s a tradeoff you’ll need to decide on, as ACID guarantees don’t come for free and there is indeed some additional cost to performing writes transactionally. For highest performance we would recommend using non-transactional writes wherever you can, and structuring your data around those lines. JSON is a rich data model that can allow you to avoid mutating multiple documents for one operation when you would need to in an RDBMS. E.g. use transactions only when you need to, not as the default option.
In terms of documents, not sure exactly what you require but a good starting point is the documentation:
Thanks everyone for clarification. Our DEV team had one concern that , KV ops under transactions are slower than the same KV ops without transaction. Could you please help us to understand this behavior.
This will be true of any system that has transactions. In many cases it is possible to use non-transactional optimistic locking via CAS to satisfy concurrency requirements without a performance penalty.
Nb do note that KV ops inside are transactions are always performed with Durability | Couchbase Docs , which is a crucial part of the ACID guarantees. Durability can be used with non-transactional KV ops also.