Handling Hundreds of Millions of New Records Daily: How BOSS Zhipin Built a High-Performance, Efficient Storage Solution on OceanBase

This article is excerpted from the e-book A Study of OceanBase Community Edition Applications in Pan-Internet Scenarios. The full version is available for download.

Authors: Zhang Yujie, Database Engineer at BOSS Zhipin; Wang Zhanquan, Senior DBA at BOSS Zhipin

1. The Challenges BOSS Zhipin Faces in Ultra-Large-Scale Data Processing

BOSS Zhipin pioneered the internet “direct recruitment” model on a global scale and has become the largest recruitment platform in China. The BOSS Zhipin workload we are responsible for mainly uses databases to store the chat-log information generated during the recruitment process. The data volume is enormous, with hundreds of millions of new records added every day. Storage costs are high, and the data places tremendous pressure on query, analytics, and other workloads.

Constrained by the characteristics of traditional centralized databases, the challenges in data storage, processing, and analysis gradually intensified as the BOSS Zhipin business kept expanding and the data volume grew explosively. Whenever a new business requirement went live, we often faced a dilemma: because it was hard to accurately estimate the data volume or business growth trend over the coming period, and in order to get the business up and running quickly while avoiding the risk of over-engineering, we tended to adopt fairly flexible early-stage solutions. However, as the business gradually expanded and the data volume grew to a certain scale, the problem of data splitting came to the fore. This process was not only complex and cumbersome, it also required close collaboration among the database administrators (DBAs), the middleware team, and the business teams. All parties had to work together to ensure the data splitting went smoothly, which undoubtedly consumed a great deal of effort and time.

To address these challenges and comprehensively improve the stability and performance of our business, in late 2023 we began evaluating distributed database products, including OceanBase. The evaluation covered not only OceanBase’s overall architecture design but also its features and relevant performance metrics, along with a comparative analysis against MySQL.

In China, the traditional database market is still dominated by MySQL. But MySQL’s storage suffers from limited single-node capacity. This means not only that a single machine’s capacity is limited, but also that it affects cluster backup, recovery, and scaling capabilities when data volumes are large. If timeliness is a requirement, a single MySQL node cannot be too large. In our experience, the single-node capacity ceiling for most companies is generally around 3 TB, with 6 TB being rarer; once you exceed 3 TB you probably need to consider data splitting. Data splitting typically falls into two scenarios: one-to-many and many-to-many. With a one-to-many split, the business may require significant rework. OceanBase has a clear advantage here. Not only is there theoretically no capacity limit and better scalability, but cluster scaling has almost no impact on the business.

On the performance front, traditional databases also fall short. On one hand, their complex queries are not very efficient; on the other, single-table reads and writes have performance bottlenecks. If the write volume on a single table is very large, a single machine cannot handle it; meanwhile, under high concurrency there can be serious primary-replica lag, and some business scenarios may not tolerate high data latency. By contrast, OceanBase is highly efficient at complex queries and has no performance bottleneck for single-table reads and writes.

In terms of the operations stack, take a certain open-source database as an example: its usage is not limited to the database itself but also involves a host of peripheral tools, which often entails a lot of custom modification work. And if you perform data splitting, the investment is heavy not only for the business but also for the DBAs. OceanBase, however, excels at scalability: after a node is added, it can automatically rebalance with very little manual intervention. In addition, OceanBase’s high availability is excellent, meeting financial-grade standards, guaranteeing zero data loss, and keeping failover time within 8 seconds.

After gaining an initial understanding of OceanBase, we decided to find a suitable non-core workload within the company for a pilot, comparing the overall capabilities of OceanBase against MySQL and competing databases. After some research, we chose the historical archive database for chat logs as the pilot scenario.

2. Technology Selection for the BOSS Zhipin Historical Archive Database

Chat logs related to recruitment tend to be streaming in nature: once a record has been written for a while it is never accessed or updated again—write-heavy and read-light. Faced with rapidly growing online data, especially historical chat logs that are accessed very rarely or not at all, the storage space they occupy in online business databases reaches the petabyte level, wasting a great deal of hardware resources and driving up enterprise IT costs. At the same time, as the data volume grows, online database query efficiency gradually declines, hampering subsequent data changes and scaling. To solve these problems, we needed to separate hot and cold data for historical chat logs. The online databases holding hot data are several MySQL clusters using a sharding approach, which periodically clean up expired data each month and roll it into the historical archive database.

