Do you know – Couchbase Things! #1

Table of contents
Reading Time: 2 minutes

Every database is viewed from different perspectives like the developer, DBA. So, in this blog I am sharing some of my learning related to couchbase, or I will say some facts that developers should know.

1) It is possible to run a query in Couchbase without index.

Yes! you have read it right. We can query without index using the USE KEY Clause. It simply fetches the document on the basis of document Id. So, if you are already aware of the document key that you want to fetch. Go with USE KEY. You can simply query like below:

select * from employee USE KEYS “emp::1”

If you see the execution plan for the above query, there will be no index scan takes place.

image (7)


Consider a scenario where you have to fetch data by key while using couchbase as DB in your app. So, definitely, you will go for USE KEYS because of no headache of creating the index. Right?  But just give a thought about the execution plan.
If you take the use keys path, then you are doing this:
app —> query service —> data service
But, if you take the key-value retrieval path, then you are doing this:
app —> data service
So, the second one is much faster. Isn’t it?

3) Use 5 or fewer buckets.

Comparing  RDBMS with couchbase, the bucket is always equivalent to a database. So, start everything with 1 bucket. And if you have such a use case where you require multiple buckets. Always try to use 5 or less or it is always advisable to never go beyond 10.

4) Use type attribute in the document.

As couchbase is so flexible to store any type of document. But it is always advisable to store one extra field in a document that is the type which helps you to distinguish from other types of documents.
For example docType in the following example highlights that we are storing student’s data.

“lastName”: “Sharma”,
“rollNumber”: “141272”,
b”firstName”: “Bhawna”,
“emailAddress”: “”,
“stream”: “Science”

5) Use the index effectively

Performance, Performance, and Performance!
Always keep one thing in mind, if you really need performance, create the right index.
Always go with the secondary index in production as it takes up less space and more efficient. But it does mean that the primary index is of no use. We can use the primary index for the FULL TABLE SCAN or for the situation where we know the range of document keys that we want to scan. For more details visit here

I hope this is helpful. Please feel free to provide your suggestions. 🙂