Overview
To prevent mutual exclusion between data reads and writes, OceanBase Database stores multiple versions of data. To make it possible to process the semantics of multiple versions of data, OceanBase Database maintains multi-version consistency. OceanBase Database maintains multi-version consistency by using read versions and data versions. You can specify a read version when you read data from an OceanBase database. Then, the database returns all committed data whose version is earlier than the specified read version.
Take note of the following items:
Uncommitted transactions: OceanBase Database does not allow you to read data that is modified by a running transaction and is not yet committed. Otherwise, a dirty read occurs if the transaction is rolled back.
Transaction consistency snapshots: To ensure a transaction consistency snapshot that is easy to understand, OceanBase Database allows you to specify a read version to read all committed data whose version is earlier than the specified read version. This prevents fractured reads.
No mutual exclusion between reads and writes: In addition to preventing uncommitted data from being read and ensuring a transaction consistency snapshot, OceanBase Database prevents mutual exclusion between reads and writes.
Use multi-version read consistency
Database systems often use multi-version read consistency, which is among the key factors in concurrency control.
Weak-consistency reads: The weak-consistency read of OceanBase Database still ensures a transaction consistency snapshot, disallows uncommitted data to be read, and prevents fractured reads.
Strong-consistency reads: The strong-consistency read of OceanBase Database supports transaction-level read versions and statement-level versions. The two types of versions are applied to two isolation levels: snapshot read and read committed. Transaction consistency snapshots are required for strong-consistency reads.
Read-only transactions: Read-only statements in OceanBase Database provide the same capabilities required for strong-consistency reads and ensure transaction consistency snapshots.
Backup and restore snapshots: OceanBase Database provides a transaction consistency snapshot for backup. In this way, all required transactions are backed up but no redundant or uncommitted transaction is backed up.
The following figure shows multiple versions of data in actual scenarios.
As shown in the preceding figure, Data A contains committed data of "a" whose version is 100 (corresponding to Transaction 10) and committed data of "b" (corresponding to Transaction 7), Data B contains data "j" whose version is not determined (corresponding to Transaction 12) and committed data of "b" (corresponding to Transaction 10), and Data C contains data "x" whose version is not determined (corresponding to Transaction 15) and committed data of "y" (corresponding to Transaction 10).
Implementation
Transaction table
A transaction table is a MemTable that stores a collection of ongoing transactions in the replica. The corresponding data is read during the execution of a transaction based on the transaction status. A transaction can be in one of the following states: COMMIT, RUNNING, and ABORT. A transaction in the RUNNING state may have a local commit version (also known as a prepare version). A transaction in the COMMIT state has a global commit version (also known as a commit version). The global commit version is the final version of the transaction. The global commit version determines the consistency snapshot.
As shown in the preceding figure, Transaction 6 is in the ABORT state. Transaction 7 is in the COMMIT state and contains a global commit version of 80, Transaction 12 is in the RUNNING state and contains no local commit version, and Transaction 15 is in the RUNNING state and contains a local commit version of 130.
Process read requests
In a read operation, OceanBase Database reads data based on the read version.
When you initiate a read request to a transaction in the COMMIT or ABORT state, OceanBase Database determines whether to read data based on the global commit timestamp and transaction status. As shown in the following figure, the read request r1 attempts to read data based on the read version 90. Based on the snapshot read strategy, OceanBase Database reads data "b" whose version is 80.
In a read operation, OceanBase Database can skip transactions in the RUNNING state. As shown in the following figure, the read request r2 attempts to read data based on the read version 130. OceanBase Database can skip Transaction 12 that did not proceed to the two-phase commit state and read data "b" whose version is 100.
In a read operation, OceanBase Database waits for a transaction in the PREPARE state because OceanBase Database cannot determine whether the transaction is to be committed. As shown in the following figure, the read request r3 attempts to read data based on the read version 140. OceanBase Database waits until the transaction proceeds to the two-phase commit state and the local commit timestamp becomes 130, and then determines the relationship between the global commit timestamp and the read timestamp 140.