As the pilot scenario, we decided to do a database selection for the ultra-large-capacity archive database. The candidate database products were: MySQL, ClickHouse, OceanBase, and a certain open-source distributed database (hereafter referred to as DB-U). We mainly evaluated each product along two dimensions: storage cost and high availability.

(1) Database Selection: Storage Cost Comparison

Our archive database needs to retain three to five years of historical chat data, so we had to solve the cost problem of large-capacity storage. First, we created an identical table for storing users’ historical messages in each of MySQL, ClickHouse, OceanBase, and DB-U. The schema is shown in Figure 1.

Figure 1: The historical message table used for testing

We then wrote 100 million rows of identical single-replica data into each and compared their disk usage, as shown in Figure 2.

Figure 2: Disk usage comparison of the tested databases

It is clearly visible that ClickHouse, which stores data in columnar format, and OceanBase, which has an extremely high compression ratio, have storage costs that are significantly lower than MySQL and DB-U. So we conducted research into the storage engines of both ClickHouse and OceanBase.

1. ClickHouse Storage Engine Research

ClickHouse’s storage engine is columnar. Compared with a row-based storage engine, the data within a single column in ClickHouse is of the same type, so compression is highly effective. Columnar storage often achieves compression ratios of ten times or more, saving a great deal of storage space and lowering storage costs.

Figure 3: The cost advantage of columnar storage over row-based storage engines

However, the historical archive database is generally a write-heavy, read-light scenario, and a pure columnar storage engine like ClickHouse cannot leverage its query-performance advantage here. On the contrary, the disadvantage of poor write performance in columnar engines is amplified.

2. OceanBase Storage Engine Research

(1) OceanBase Storage Engine Architecture

OceanBase’s storage engine is based on an LSM-Tree architecture (as shown in Figure 4). It divides data into baseline data (stored in SSTables) and incremental data (stored in MemTables/SSTables). The baseline data is read-only—once generated it is never modified—while the incremental data supports reads and writes.

Figure 4: OceanBase’s LSM-Tree storage engine architecture

When the OceanBase database performs DML operations such as insert, update, and delete, the data is first written to the in-memory MemTable, so write performance is equivalent to that of an in-memory database—a perfect fit for our write-heavy, read-light historical archive scenario. When a MemTable reaches a certain size, it is dumped to disk as an incremental SSTable (the red arrow in Figure 4). The process of dumping to disk consists of batched sequential writes, which greatly improves disk-write performance compared with the scattered random writes of a B+Tree.

When the incremental SSTables reach a certain scale, a merge of the incremental data and baseline data is triggered, integrating the two. After the merge completes, the baseline data does not change again until the next merge. The system also automatically performs a daily major compaction during the off-peak window in the early morning.

But the LSM-Tree architecture also has a problem: read amplification (the green arrow in Figure 4). A query needs to scan both the SSTables and the MemTable separately, merge the results once, and then return the merged result to the SQL layer. To mitigate the impact of read amplification, OceanBase implements multi-level caching in memory—such as BlockCache and RowCache—to avoid frequent random reads of the baseline data.

(2) OceanBase Data Compression Technology

Under this storage architecture, OceanBase’s data compression is concentrated when SSTables are written during the compaction process, decoupling online data updates from compression.

OceanBase supports both generic compression that is agnostic to data characteristics, and data encoding that is aware of data characteristics and compresses on a per-column basis. These two compression methods are orthogonal—that is, a data block can first be encoded and then generically compressed to achieve a higher compression ratio.

OceanBase’s batched flush-to-disk characteristic allows it to adopt a more aggressive compression strategy, as shown in Figure 5. OceanBase uses a hybrid row-column micro-block storage format (PAX), fully exploiting the locality and type characteristics of data within the same column. Inside a micro-block, a group of rows is stored in columnar fashion and encoded per column according to the data characteristics. Variable-length data blocks and continuously batched compressed data also allow OceanBase to use the prior knowledge of already-compressed data blocks within the same SSTable to guide the compression of the next data block, thereby packing as many data rows as possible into each block and choosing a better encoding algorithm.

Figure 5: Illustration of OceanBase’s compression strategy

Unlike some database implementations that specify data encoding in the schema, OceanBase chose user-transparent adaptive data encoding, which reduces both the burden on users and storage costs. From the perspective of the historical archive database, we also do not need to make too many compression- and encoding-related configuration adjustments for the data.

(2) Database Selection: High Availability and Stability Comparison

