Here follows three key technical capabilities of AntDB.

Thread Pool + Coroutine Model

Traditional database server-side processing model generally adopts single connection single thread model or single connection single process model, which will occupy a lot of system resources and have high context switching and cannot support large concurrency (such as 100,000+ concurrency).  AntDB can support millions of connections by introducing the thread pool + coroutine model.

Thread pool: Thread pool is a general technique that works by creating a certain number of threads in advance, and when a request is reached, the thread pool allocates a thread to provide service, and when the request is finished, the thread goes on to serve other requests. Compared with the model where one client connects to one thread, it takes less system resources and has higher throughput.

Coroutine: In contrast to threads, coroutine does not require kernel’s participation when switching contexts, and the timing of the switch can be controlled by the application layer code itself. AntDB will assign a coroutine to each client connection, one by one. The use with thread pool can further solve the problems caused by thread pool model such as jittering of thread number and deadlock.

Figure1: Thread Pool/ Coroutine Model

Highly Concurrent Interval Index

AntDB interval index adopts improved Btree (B-Link-tree) algorithm, and supports concurrent reading and writing. There is no need to lock the whole tree when modifying Btree, nor to lock the complete path from root node to leaf node, which greatly improves concurrent performance of interval index access, meanwhile, the node merge and recycle function minimizes the memory occupation. If multiple locks need to be held at the same time, the locking order for node accesses is: left to right, top to bottom. A maximum of 3 node locks are held simultaneously at the same moment.

Figure2: Btree algorithm

Distributed Transactions

Distributed transaction is a difficult problem in the field of distributed database, and the performance of distributed transaction largely affects the performance of the whole distributed database. 2PC (Two-Phase Commit) protocol is also chosen by AntDB to solve the problem of distributed transaction, and the classic 2PC protocol has two roles, coordinator and participant, which requires to write log four times, causing larger latency. AntDB optimized the 2PC protocol. The coordinator does not write logs, only retains the memory state; it removes the coordinator's step of writing logs twice, and asynchronizes the participant's P2 stage Commit Log, which greatly reduces the Commit latency; at the same time, because all participants are highly available, there is no problem that the coordinator is down and stuck appeared in the classic 2PC. If it is a standalone transaction, AntDB will optimize it as a local transaction to further reduce the latency.