Riak-Background (3)

Distributed high-availability key-value pairs database Riak-background (3) Dynamo handling of data versions

The problem of data versioning is not only in distributed systems, but in a simple discussion of distributed database systems. Let's look at a simple example where user X does a write to the Key1, and we set the value to be the number 3. Then user Y reads the key1, and this time user Y knows the value is 3. Then User X does a +1 operation on the value, writes the new value, and now the value of Key1 is 4. and user Y also did a +1 operation, and then write, because user Y read the value is 3,y do not know that the value has now changed, the result according to semantics should be 5 of the value, now or 4.
The common way to solve this problem is to set a version value. User X writes Key1 value 3 for the first time, producing a version set to V1. The information that user Y reads includes version number v1. When x does add 1 to the value of 4 write, tell the server to get the version v1, to the V1 based on the value of the change to 4. The server found that the version it saved was V1, so I agreed to the write and changed the version to V2. This time Y also writes 4, and declares itself to be a modification made on version v1. However, because the server found that it was already in version V2, the server rejected the write request for Y, telling Y that the version was wrong. This algorithm is often used when version conflicts are in use.
But for the distributed database system we just described, we can't do that. Suppose we set the n=3 w=1. Now X writes the Key1 value 3, which is processed by node A, generating the V1 version of the data. The x user then performed a write to the Key1 value of 4 on version v1, which was handled by node C this time. However, node C has not received the previous a received version (data backup is asynchronous) if according to the above algorithm, he should reject this request, because he does not understand the version V1 information. But in fact it is not possible to refuse, because if C rejects the write request, in fact w=1 this configuration, the server to the customer commitment will be broken, so that the system's behavior degenerated into w=n form. Then C receives the request, which may produce the inconsistencies mentioned earlier. How to solve this problem?
The Dynamo method is to keep all these versions, using the vector clock to record version information. When a read operation occurs, multiple versions are returned, and the client's business layer resolves the conflict by merging each version. Of course, the client can also choose the simplest strategy, that is, the last write overwrite the previous write.
As an example:
Assuming the processing is single, the first request is sent to the E machine, and the update status is 1. E1 ((status:1,e)) is logged on the virtual node corresponding to E, and is synchronized to the other backup nodes.

Then the request is sent to the e-machine, and the update status is 2. The Record E2 ((status:2,e)) is updated on the virtual node that corresponds to E, and is synchronized to the other backup nodes.

Assuming that there are update requests to B and a, B and a will update their records separately for B1 (((Status:2,e), (status:3,b)) and A1 (((Status:2,e), (Status:4,a)).

Then, after synchronization, each virtual node will save the conflicting version until the business side resolves the conflict

The nagging NoSQL and the database trend

First of all, there is a more than 20-year relational database, it is still very successful, stable operation in the single-machine environment and reliable persistent data, and can control the concurrent access to effective processing transactions.
But this relational database based on relational algebra does not match the entity object classes designed by developers. So there are some ORM (Object Relational Mapping) layer framework products similar to hibernate and MyBatis.
Traditionally, each module of the application uses the same database as a common integration point. But now, the idea of popular application design ideas, such as microservices, can be understood as that each application module encapsulates its own database and integrates with the service. The idea of clustering is becoming more and more popular, but the traditional relational database has poor performance in the cluster. This is also the validation of the CAP theory, because the traditional relational database, consistency (C), and Availability (A) are well guaranteed, but the partitioning cluster fault tolerance (P) is not as good.
As a result, NoSQL, which emphasizes different cap dimensions, appears.

Riak Introduction

Riak is a distributed database of key-value pairs developed by Basho company based on Amazon's dynamo theory. Basho Technologies, the founder of the distributed NoSQL database Riak, received a $25 million G-round of financing after a strong round of growth, which is being used to expand development and marketing activities. Riak is open source, but Basho's Riak Enterprise adds key features such as Multi-data Center replication, which makes it possible to distribute workloads, monitoring, and uninterrupted support on a global scale.
We can take Riak as a good implementation of the Dynamo theory that we have described earlier.
Riak to now mainly experienced two times, namely 1.0 and 2.0 times.
Riak mainly has the following important characteristics:

1. A key-value database in which all key-value pairs are placed in different buckets (buckets).
2. Based on the high availability of the NWR model, Riak can maintain service availability by reading and writing to multiple servers to ensure that the network is disconnected or the machine is down.
3. When the cluster adds new nodes, it can be easily expanded without tedious operation.
4. The Riak distributes the data evenly across every node in the cluster, ensuring that the performance is approximately linearly increased as the machine increases.
5. Riak is a non-primary cluster in which a node outage or permanent damage does not affect the entire cluster
6. Version Vector resolution distribution is a data conflict. Is the conflict resolution at the beginning of this article.
7. Map-reduce operation

After 2.0, the following additional features are introduced:

1. The new Crdt (Conflict-free replicated data type) datatype. But a bucket display is required to specify a specific data type
2. Strong consistency improvements, Riak security-related, new Riak search engine (integrated SOLR)-these need to be explicitly opened Riak configuration files.
3. Dotted version Vectors (DVVS) new versions vector scheme

Riak-Background (3)