Shulou(Shulou.com)06/02 Report--

The little ant said:

I believe that everyone is no longer unfamiliar with the story of financial-level distributed relational database OceanBase independently developed by Ant Financial Services Group. In the just past 2018 Tmall double 11, the turnover of 213.5 billion once again set a new record, and the core link supporting this year's double 11 is the OceanBase 2.0 version.

In this article, Little Ant will explain in detail how OceanBase supported the flood peak of Singles Day this year with the same number of machines last year. Let's learn about it.

The writer is Yan ran, a senior technical expert on Ant Financial Services Group's OceanBase team. he is also a startup member of OceanBase and is currently responsible for the research and development of transaction engine and performance optimization.

OceanBase: a database service that provides extreme performance on ordinary hardware

OceanBase is a completely self-developed financial-level distributed relational database, which can be architecturally extended to meet the expansion requirements of cluster service capabilities.

OceanBase adopts the scheme of multi-replica replication to meet the requirements of reliability and availability, and is built on ordinary PC servers and does not rely on high-end engines.

Our goal is to provide database services with extreme performance on ordinary hardware. So, what are the characteristics of OceanBase's storage engine?

OceanBase's storage engine is similar to LSMTree. All new changes are recorded in Memtable first. Changes to these data are not written to disk in real time, but are written to the hard disk regularly in the background.

Whether on disk or SSD, when there are a large number of writes, its read performance will be greatly affected. From the very beginning, the architecture of OceanBase is to adapt to the characteristics of this kind of hardware, so there is no random write operation, and it is very friendly to SSD and disk. It can give full play to the throughput advantage of hard disk and squeeze out the best performance of hardware resources.

One of the things that OceanBase has been promoting from 0.x to 1.x to the current 2.0 is to maximize the performance of the hardware, hoping to bring more performance space to the business under the same hardware conditions. The goal of OceanBase has always been to have the best performance and the best cost-effective database.

Performance goal of OceanBase: extreme crushing hardware performance

From the perspective of user usage, the database has two important metrics, latency (Latency) and throughput (Throughput). These are two very different indicators.

According to the queuing theory model, the relationship between the two is shown in the above figure: as the throughput increases, the delay increases approximately exponentially.

When the performance of the whole system is not very high, the stability of delay can be maintained. When the system performance pressure is very high, the delay will increase, and what we need to do is to make the throughput as large as possible under a reasonable delay. In other words, it is to minimize the amount of work that a request needs to do, and then make as many requests as possible per unit of time. The ultimate goal of performance optimization is to improve the throughput of the system as much as possible in scenarios where latency is acceptable.

Performance optimization work

In the just past 2018 Tmall double 11, the turnover of 213.5 billion has once again set a new record. Then in the scenario of Ant Financial Services Group / Alipay, the pressure to pay will all fall on the OceanBase 2.0 version. In version 2.0, we did a very important thing to further squeeze the performance of the hardware-that is, to support this year's traffic peak with the same number of machines last year.

In the same hardware environment, the same number of machines, through the upgraded version of the server and the deployment of the server, to provide the anti-pressure capacity of Singles Day this year when the flood peak arrived at 0:00:00. The payment pressure of Shuang 11 is a typical OLTP model, with a large number of additions, deletions, modifications and queries. The storage model of OceanBase determines that the operation is mainly carried out in memory, so CPU is the main bottleneck at full load.

How the resources of CPU are squeezed to the extreme, in fact, mainly includes two aspects of work:

One is to optimize the number of instructions consumed by statement execution (Instructions / SQL), that is, the number of instructions to be executed per request. The fewer instructions, the better.

The second is to optimize the efficiency of system instruction execution (Cycles / Instruction), which can be expressed by CPI (Cyclesper Instruction).

System performance is determined by each line of code

Any piece of code can lead to bug, and any line of code has room for performance optimization. For different scenarios, we need to go deep into each line of code to see what optimizations can be made.

OceanBase 2.0 has been deeply optimized to achieve a good performance improvement. The figure above is only part of the optimization. Performance optimization is a detailed work, a bit similar to testing work, in essence, every line of code will affect the performance of the system.

Optimize CPU overhead

Commit asynchronization

In the existing model of OceanBase, the network module has a separate thread pool responsible for communicating with the client, accepting user requests and returning request results. Received requests are sent in the task queue and processed by the worker thread.

Compared with the model in which each user's connection uses a separate thread service, OceanBase's model can greatly reduce the number of context switches.

This is a good model for the execution of SQL statements. However, for the commit operation of the transaction, the log needs to be persisted locally and sent to other copies, and the commit operation will make the worker thread wait.

Commit asynchronization means that instead of waiting for the log to persist after the transaction commits the log, the worker thread can directly go to the queue to fetch the next task for execution. After the log persistence is completed, the transaction commits the completed operation and sends the result of the request to the user by callback.

Optimize system scalability

Scalability problem

We do a lot of things to get the system to do less unnecessary things and more useful things, that is, to increase the percentage of time CPU takes to do effective work.

The number of CPU cores of machines is increasing, from dozens of cores to more than a hundred cores now, it is a very common scenario on Intel's PC Server. The system runs on the server, and the scalability of multi-core CPU is a very important aspect. Here we take the counter scenario as an example. A single thread and multiple threads operate the same counter together, and the performance of the latter will be degraded hundreds of times because multiple cores compete for the same memory unit. In fact, sometimes a large number of people does not necessarily have a lot of strength, and a large number of people may also lead to a race track together.

There are a large number of similar competitive scenarios in the system, and the memory allocator is a common scenario. When multiple threads operate on the same memtable, they allocate memory from successive blocks of memory, which is like counter competition. Therefore, it is necessary to make the memory allocation operation of memtable in the form of partitions to reduce competition among multiple cores.

In the final analysis, performance optimization is actually optimizing all the details of the system, every detail must be extreme, the final performance can be squeezed to the best point, and the performance of the hardware itself can be played to the best.

The performance is endless.

As we can see, the blue block represents OceanBase version 1.4, which is the main version we use now, and the green block represents OceanBase version 2.0. Scenario An is the scenario of issuing an order, that is, the operation when you click to submit the order, and scenario B is the payment scenario, that is, the scenario in which you log on to Alipay to make final payment.

The final result is that the performance of OceanBase version 2.0 is 63% higher than that of version 1.4 in the order scenario and 58% in the payment scenario.

The Future of OceanBase

In the future, OceanBase will strengthen the optimization of full stack, optimize the workload, and optimize the new hardware.

OceanBase will continue to optimize the performance of the work, the aim is to continue to provide users with the highest performance and the best cost-effective products. This is the idea that OceanBase has always adhered to.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.