In addition to storage cost, we also compared the high availability and stability of ClickHouse and OceanBase.

1. ClickHouse

We treated ClickHouse as a historical database and tested it thoroughly: we used Replication to automatically synchronize data among different servers in the cluster, ensuring high availability and fault tolerance of the data; we used ZooKeeper to coordinate the replication process, track the state of all replicas, and ensure they remained consistent. Replication and ZooKeeper guaranteed multiple data replicas across different physical devices, reducing the risk of data loss.

Figure 6: ClickHouse high-availability architecture

However, while using ClickHouse we found that its high-availability solution has some issues in large-data scenarios. This is mainly because the native Replication solution stores too much information in ZooKeeper, and to keep the service running you generally have one or several replicas. But ZooKeeper does not support linear scaling and is limited by a single machine’s service capacity. As the data volume of the archive cluster keeps growing, the whole service quickly becomes unavailable.

In practice, when using ClickHouse people often treat ZooKeeper as a combination of multiple services rather than merely a coordination service. For example, a common practice is to use it as a log service, with a lot of behavior logs and other numeric information also stored in ZooKeeper; it is also used as the catalog service for tables, with some table schema information validated against ZooKeeper. This causes the amount of data ZooKeeper has to handle to grow linearly with the total data volume. Based on the estimated growth rate of our archive database, ClickHouse paired with ZooKeeper cannot support three to five years of full archive data requirements.

In addition, ClickHouse’s replication feature relies heavily on ZooKeeper. But ZooKeeper is an external coordination service, and its own configuration and maintenance add extra complexity. If ZooKeeper itself has problems, it may affect ClickHouse’s replication process. At the same time, this high-availability solution lengthens the troubleshooting chain and makes problem diagnosis harder; the recovery process also becomes fairly complex and requires manual intervention. While using ClickHouse, we frequently encountered data loss.

2. OceanBase

OceanBase is a natively distributed database that inherently guarantees consistency among multiple data replicas. It leverages a Paxos-based distributed consensus protocol to ensure that at any moment a Leader can only be elected once a majority of replicas reach agreement, guaranteeing the uniqueness of the primary replica that provides data services. In other words, OceanBase ensures database high availability through multiple replicas and the Paxos protocol.

Figure 7: OceanBase high-availability architecture

Compared with the high-availability solutions of MySQL and ClickHouse, OceanBase’s high-availability solution reduces our operational difficulty and the difficulty of business changes. Moreover, OceanBase’s multi-region, multi-replica architecture and the Paxos consensus protocol can also support storing data replicas separately in the same city and in a remote location, achieving geo-disaster recovery.

Figure 8: OceanBase multi-region, multi-replica architecture

Because OceanBase is distributed by nature, its data storage inherently has dynamic scaling capability. When the archive database’s data volume keeps growing, our DBAs only need to run a few commands to scale up the machine hardware or the number of nodes in the entire cluster. After new nodes are added to the cluster, the data automatically completes load balancing between the new and old nodes, achieving smooth, business-transparent scaling that requires no downtime. This also saves the database scaling and migration costs after a surge in business volume, greatly reducing the various risks caused by insufficient database capacity.

When scaling OceanBase—whether increasing a single machine’s capacity, increasing the number of nodes within a Zone, or adding a new Zone for higher availability—everything can be done directly through the GUI-based OCP tool. Figure 9 is an OCP screenshot of us expanding a single-replica cluster into a three-Zone, three-replica cluster.

Figure 9: Expanding a single-replica OceanBase cluster into a three-Zone, three-replica cluster via OCP

Compared with running commands in a terminal, our DBAs reported that using OCP to deploy and operate OceanBase is much more convenient, and we recommend it to everyone.

(3) Database Selection Summary

To sum up: compared with MySQL and ClickHouse, in terms of consistency, OceanBase natively provides a strongly consistent storage guarantee rather than trading off other capabilities by compromising with eventual consistency, and it does not require configuring a variety of complex peripheral components to ensure consistency. In terms of high availability, OceanBase’s multi-replica disaster-recovery technology is targeted at a single cluster: transaction logs are persisted and synchronized among multiple replicas, and the Paxos protocol guarantees that log data is successfully persisted on a majority of replicas, providing users with high availability of RPO=0 and RTO<8s in the event of a minority failure. Throughout the entire testing process, OceanBase also performed more stably than MySQL, ClickHouse, and DB-U.

