![](https://csdnimg.cn/release/download_crawler_static/9625431/bg10.jpg)
Apache CouchDB, Release 2.0.0-git
Can you really use CouchDB on a phone? Erlang, CouchDB’s implementation language has been designed to run
on embedded devices magnitudes smaller and less powerful than today’s phones.
1.2.7 Wrapping Up
The next document Eventual Consistency further explores the distributed nature of CouchDB. We should have
given you enough bites to whet your interest. Let’s go!
1.3 Eventual Consistency
In the previous document Why CouchDB?, we saw that CouchDB’s flexibility allows us to evolve our data as our
applications grow and change. In this topic, we’ll explore how working “with the grain” of CouchDB promotes
simplicity in our applications and helps us naturally build scalable, distributed systems.
1.3.1 Working with the Grain
A distributed system is a system that operates robustly over a wide network. A particular feature of network
computing is that network links can potentially disappear, and there are plenty of strategies for managing this type
of network segmentation. CouchDB differs from others by accepting eventual consistency, as opposed to putting
absolute consistency ahead of raw availability, like RDBMS or Paxos. What these systems have in common is an
awareness that data acts differently when many people are accessing it simultaneously. Their approaches differ
when it comes to which aspects of consistency, availability, or partition tolerance they prioritize.
Engineering distributed systems is tricky. Many of the caveats and “gotchas” you will face over time aren’t
immediately obvious. We don’t have all the solutions, and CouchDB isn’t a panacea, but when you work with
CouchDB’s grain rather than against it, the path of least resistance leads you to naturally scalable applications.
Of course, building a distributed system is only the beginning. A website with a database that is available only
half the time is next to worthless. Unfortunately, the traditional relational database approach to consistency makes
it very easy for application programmers to rely on global state, global clocks, and other high availability no-nos,
without even realizing that they’re doing so. Before examining how CouchDB promotes scalability, we’ll look
at the constraints faced by a distributed system. After we’ve seen the problems that arise when parts of your
application can’t rely on being in constant contact with each other, we’ll see that CouchDB provides an intuitive
and useful way for modeling applications around high availability.
1.3.2 The CAP Theorem
The CAP theorem describes a few different strategies for distributing application logic across networks.
CouchDB’s solution uses replication to propagate application changes across participating nodes. This is a fun-
damentally different approach from consensus algorithms and relational databases, which operate at different
intersections of consistency, availability, and partition tolerance.
The CAP theorem, shown in Figure 1. The CAP theorem, identifies three distinct concerns:
• Consistency: All database clients see the same data, even with concurrent updates.
• Availability: All database clients are able to access some version of the data.
• Partition tolerance: The database can be split over multiple servers.
Pick two.
When a system grows large enough that a single database node is unable to handle the load placed on it, a sensible
solution is to add more servers. When we add nodes, we have to start thinking about how to partition data between
them. Do we have a few databases that share exactly the same data? Do we put different sets of data on different
database servers? Do we let only certain database servers write data and let others handle the reads?
10 Chapter 1. Introduction