Some articles about nosql

Thoughts on Cache Design

Oceanbase-hundreds of billions of databases

[Distributed System Engineering Implementation] distributed transactions

Acid is a feature of standalone transactions, but in a distributed system, because the two machines cannot reach the same state in theory (refer to Fischer and other papers), we need to introduce a single point for coordination, this shows the famous two-phase lock protocol. The two-phase lock (two-phase commit) protocol is a required protocol for each distributed engineer, which is roughly as follows:

1. Prepare: the coordinator sends a prepare message to each participant (participant). Each participant either returns a failure directly, for example, permission verification fails, or is executed locally but not submitted, it is in a state where everything is ready, and there is nothing to do with it;

2. Commit/rollback: If the Coordinator receives the failed message or times out, it directly sends a rollback message to each participant. Otherwise, it sends a commit message; the participant submits or rolls back the data according to the instructions of the Coordinator;

Two-phase locks are pessimistic locks. The first problem is the cost of the Protocol itself: the entire Protocol process requires locks, such as locking a database record, A large number of Transaction status related operation logs need to be persisted. More importantly, the vulnerability of the two-phase lock in the event of a fault, such as the fatal defect of the Two-Phase Lock: when the Coordinator encounters a fault, the entire transaction can continue to be executed only after the Coordinator recovers,If the Coordinator encounters a permanent error such as a disk fault, the transaction will become an orphan permanently abandoned.. For more details about the two-phase lock, see Andrew S. Tanenbaum's masterpiece <distributed systems: Principles and paradigms>.

There are different solutions to the fault of the Two-Phase Lock Coordinator: the first is the three-phase lock (three-phase commit), which is purely a theoretical method, the project is not operable; the second method isPerform replication on the CoordinatorWhen the master Coordinator fails, the slave server can take over the service. To automate this process, you can introduce the paxos protocol to execute the master Coordinator Election (refer to Jim Gray and Lamport papers ).

Of course, it should be noted that not all multi-host transactions require two-phase locks. For example, three copies are stored in Microsoft Azure, the transaction operations of the primary replica are synchronized to the secondary replica in the form of operation logs. Although transaction operations are performed on all three machines, they are essentially standalone transaction operations.

Optimistic locks correspond to pessimistic locks such as two-phase locks: most operations are unlikely to succeed, so the prepare phase similar to the two-phase locks is not required and is executed directly on multiple participants, when a participant fails to perform the operation, the compensation operation is performed again. Another example is the read-test-write operation that often occurs in the storage system. Instead of locking the entire process, we allow access to mutex resources by other clients in the read-test-write process, for example, the data version is recorded in the read phase, and the version is checked during write. If any inconsistency is found, the entire read-test-write process is retried.

Base is mainly used for multiple business systems. This concept is not mentioned in the storage system. For an SQL system like a database, it is the acid consistency model; for a nosql system like GFS + bigtable, It is the consistency model of a single row transaction; if it is a nosql system like Google External Store, It is a consistent model that supports cross-machine multi-line transactions; if it is a decentralized system like dynamo, It is a consistent model based on conflict merge. The base principle can be used between multiple business systems for architecture design. For example, message-oriented middleware can be used for reliable message transmission to ensure that multiple business systems reach a consistent state.

Almost all nosql storage systems do not support distributed transactions because of insufficient demand and extremely complex implementation. However, if the business really needs distributed transactions, it is supported. Although it affects scalability, it is impossible for us to find other methods that do not affect scalability because we are a nosql system.

[distributed system engineering practice] Random Access to the kV storage engine