CouchDB与关系数据库中的分布式一致性？

Question

From CouchDB guide :

Maintaining consistency within a single database node is relatively easy for most databases. The real problems start to surface when you try to maintain consistency between multiple database servers. If a client makes a write operation on server A, how do we make sure that this is consistent with server B, or C, or D? For relational databases, this is a very complex problem with entire books devoted to its solution. You could use multi-master, master/slave, partitioning, sharding, write-through caches, and all sorts of other complex techniques.

Why is it hard to maintain consistency between the database server in a relational model? And why is CouchDB approach simpler and easier?

Answer 1

Couch simplifies it in two ways.

First, it has a higher level replication model built in and enforced by the system.

Second, it's data elements are coarser, giving the optimistic locking and conflict resolutions models less to work with.

As a general rule, RDBMSs do not natively support optimistic locking. Many frameworks built on top of them do, but not the DBMSs themselves. Some may support it internally, but if they do, it's not exposed to the end users.

Couch supports optimistic locking/versioning intrinsically, and relies up this for its replication.

In a RDBMS, most larger order data items are broken up in to their normalized, relational components. A simple order may well be composed of a half dozen tables, each with their own row structure. But the combination of tables and their relationships are what make up "an order". Given this finer grain representation of the order, it's difficult for the database to capture the concept of "change" at the higher level. What does "an order changed" mean? The database sees a collection of nodes and relationships, not higher order meta objects like "orders".

The application can define change, but not as readily the database.

Now this is not so much an issue if you're replicating the entire database, but it's significantly more complicated if you're replicating a portion of the database.

In Couch, an order, for example, is an entire document. Change the document, and the entire order "changes", and thus the entire order is replicated. In a RDBMS, if a line item changed, then it's easy enough to detect that one line changed, but does that mean the "order" changed? What if an item that the order is referring to changed, does that change the order? You can see how this gets more complicated.

All of this can be built on top of the RDBMS, but then it's the application doing change management and facilitating replication, not the database.

However, no matter what support CouchDB offers, it can only goes so far, and that caveat is highlighted in the quote:

When two versions of a document conflict during replication, the winning version is saved as the most recent version in the document's history. Instead of throwing the losing version away, as you might expect, CouchDB saves this as a previous version in the document's history, so that you can access it if you need to. This happens automatically and consistently, so both databases will make exactly the same choice.

It is up to you to handle conflicts in a way that makes sense for your application. You can leave the chosen document versions in place, revert to the older version, or try to merge the two versions and save the result.

During replication, Couch simply has deterministic rules to make two systems consistent. But consistent doesn't make them correct. When Couch detects two documents in conflict, it picks one, deterministically, and the winner stomps on the loser. But as far as your application is concerned, the loser may have been "right", or the correct document is the fusion of the two documents.

You have to write that logic handle those merges. And this is a fundamental issue with all master-master replication schemes. The technique to determine "who wins". The "now what" problem when to different opinions on what the data should look like arrive at the same crossroads.

No system can handle that for you. All a system can do is pick some set of rules it follows, or lets you configure to handle the problem, because the problem is almost always application dependent.

If the simpler model that Couch supports and projects for you works, then that's great. If it doesn't, then you're kind of stuck. Many RDBMSs have solid support for Master-Slave replication, as it's a simpler model, and with that support it's pretty much transparent to the end user application.