The Road to CouchDB 3.0: Introducing Partitions to CouchDB for More Efficient Querying

This is a post in a series about the Apache CouchDB 3.0 release. Check out the other posts in this series.

Apache CouchDB 3.0 comes equipped with a new partitioned database feature, offering  more performant, scalable, and efficient querying of secondary indexes.

Users decide, at database creation time, whether or not to create the database with partitions. All documents in a partitioned database require a partition key, and all documents within a partition are grouped together. Common partition keys could include usernames, IoT device IDs, or locations. Partitioned database documents also have an _id field, but the _id field is in two parts, the partition key and the document key, separated by a “:” character:

Querying against a secondary index for a partition scans only the specified partition range within a single shard.  Compared against a “global” query that requires collating the results of reading a copy of every shard, partition queries require much fewer resources and respond faster at scale. To visualize the difference in database operations, compare a global query on left with a partition query on right:

Querying a partitioned database with a partition key can be done against the Primary Index (_all_docs), as well as a MapReduce view, Search (now available in Apache CouchDB 3.0), or Mango index. Users can combine both partitioned and global indexes within the same database to meet their querying requirements. 

For more information on leveraging Partitioned Databases in Apache CouchDB, check out the following resources: 

One thought on “The Road to CouchDB 3.0: Introducing Partitions to CouchDB for More Efficient Querying

  1. The Road to CouchDB 3.0 – CouchDB Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s