“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
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
You could use multi-master, master/slave, partitioning, sharding, write-through caches, and all sorts of other complex techniques.
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.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。