After comprehensively weighing the storage cost, high-availability capability, and operational difficulty of the various databases, we ultimately chose OceanBase as our historical archive database.

3. Putting OceanBase into Practice for the BOSS Zhipin Historical Archive Database

(1) OceanBase Historical Archive Database Architecture

Our current online database is a primary-replica MySQL setup used to store hot data, generally users’ chat logs from the most recent month; the historical archive database is several OceanBase clusters managed by OCP. Every month, we use a self-developed DTS tool to periodically archive expired data from the online MySQL database to the historical database built on OceanBase. The overall architecture is shown in Figure 10.

Figure 10: Illustration of BOSS Zhipin’s online and historical database architecture

By early 2024, we had used OCP to take over 8 OceanBase archive business clusters with more than 20 tenants. The online MySQL had over 10,000 sharded tables and was still continuously writing data to MySQL hashed by user ID through the app, while expired historical data is now imported directly into the OceanBase archive database.

Figure 11: OceanBase historical archive database management interface

An old ClickHouse archive cluster we once used still provides read access to some historical data, but considering ClickHouse’s stability and data-safety issues, that archive cluster will gradually be replaced by OceanBase.

(2) Business Benefits of Using OceanBase as the Archive Database

First, through the high compression capability of its database kernel, OceanBase helped us easily complete cold-data archiving while saving more than 70% of storage resources.

Figure 12: Illustration of OceanBase’s high-compression characteristic

Second, OceanBase is a natively distributed system with good scalability, and it can also provide users with high availability of RPO=0 and RTO<8s in the event of a minority failure, making the database more stable in use.

Finally, OceanBase comes with an intelligent, GUI-based OCP platform tool that lowers the deployment and operations barrier for our DBAs. OCP performs full-lifecycle management of resource objects such as clusters, tenants, hosts, and software packages—including management, installation, operations, performance monitoring, configuration, and upgrades. And in addition to the default monitoring alerts, OCP now supports custom alerts as well: for example, we can customize alert thresholds for disk and memory utilization, meeting customized alerting needs. OCP also supports backup and recovery, and can provide some automated diagnostic features during operations.

Figure 13: OceanBase’s GUI-based OCP tool greatly reduces operational difficulty

4. From Non-Core Workloads to At-Scale Rollout: OceanBase’s Adoption Journey and Use Cases at BOSS Zhipin

(1) OceanBase’s Adoption Journey at BOSS Zhipin

Since we began evaluating OceanBase in late 2023, its adoption at BOSS Zhipin went through four phases: research and adaptation, the non-core workload pilot (the historical archive database mentioned earlier), core business onboarding, and at-scale rollout, as shown in Figure 14.

Figure 14: OceanBase adoption milestones at BOSS Zhipin

After the research phase ended, the project moved into the second phase: adapting internal middleware, including DTS and the read-write splitting middleware, as well as the archive database pilot. Subsequently, after the pilot deployment for the historical archive workload, we planned to adopt OceanBase widely across the company, including some relatively important business scenarios such as recruitment chat. The data volume there is enormous (after a secondary-partition refactor that added table storage and spread out the write pressure, the overall response time became more stable).

After the business was onboarded onto OceanBase, we invested a great deal of work to handle the issues that might arise during use. Starting in October 2024, we shifted our focus to OceanBase metadata management and integration with the internal control platform, improving the internal monitoring and alerting system and enhancing operations automation efficiency and the internal operations experience.

Figure 15 shows the overall architecture layout of BOSS Zhipin’s internal relational databases. Front-end traffic is first received by the internal proxy software OneDB, which then intelligently distributes traffic to the primary or replica databases, ensuring efficient and flexible data processing.

Figure 15: The overall architecture of BOSS Zhipin’s internal relational databases

For OceanBase, we currently adopt two main strategies: archiving and hot-cold data separation.

The archiving approach is simple to operate. As mentioned earlier, we periodically archive part of the data from day-to-day relational databases into OceanBase for long-term retention and management. The hot-cold separation approach is more fine-grained: we store the most recent portion of data in both MySQL and OceanBase. MySQL is responsible for storing recent hot data to ensure fast access, while OceanBase stores the full dataset—both hot and cold data—providing comprehensive support for data queries and analytics. In addition, we deployed a log subscription service at the bottom layer of the system. The main responsibility of this service is to synchronize data to the data warehouse in real time, providing strong support for subsequent data analytics and applications.

