Cassandra How to handle database latency issues across data centers

The reliability, delay and consistency of the distributed system are general problems, not limited to the database, and Cassandra provides a good solution to the problem.

Cassandra claims to be able to achieve the efficient access to database access across data centers, and it is implemented in a way that gives users the tradeoff between latency, throughput, and consistency. Cassandra provides two levels of access: Local_quorum and Each_quorum, where

• Local_quorum can be semantically executed successfully for more than half of the replicas in this data center before returning to the user operation successfully;
• Each_quorum semantics for each data center more than half of the copy executed successfully, only to return the user operation success;

So it is not difficult to imagine Each_quorum because of the need for cross-datacenter access, so the delay will be very large, and bandwidth, throughput corresponding performance will be reduced.

---------------ref:http://www.packtpub.com/article/apache-cassandra-working-multiple-datacenter-environments

Quorum operations in Multi-datacenter environments

Most applications use Cassandra for IT capability to perform low-latency read and write operations. When a cluster was all located with a single physical location, the network latency was low and bandwidth does not (typically) Has a cost. However, when a cluster is spread across different geographical locations, latency and bandwidth costs be factors that NE Ed to is considered. Cassandra offers, consistency levels:local_quorum and Each_quroum. This recipe shows how to use these consistency levels.

Getting Ready

The consistency levels Local_quorum and Each_quorum only work when using a datacenter-aware strategy such as the Networkto Pologystrategy. See the recipe Scripting a multiple datacenter installation for information on setting up that environment.

READ. Local_quorum returns the record with the most recent timestamp once a majority of replicas within the local datacenter hav E replied.
READ. Each_quorum returns the record with the most recent timestamp once a majority of replicas within each datacenter has REPL Ied.
WRITE. Local_quorum ensures that the write have been written to <ReplicationFactor>/2 + 1 nodes within the local Datacente R (Requires network topology strategy).
WRITE. Each_quorum ensures that the write have been written to <ReplicationFactor>/2 + 1 nodes in each datacenter (require s network topology strategy).

How it works ...

Each datacenter-aware level offers tradeoffs versus non-datacenter-aware levels. For example, reading at quorum in a multi-datacenter configuration would has to wait for a QUORUM of nodes Acro SS several datacenters to respond before returning a result to the client. Since requests across a WAN link could has high latency (40ms and higher), this might is acceptable for a applicatio n that returns results to the clients quickly. Those clients can use local_quorum for a stronger read then one while not causing excess delay. The same can said for write operations At local_quorum, although it's important to point out that writes was Gene Rally faster than reads.

It is also important to note how these modes react in the face of the network failures. Each_ Quorumwill only succeed if each datacenter are reachable and QUORUM can be established in each. Local_quorum can continue serving requests even with the complete failure of a datacenter.

Ref:http://www.datastax.com/docs/0.7/operations/datacenter

---------------------------------------------

There is no doubt that when using each_quorum, the consistency of global data can be ensured;

However, how do you ensure global data consistency when using Local_quorum? For example, two datacenter "at the same time" (in short enough time) to write a piece of data, it is likely that data conflicts.

• Of course, it can be allowed to write inconsistent, while reading to resolve the conflict. Amazon Web server is said to be doing this (without a fancy, but their scenario is likely to do so). Reading is also a read operation with these two levels of consistency. When inconsistencies are found, the inconsistent resolution of the data is thrown to the user for resolution, or the conflict is resolved by the time stamp written, the level of the writer, or other criteria of judgment.
• In addition, we can assume that the written user is geographically localized. That is, most of the writes are written from some datacenter, and occasionally a small portion is written from other datacenter, so as long as we redirect all writes to a datacenter, the consistency problem is resolved. This method is to sacrifice the "small" user performance, so as to achieve the overall performance maximization;

As an example of DataStax enterprise:

The required end result is for users in the US to contact one datacenter while UK users contact another to lower end-user Latency. An additional requirement are for both of these datacenters to being a part of the same cluster to lower operational costs. This can is handled using the following rules:

• When reading and writing are datacenter, ensure that the clients the users connect to can only see one datacenter, b ased on the list of IPs provided to the client.
• If doing reads at QUORUM, ensure that local_quorum are being used and not each_quorum since this latency would affect the EN D user ' s performance experience.
• Depending on what consistent you want your datacenters to be, the choose to run repair operations (without THE-PR Opti On) more frequently than the required once per gc_grace_seconds.

ref:http://planetcassandra.org/blog/post/datastax-developer-blog-multi-datacenter-replication-in-cassandra/

----------------------------

The above is written in the case, when read, in fact, is a similar processing. Cassandra also provides two levels of Local_quorum and each_quorum for read operations, and is similar for these two level definitions. There is a consistency problem with read operations because each datacenter is asynchronously replicated, so a time window (a few seconds) after the data is updated, the data read from different datacenter may not be the same, so consistency level requirements are required. In general, in the case of DataStax, they say "reading and writing" are fixed to a datacenter.

If you have seen Google's Spaner, you will find that although Google used atomic clocks such a tall tool, the delay of writing "slightly" down some, but, the same reason, it also provides a lot of space for the user configuration, such as the selection of the nearest user datacenter, say " Most "copies are placed closest to" most "users. I boil it down to, no matter how powerful, can not exceed the speed limit.