{"id":1500,"date":"2014-12-16T16:54:23","date_gmt":"2014-12-16T16:54:23","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=1500"},"modified":"2025-06-13T23:52:05","modified_gmt":"2025-06-14T06:52:05","slug":"10-things-developers-should-know-about-couchbase","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/10-things-developers-should-know-about-couchbase\/","title":{"rendered":"10 Things Developers Should Know about Couchbase"},"content":{"rendered":"

As a developer, I\u2019ve been using Couchbase Server for couple of months now and I love it. Having written several apps myself, I\u2019ve come to learn many (but not all) of the ins-and-outs of Couchbase. To be a good Couchbase developer, it\u2019s not just enough to know how to use the API\u2019s – it takes a little bit more.<\/p>\n

To give you a quick overview of what developers can get out of Couchbase we\u2019ve put together this Top 10<\/strong> list of things you should know. These are in no particular order but it\u2019s a good collection of information you should know if you\u2019re building your app with Couchbase.<\/p>\n

Here we go…<\/p>\n

#10<\/strong>. <\/strong>Document access in Couchbase is strongly consistent, query access is eventually consistent<\/strong><\/p>\n

Couchbase guarantees strong consistency by making sure that all reads and writes for a particular document go to a single node in a cluster. This is for document (key \/ value ) access. Views are eventually eventually consistent compared to the underlying stored documents.<\/p>\n

#9<\/strong>. Writes are asynchronous by default but can be controlled <\/strong><\/p>\n

By default, writes in Couchbase are async – replication and persistence happen in the background, and the client is notified of a success or failure. The updates are stored in memory, and are flushed to disk and replicated to other Couchbase nodes asynchronously.<\/p>\n

Using the APIs with durability constraints within the application, you can choose to have the update replicated to other nodes or persisted to disk, before the client responds back to the app.<\/p>\n

#8.<\/strong> Couchbase has atomic operations for counting and appending<\/strong><\/p>\n

Couchbase supports atomic incr\/decr and append operations for blobs.<\/p>\n

For example:<\/em><\/strong><\/p>\n

cb.set(“mykey”, 1)
\nx = cb.incr(“mykey”)
\nputs x #=> 2<\/p>\n

incr is both writing and returning the resulting value.<\/p>\n

The update operation occurs on the server and is provided at the protocol level. This means that it is atomic on the cluster, and executed by the server. Instead of a two-stage operation, it is a single atomic operation.<\/p>\n

#7.<\/strong> Start with everything in one bucket<\/strong><\/p>\n

A bucket is equivalent to a database. You store objects of different characteristics or attributes in the same bucket. So if you are moving from a RDBMS, you should store records from multiple tables in a single bucket.<\/p>\n

Remember to create a \u201ctype\u201d attribute that will help you differentiate the various objects stored in the bucket and create indexes on them.\u00a0It is recommended to start with one bucket and grow to more buckets when necessary.<\/p>\n

#6.<\/strong> Try to use 5 or less buckets in Couchbase. Never more than 10.<\/strong><\/p>\n

Documents don\u2019t have a fixed schema, multiple documents with different schema can be in the same bucket. Most deployments have a low number of buckets (usually 2 or 3) and only a few upwards of 5. Although there is no hard limit in the software, the max of 10 buckets comes from some known CPU and disk IO overhead of the persistence engine and the fact that we allocate specific amount of memory to each bucket. We certainly plan to reduce this overhead with future releases, but that still wouldn’t change our recommendation of only having a few buckets.<\/p>\n

#5.<\/strong> Use CAS over GetL almost always<\/strong><\/p>\n

Optimistic or pessimistic locking, which one should you pick?<\/a> If your app needs locking, first consider using CAS(optimistic locking<\/a>) before using GetL (pessimistic locking).<\/p>\n

But remember, locking might not be good for all cases – your application can have a problem if there is a lock contention. A thread can hold a lock and be de-scheduled by the OS. Then all the threads that want to acquire this lock will be blocked. One option is to avoid locking altogether where possible by using atomic operations. These API’s can be very helpful on heavily contested data.<\/p>\n

#4. <\/strong>Use multi-get operations<\/strong><\/p>\n

Once your client application has a list of document IDs, the highest performance approach to retrieve items in bulk using a multi-GET request. This performs better than a serial loop that tries to GET for each item individually and sequentially.<\/p>\n

#3.<\/strong> Keep your client libraries up-to-date <\/strong><\/p>\n

Make sure that you\u2019re using the most recent client library. Couchbase client libraries are available in Java, .NET, C\/C++, Ruby, Python and PHP.<\/p>\n

#2. <\/strong>Model your data using JSON documents<\/strong><\/p>\n

Couchbase Server supports JSON and binary document format. First, try modeling your data using JSON. JSON documents can be indexed and queried. You can store binary blobs and range query off of the key names. Start by creating documents from application-level objects. Documents that grow continuously or under high write contention should be split.<\/p>\n

#1.<\/strong> Use indexes effectively<\/strong><\/a><\/p>\n

Use primary key access as much as possible. Couchbase has keys and metadata in memory – data accesses are fast. Use secondary indexes for less performance sensitive paths or for analytics. Start with 4 design documents and less than 10 views per design document. Create a few \u201clong\u201d indexes that can be used for multiple queries and use creative filtering. Construct indexes to \u201cemit\u201d the smallest amount of data possible: use \u201cnull\u201d for value if you do not have any reduce function.<\/p>\n

Just 10 things? <\/strong>No, of course not! Couchbase is a NoSQL database system and after you try it you will find that there\u2019s a lot more you will learn. If you feel that I missed something important that should be added in the top 10 list, feel free to add them using the comments below.<\/p>\n

Enjoy!<\/p>\n

Related Links<\/strong><\/p>\n