Currently, we have deployed 20+ OceanBase clusters with 100+ online nodes. The physical machines we use have storage capacities in several specifications—3 TB, 7 TB, and 15 TB—ensuring that every cluster uses a consistent storage capacity for easier subsequent management. Across the workloads in production, there are four main application scenarios.

• Data archiving scenario. We periodically archive cold data from MySQL to free up storage space.
• Chat message processing scenario. In this scenario, we use a dual-write mechanism to store messages. MySQL stores the most recent month of data, while OceanBase stores all data.
• Analytics scenario. This is closely tied to the chat feature. In this scenario, we mainly store behavioral data generated during chats and perform related analysis on it.
• Control platform scenario. This involves our internal control platform and is used to store metadata. Currently we store some metadata from the CMDB and configuration center in OceanBase. The main reason for choosing it is that when a machine fails, we can leverage OceanBase’s high availability to eliminate circular dependencies during failover, ensuring the control platform can recover quickly in the event of a data-center failure.

Figure 16: OceanBase’s four main application scenarios at BOSS Zhipin

Below, we use the chat-message processing workload as an example to describe how OceanBase is applied to BOSS Zhipin’s core business.

(2) OceanBase in BOSS Zhipin’s Core Business: Chat Message Processing

The cluster for the chat-message scenario has dozens of nodes, each using a single 15 TB disk. In terms of machine configuration, configurations vary between 32 cores and 48 cores. Overall, our data grows very fast—we basically add machines to the cluster every month to keep up with the increasing storage capacity. At peak, the write volume can reach tens of thousands of QPS, and we can guarantee that 90% of requests complete in around 4 milliseconds.

Our initial message storage used a single-partition design, primarily partitioned along the time dimension. This caused a problem: all of a given day’s messages were written to the same shard, making the primary shard’s write volume very large within a single day and creating a performance bottleneck. Due to the excessive write volume, business response times fluctuated during peak hours or certain time windows, resulting in a poor experience.

Our optimization strategy for this was to add a secondary hash partition by ID on top of the daily partitioning. This spreads the write traffic from a single point across multiple nodes, eliminating the write bottleneck. At the same time, we changed single-row writes into batch processing, reducing the number of interactions between the application and the database and lowering network and I/O overhead. Through these two approaches, on one hand we eliminated the single-point write bottleneck, and on the other we solved the response-time fluctuation problem. Although switching from single-row writes to batch writes raised the response time somewhat, the increase was within an acceptable range, and the jitter problem was perfectly resolved.

In addition, while using OceanBase, we also made other optimizations.

First, after a small number of Joins were migrated from MySQL to OceanBase, performance declined somewhat. In particular, association queries between small tables became cross-node. To solve this, we used the existing tablegroup mechanism to place the tables that need to be joined on the same node, avoiding cross-node overhead. After the nodes were rebalanced, we tested product performance again and found a significant improvement over before the migration.

Second, queries on frequently updated small tables were slow. The data volume of this table is not large, but inserts, updates, and deletes are very frequent—this is called a “Queuing table” in OceanBase. The main reason for slow queries is that when deleting data, OceanBase does not immediately delete it at the physical level, so queries have to scan too many physical rows, degrading performance. To solve this, we increased the table’s dump frequency and quickly cleaned up deleted records. This way, queries scan fewer physical rows, improving overall performance.

5. Cost, Efficiency, and Stability: OceanBase Delivers a Triple Win for BOSS Zhipin

OceanBase has now been running stably at BOSS Zhipin for some time, meeting our expectations in cost, efficiency, and stability.

(1) Cost Benefits

After adopting OceanBase, our storage costs dropped significantly—by at least 60% on a rough estimate. Specifically: first, the archive cluster, which originally had 4 TB+ of capacity, requires only about 500 GB per replica in OceanBase, a compression ratio as high as 8x; second, the storage compression ratio for chat-message data is around 4x, a pleasantly surprising result. Taken together, after adopting OceanBase we expect to save 50+ physical machines, directly lowering our 2025 hardware procurement costs.

(2) Efficiency Benefits

The efficiency benefits show up in two ways: improved query performance and improved operations efficiency.

For query-performance improvement, our most direct impression is that the response time of complex queries dropped dramatically. At the same time, after migrating from the original system to OceanBase, although the exact figures are hard to compute precisely, we could feel that machine utilization decreased.

