Characteristic analysis of OceanBase

Features of OceanBase

Advantages of OceanBase

Distributed transaction

OceanBase implements distributed transactions by improving the original 2PC

2PC problem

1. Single point of issue. Over-reliance on the coordinator, once the coordinator has a problem, the system will not operate normally, which may cause data inconsistency
2. Participants are unable to perform any operations while waiting for responses from other participants, and are in a blocked state. Once a participant fails, the coordinator can only find out through its own timeout mechanism
3. The efficiency is relatively low. The submission delay perceived by the user is 4 log write times and 2 round-trip times of RPC

Improvement of OceanBase

OceanBase solves the problems of 2PC single point, blocking and data inconsistency through Multi-Paxos

As shown in the figure above, when a distributed transaction is committed, one of the data shards will be selected as the coordinator to execute the two-phase commit protocol on all data shards. Remember the coordinator downtime mentioned earlier? In OceanBase, since all data shards are replicated by Paxos to achieve high availability of multiple copies, when the primary copy goes down, the backup copy of the same data shard will be converted to the new primary copy to continue to provide services, so you can It is believed that in OceanBase, participants and coordinators are guaranteed high availability without downtime (majority survival), bypassing the problem of coordinator downtime.

Under the premise of achieving high availability of participants, OceanBase has performed a "stateless" optimization for the coordinator. In the standard two-phase commit, the coordinator must persist its own state by recording logs. Otherwise, if the coordinator and participants are down at the same time, the coordinator may cause inconsistent transaction commit state after recovery. But if we think that the participants will not go down, then the coordinator does not need to write a log to record their own state.

After all participants in the first phase of Ocean Base reply that the prepare is completed, it will report that the transaction is submitted successfully, which improves the efficiency of 2PC.
Because there are multiple copies, as long as it is ensured that the transaction is executed without errors in the prepare phase, and the coordinator issues the commit command, It can be optimistic that the transaction execution is successful and feedback to the transaction initiator. OceanBase believes that the commit message will be received by most replicas, and after most replicas receive the message, they will synchronize the rest.

In the above figure (the green part represents the action of writing logs), the left side is the standard two-phase commit protocol, and the submission delay perceived by the user is the time it takes to write the log 4 times and the round-trip time of 2 RPCs; the right picture OceanBase's two-phase submission implementation, due to the less time spent on log writing by the coordinator and the earlier time for responding to the client, the submission delay perceived by the user is the time it takes to write the log once and the round-trip time for 1 RPC.

The problem with OceanBase

The efficiency of complex queries

After the OceanBase database is partitioned, it processes some complex queries, such as multi-table joins across partition keys and queries that do not contain partition keys. These queries need to be distributed to each partition and even produce Cartesian products.
Question
Does OceanBase provide a function similar to Mysql Binlog monitoring, so that some complex queries can be processed on ES

Very high requirements for data structure design

As discussed above, when OceanBase does not use the partition key, the query efficiency is very low, which is also a common problem in current distributed databases.

Design difficulties:

1. Is to combine business in design, give full play to the role of the partition key
2. Processing of cross-database association: field redundancy, binding table (data indexed by a certain dimension are placed in one table), global table (infrequent changes, small amount of data)
3. Paging: In order to scan fewer rows in cross-partition paging queries, you need to perform secondary assembly after querying in the sub-database, and when querying the second page, you need to bring the last page of the sort field value
4. Simple associated query can be achieved through multi-dimensional sub-database (for example, the order table is sharded by the hash value of userId. If you need to query the order details of a certain store in the merchant dimension, you need to create an order in order to avoid full partition scanning. The index mapping table of id and merchant. This table is fragmented by merchant id. When querying, first find out the corresponding order in the mapping table by merchant id, and finally go to the order table to bring out the order details), the efficiency is reduced
5. Position OceanBase in a transactional database (OLTP), focus on transaction pipeline operations, and put complex queries on ES

to sum up

OceanBase is particularly suitable for business scenarios (such as the financial field) that have more writes and less reads, high transaction requirements, high concurrency, and large data volumes.