Best Practices
Speed up your application development, with some best practices for using Couchbase SDKs.
From batching and reactive APIs, to unit tests and handling errors. There’s plenty that can be done to remove bottlenecks in development and in performance, and this page can be your checklist of areas not to neglect as you develop your app.
Performance
Couchbase’s Data Service uses a fast binary protocol, which will always outperform JSON streamed over HTTP from SQL++ queries. If you know the key (ID) of a document, then use the Data Service.
If you need pessimistic logging, in particular if you need to lock documents for multi-document ACID transactions, then anything you can do at the schema level to reduce the number of documents locked simultaneously wil remvoe a bottleneck to updating the affected documents.
Dealing with Timeout Errors
-
LAN-type connection of client and server is recommended in production, but WAN development is a reality pre-production. Ensure that you’re familiar with the best timeout options for WAN environments, or at least set a WAN development Configuration Profile.
Concurrency and Async APIs
See the Async & Reactive APIs page for practical examples.
Bulk Get, Multi-Get, and Network Latency
In traditional databases, a bulk get or multi-get is often an efficient way of overcoming network latencies as a bottleneck, or simply making more efficent use of your database’s performance.
Couchbase is a distributed database, efficiently fetching data from vbuckets spread across several nodes: bulk gets can be an anti-pattern, holding things up on the Server side, compared with the efficiency of fetching your data asynchronously. However, this depends upon your platform language’s availability of asynchronous APIs — see the bulk get and async API page for the specifics for the C++ SDK.
When to Use Bulk Get
As stated above, bulk gets are rarely the best way to fetch data from different documents efficently. Nevertheless, if your business logic dictates that all of, say five, results need to be returned before processing for the application’s next step, then a bulk get will give you all of the results together, as needed by your app. For this reason we do provide a batching example for the C++ SDK.
Error Handling
Best practices for error handling in C++ depend somewhat upon your choice of API: future, or callback based, as covered in the async and reactive API guide. That guide also covers how errors are actually returned and handled. Your application should always check if an operation returned an error, and potentially handle any specific error codes that may have returned. See also the error handling guide, which covers specific errors, along with a broader look at error handling strategies.
Threshold & Orphan Logging
Observability is provided by the SDK in the following ways:
Threshold Logging
Threshold logging is the recording of slow operations — useful for diagnosing when and where problems occur in a distributed environment. It is enabled by default.
You will see this information turning up in the logs something like this:
Threshold Log: {"service":"kv","count":2,"top":[{"operation_name":"Insert","total_us":161679},{"operation_name":"Upsert","total_us":161451}]}And as tracing values such as total_us, the duration of the total time taken for the operation, expressed as microseconds.