Principle of distributed database CAP

Principle of distributed database CAP

Introduction to CAP

Traditional relational database transactions have ACID:

• A: Atomicity
• C: Consistency
• I: Independence
• D: Persistence

CAP of distributed database:

• C (Consistency): strong consistency

  • "All nodes see the same data at the same time", that is, after the update operation is successful and returns to the client, the data of all nodes at the same time are completely consistent, which is distributed consistency. The problem of consistency is inevitable in concurrent systems. For the client, consistency refers to the problem of how to obtain updated data during concurrent access. From the server side, it is how the update is replicated and distributed to the entire system to ensure that the data is eventually consistent.

• A (Availability): high availability

  • Availability refers to "Reads and writes always succeed", that is, the service is always available, and if there is a normal response time. Good usability mainly means that the system can serve users well, and there is no bad user experience such as user operation failure or access timeout.

• P (Partition tolerance): Partition tolerance

  • That is, when a distributed system encounters a node or network partition failure, it can still provide external services that meet consistency or availability.
  • Partition fault tolerance requirements can make the application appear to be in a functioning whole although it is a distributed system. For example, in the current distributed system, one or several machines are down, and the other remaining machines can still run normally to meet the system requirements, and there is no experience impact on users.

CAP theory

CAP theory is proposed for the distributed database environment, so the P attribute must tolerate its existence, and it must be possessed.

Because P is necessary, then we need to choose A and C.

As you all know, in a distributed environment, in order to ensure the availability of the system, replication is usually adopted to avoid damage to a node, resulting in unavailability of the system. Then there are many copies of the data on each node, and when the data is copied from one node to another node, it takes time and requires a smooth network. Therefore, when P occurs, it is impossible to When the node replicates data, you have two options at this time:

• Select availability A. At this time, the node that lost contact can still provide services to the system, but its data cannot be guaranteed to be synchronized (the C attribute is lost).
• Choose consistency C. In order to ensure the consistency of the database, we must wait for the node that has lost contact to recover. During this process, that node is not allowed to provide services to the outside world. At this time, the system is in an unavailable state (losing the A attribute) .

The most common example is separation of reading and writing. A node is responsible for writing data and then synchronizing the data to other nodes. Other nodes provide reading services. When two nodes have communication problems, you are faced with choice A (continue Provide services, but the data is not guaranteed to be accurate), C (the user is in a waiting state and waits until the data synchronization is completed).

to sum up

Partitioning is normal and inevitable. The three cannot coexist

Usability and consistency are a couple

• High consistency, low availability
• Low consistency, high availability

Therefore, according to the CAP principle, NoSQL databases are divided into three categories: satisfying the CA principle, satisfying the CP principle, and satisfying the AP principle:

• CA-Single-point cluster, a system that meets consistency and availability, usually not very powerful in scalability.
• CP-a system that satisfies consistency and partition tolerance, usually not particularly high performance.
• AP-A system that satisfies availability and partition tolerance, and generally may have lower consistency requirements.