Thanks to OceanBase’s architectural advantages, its concurrency-handling capability is stronger than that of traditional standalone databases. In particular, its flexible scaling capability—you only need to add a machine to the cluster to automatically scale out—makes elastic scaling during our peak periods very convenient and directly shortens query time. For example, after we migrated finance-related queries to OceanBase, we compared the average latency before and after the migration and found a significant performance improvement, with some SQL performance improving nearly 20x, as shown in Figure 17.

Figure 17: Performance improvement after migrating finance-related queries to OceanBase

In addition, OceanBase significantly improved operations efficiency. After introducing OceanBase, online operations became relatively simple. For example, the scaling process is very fast, greatly saving on operations labor costs. Moreover, when troubleshooting OceanBase-related issues, because OceanBase’s tools provide rich monitoring metrics, we can rely on these metrics to quickly locate problems.

(3) Stability Benefits

During our use of OceanBase, there were almost no stability incidents (aside from proactive operations), and the system is very robust. Take the chat-message storage scenario as an example: previously, because the table storage used first-level (time) partitioning, there was some write pressure, and during peak hours the single-point bottleneck caused some response jitter. After refactoring to two-level partitioning (adding a second-level hash partition on top of the time partition), there was no more noticeable jitter in overall response time. During operation, OceanBase’s failure rate is very low. We conducted related failure drills (taking down a node), and its recovery RTO was under 8 seconds, meeting expectations. In addition, operations have very little impact on the business.

6. Future Plans: Continuing to Expand OceanBase’s Scope of Application

Because this database replacement project went smoothly and achieved multiple satisfying benefits, we plan to continue expanding OceanBase’s scope of application. Specifically, this includes several aspects.

First, for the online database scenario, our online databases still use MySQL. Sharding within MySQL is clearly far more complex from a business standpoint than using a single table in a distributed database, and data consistency is hard to guarantee. When the data relationships among multiple tables or databases are complex, maintaining data consistency becomes much harder. The operational difficulty of the online databases is also high—you need to manage and maintain multiple databases or tables, which increases the difficulty of system troubleshooting and maintenance. And in sharding scenarios, tracing historical problem data is a common issue: because the data is scattered across multiple databases or tables, tracing historical data becomes difficult.

We still have many upper-layer services that depend on the online MySQL, and many of these upper-layer services were designed and implemented around MySQL sharding, so replacing the online database from MySQL with OceanBase will still take some time. But after introducing OceanBase, we improved the database side’s native support for distributed tables, providing a more convenient and feasible solution for workloads with large storage volumes where refactoring the sharding logic is difficult.

In addition, as online workloads are gradually onboarded, downstream workloads such as data warehouses have also raised requirements based on binlog subscription. OceanBase 4.2.1 provides a Binlog service, so downstream onboarding for sharding-style workloads can be provided directly through this service, reducing the complexity of having downstream consumers subscribe to the binlog of each MySQL cluster individually.

Second, on the technology-evolution front, our top priority is architecture optimization. We are currently doing in-depth research into AP features, aiming to explore the feasibility of replacing internal pure-AP database products with OceanBase. On the backup front, we have successfully completed backup validation between OceanBase and internal S3 storage. Next, we will integrate OceanBase’s backup feature into the company’s backup platform to further improve and optimize the backup system.

Third, on the business-support front, we plan to further expand OceanBase’s scope of application in internal workloads and write relevant documentation that introduces OceanBase’s features in detail, so that business teams can quickly make decisions during technology selection. At the same time, we will keep working to improve the experience of using OceanBase in our business.

Fourth, on team building, we will pursue two approaches: first, regularly organizing the internal team to study OceanBase’s mechanisms module by module and holding knowledge-sharing sessions to improve the team’s overall command of OceanBase technology; second, building a knowledge system by summarizing and accumulating the problems encountered while using OceanBase, forming a valuable knowledge resource.

Fifth, on improving the tooling platform, we will continue to explore more capabilities of tools such as ODC and the Binlog service, keep optimizing the connection between OceanBase and the internal control platform, optimize OceanBase lifecycle management and automation workflows, and improve the granularity of management. At the same time, we will integrate with the internal alerting platform and refine the related processes to achieve more efficient collaboration.

Sixth, on best-practice exploration, introducing a new database also raises the bar for DBAs. While ensuring database stability, we must also make reasonable selections and continuously optimize across dimensions such as hardware and service configuration to better unlock OceanBase’s potential. We will continue to practice and discuss together with the OceanBase team to find the most efficient and cost-effective ways to use OceanBase, providing strong support for the rapid and stable development of our business.