CouchDB essentials

“Each node in a system should be able to make decisions purely based on local state. If you need to do something under high load with failures occurring and you need to reach agreement, you’re lost… If you’re concerned about scalability, any algorithm that forces you to run agreement will eventually become your bottleneck. Take that as a given.”

— Werner Vogels, Amazon CTO and Vice President

 

 

Local Consistency

The Key to Your Data

At the heart of CouchDB is a powerful B-Tree storage engine. A B-Tree is a sorted data structure that allows for searches, insertions, and deletions in logarithmic time. As Figure 2-2 illustrates, CouchDB uses this B-Tree storage engine for all internal data, documents, and views. If we understand one, we will understand them all.

Anatomy of a View Request

 

Distributed Consistency

You could use multi-master, master/slave, partitioning, sharding, write-through caches, and all sorts of other complex techniques.

 

Incremental Replication

Because CouchDB operations take place within the context of a single document, if you want to use two database nodes you no longer have to worry about them staying in constant communication. CouchDB achieves eventual consistency between databases by using incremental replication, a process where document changes are periodically copied between servers. We are able to build what’s known as a shared nothing cluster of databases where each node is independent and self-sufficient, leaving no single point of contention across the system.