Tongfang Smart Energy: OceanBase Powers a Secure, Reliable, High-Performance Energy Data Foundation

This article is excerpted from the e-book A Study of OceanBase Community Edition Use Cases in Pan-Internet Scenarios. Click the link to get the full content.

Introduction

Tongfang Smart Energy Group is a backbone enterprise under Tongfang Co., Ltd., committed to becoming a world-leading provider of comprehensive smart-energy solutions. Drawing on the technological strengths of China National Nuclear Corporation (CNNC) and Tsinghua University, the company serves major energy-use scenarios—buildings, transportation, industry, northern district heating, data centers, and more—offering design consulting, product technology, investment and construction, operation services, and other project services. It provides cities with one-stop solutions for intelligent, energy-saving, and efficient energy use under a green, low-carbon energy structure, and delivers first-class energy investment and operation services.

Starting from our business dilemmas, this article explains why we ultimately adopted OceanBase 4.2.1 after comparative testing of similar database products. It also presents our hands-on experience in a real environment and uses application cases to illustrate the technical-performance improvements and cost-reduction-and-efficiency gains achieved in our business scenarios.

I. Business Dilemmas Created an Urgent Need for a High-Performance Domestic Database

Currently, the company’s projects mainly have the following distinct characteristics:

• toG (Government) business. Our main projects differ from common consumer-facing (toC) or enterprise-facing (toB) services; they are more about serving government industrial construction, urban transportation, infrastructure, and the like.
• Independent projects. Most projects have completely independent server resources and generally don’t share them across projects.
• Little use of public cloud. Very few projects use public cloud or related services; large-scale clusters are usually deployed via an internal private cloud or physical machines.
• Equipment-centric. Most projects are equipment-centric, capable of working 24/7 with no operational limits or low-pressure troughs, and they generate data at a high frequency.

Against this business backdrop, traditional databases ran into support bottlenecks due to outdated technical architectures, low server specs, complex functionality, and other issues. On one hand, for physical machines, MySQL is hard to scale by adding single-machine CPU, memory, and storage, and there’s a risk of single-node failure. On the other hand, MySQL’s performance gains are limited, and sharding solutions add architectural complexity and modification costs.

Figure 1 shows an example of one of the company’s projects: this project used 14 machines in total—2 with lower specs and 12 high-spec. At the underlying layer it used Hadoop, while the upper layer used the Apache Phoenix interface and SQL-layer conversion. For data transfer, intermediate data was transmitted via MQ and other protocols, and Spark was used for offline computation tasks.

Figure 1: Example of a company project’s database architecture

This project built a distributed data-transmission system that transmits device data from each province to its respective station, and then from the stations to the central system. Currently, the project covers more than 100 stations and over 3.5 million data points, with the daily station data volume reaching 1 billion records. After two years of operation, the data scale is about 55 TB, and it’s expected to support 2,000 stations and 60 million data points in the future. Although there is still a gap between the currently onboarded stations and the projected supported data volume, the sheer data volume means we must plan our support approach in advance.

As you can see, the original Hadoop stack in this project has many components, is complex to set up, and has relatively high operations costs. In addition, the special Phoenix syntax and time-series issues caused trouble for developers, and the performance couldn’t fully meet our requirements.

There are also some older projects using traditional relational databases—they’ve run for a long time, have relatively backward technical architectures but fairly complex functionality, and their modification costs remain high.

For new projects, we can plan server specs and counts before development begins, and starting from scratch isn’t constrained by legacy code architecture. But new projects come with higher requirements—especially high reliability and the localization that enterprises have valued so highly these past couple of years.

Given these needs, we wanted to find a database product that was high-performance, had a complete ecosystem, was highly compatible with traditional relational databases, and at the same time was highly scalable, highly reliable, easy to maintain, domestically developed, and self-controllable.

II. After Comparing Multiple Products, Why Did We Choose OceanBase?

When selecting a database solution, we studied database products suited to different directions, including HBase-Phoenix, Apache Ignite, TiDB, OceanBase, and others. Below are some basic research findings.

1. HBase-Phoenix

HBase is a KV-storage-type database, and Phoenix provides a SQL interface that makes analysis and business development more convenient. However, its structure is fairly complex, it doesn’t support many open-source tools, and its default characteristics don’t match our development habits, which creates certain limitations in practical use.

2. Apache Ignite

It is an in-memory relational database. When we used it, Ignite wasn’t mature enough, had relatively little documentation, and had low community activity. We ran into some problems—for example, occasional partition loss that made table queries impossible, and services that were running normally unexpectedly crashing under no business load—which is unacceptable for an online database.

3. TiDB

According to our research, this product requires a minimum of 13 servers for a production environment, which is hard for some of the company’s older projects to reach in terms of resource configuration, so it poses certain challenges in practical use.

4. OceanBase

By comparison, OceanBase is fully self-developed by Ant Group, satisfying our domestic-development needs. It has high community activity, official staff respond promptly to user questions, and its complete ecosystem makes operations convenient. Notably, OceanBase is highly compatible with MySQL. Testing showed that a MySQL project migrated to OceanBase can run directly with zero application modification. In addition, OceanBase is highly popular—ranking first on the Modb domestic-database leaderboard, with its GitHub Star count reaching 7,000+, all of which indicate its broad recognition and use in the industry (as of 2025-03-18, the Star count had exceeded 9K).

On the basis of domestic development, MySQL compatibility, and a complete ecosystem, we believe OceanBase is superior to the other databases we tested and better fits our actual business needs. This is mainly reflected in the following aspects:

• High scalability. Flexible horizontal and vertical scaling with automatic load balancing; nodes can be expanded easily and conveniently as needed—up to 1,500+ nodes—transparently to the application;
• High reliability. Strong data consistency, multiple cluster replicas, and support for cross-region disaster recovery, avoiding single points of failure;
• Low cost. An integrated architecture with a high compression ratio, with a minimum deployment of 3 servers;
• HTAP. Converged functionality—a single engine supports both OLTP and OLAP business at the same time;
• Multi-tenancy. Reasonable resource division to maximize resource utilization.

In the end, we chose OceanBase as our new database solution. As shown in Figure 2, compared with traditional databases such as MySQL, OceanBase—thanks to its architectural advantages—can scale easily and flexibly, elegantly avoid single-node failures, and improve the overall performance of the database service. Because OceanBase is compatible with MySQL, we don’t have to worry much about the problems and costs of application modification.

Figure 2: Architecture comparison between a traditional database and OceanBase

At the same time, we conducted a performance stress-test comparison of OceanBase and MySQL. Figure 3 shows the data we obtained testing OceanBase 4.2.1 and MySQL 8.0. The test was run on a machine with 32 cores, 64 GB of memory, and a 200 GB disk, using Sysbench 1.0.2 as the stress-testing tool, with Anolis 8.8 as the operating system.

Figure 3: Comparison of test data for OceanBase 4.2.1 and MySQL 8.0

In this environment, we tested a “1-million-row single table” and “1 million rows across 10 tables” respectively, and considered the performance of OceanBase and MySQL under different thread counts. As you can see, MySQL’s performance gradually declines after 32 threads, while OceanBase’s performance keeps rising under multiple threads, reaching twice the performance of MySQL 8.0 under the same hardware environment. This test shows that OceanBase has better performance under the same hardware environment—especially more outstanding under multiple threads—with a clear performance improvement over MySQL 8.0. This further confirms the correctness and reliability of our choice of OceanBase as our database solution.

III. Markedly Improved Usability After Adopting OceanBase

After testing multiple versions, we ultimately used OceanBase 4.2.1. The most notable improvement across versions is usability—in particular, both OCP and OBD support a graphical interface, avoiding complex configuration, which is what got us started on OceanBase deployment. During setup, we found that OceanBase adapts best to CentOS 7.9, but to meet localization needs we leaned toward Anolis 8.8. Below is our hands-on experience in a real environment, for your reference.

(1) Resource Configuration

Because OceanBase divides CPU and memory resources by tenant, even setting up just an instance consumes a certain amount of CPU and memory itself. Although OceanBase has supported running in low-spec, low-resource environments since version 4.0, we don’t recommend configuring resources too low in an actual production environment; otherwise, the actual resources allocated may be insufficient.

(2) Disk Selection

OceanBase currently recommends SSDs and advises against mechanical hard drives. For companies that use HDDs in test environments, this will have some impact, possibly causing low efficiency and affecting the experience. When planning disks, no matter how small the data volume, the log disk should be planned at no less than three times the memory size; otherwise OCP by default cannot allocate all memory resources to the tenant. To prevent I/O resource contention, the log disk, data disk, and system disk should ideally be configured independently and not shared.

(3) Choosing a Deployment Method

OBD and OCP each have their strengths. OBD is very convenient, comes with OCP Express, and can perform simple cluster management—you can complete cluster setup without too much resource configuration and planning. However, some advanced operations need to be done through command-line operations in the terminal—for example, you can’t manage OBProxy directly through pages, nor can you restart the cluster, and so on—so it places higher demands on maintenance staff. By comparison, OCP is powerful and easier to maintain. With OCP you can perform a variety of advanced operations and manage multiple clusters at the same time, making it well suited for setting up large projects. However, as an independent component, OCP requires fairly high resource configuration; and when setting up OCP, you need at least one independent machine and a separate OceanBase cluster to improve its stability and ensure unrestricted functionality—all of which limit OCP’s application in small and medium-sized projects.

Recently, we found that the new version of OBD can deploy OCP directly, indicating that tools like OBD and OCP are gradually maturing and becoming more convenient. Besides OCP and OBD, we also use export tools and migration-assessment tools such as OMS, ODC, CDC, OBKV, and OAT, as well as MySQL-ecosystem tools. We suggest that the official team merge OBD, OCP, and OAT, or better highlight their respective focuses, to improve the user experience. Such integration would make it more convenient for users to manage and maintain databases while reducing learning and usage costs.

IV. Application Scenarios: Technical Project Transformations Using OceanBase

(1) Scenario 1: A New-Energy Project

This project has already onboarded more than 100 new-energy power-generation stations across 20 subordinate provincial branches, with over 3.5 million data points and business covering nearly every province in the country. By building a distributed data-transmission system, it implements a transmission architecture in which device data is aggregated through stations to the central system. The current system has been running for two years and accumulated 55 TB of data, processing an average of 1 billion records per day. According to the plan, it will expand in the future to support 2,000 stations and a scale of 60 million data points.

The original project was built on physical machines using the Hadoop stack: 2 NN nodes (192 GB memory, 48 cores, about 3 TB disk each), 12 DN nodes (384 GB memory, 96 cores, 1 TB×2 + 8.7 TB disk each), plus other servers, for a total of about 20 servers—making the whole technical architecture huge and complex, with a high technical barrier and high operations costs.

We decided to use OceanBase to transform the project, starting at the central control level. We prepared 1 OCP node and 6 OBServer nodes for OceanBase, with the configuration shown in Table 1.

Table 1: OceanBase configuration

All 6 OBServer nodes were deployed with the OBProxy service. To improve performance, we used LVS to load-balance OBProxy across the 6 servers; the structure is shown in Figure 4.

Figure 4: OceanBase cluster structure for the company’s new-energy project

The transformed cluster is easy to maintain and has a complete set of ecosystem components. With OCP, we can visually manage and monitor the cluster; its very high MySQL compatibility makes the learning cost for developers extremely low; and the highly available distributed structure guarantees data reliability—all of which are difficult to achieve with traditional technical architectures.

From this project’s application, we saw more possibilities for domestic databases, and internally we are also actively promoting OceanBase across various projects. We still have a few hopes for OceanBase: some projects’ status quo may already be fixed—especially in the early stages of transformation, when there may be no budget to purchase new servers—and we hope OceanBase can improve the operating efficiency of low-spec servers, especially those without SSDs.

(2) Scenario 2: A New Metro Line Project in a Provincial Capital

A provincial capital opened a new metro line, which carries the core tasks of efficient operation and digital management. In scenarios such as station operations, equipment monitoring, and maintenance management, it needs to handle the real-time storage, querying, and analysis of massive amounts of data. To meet the business’s needs for high reliability and high scalability in data management, the line adopted the OceanBase database to build a stable and efficient data foundation, supporting the smooth operation of the entire line’s business.

Line operations involve equipment-status monitoring data, as well as fault and alarm data from maintenance; the data scale grows continuously with operating time, posing stringent challenges to the database’s storage and processing capabilities.

This project chose OceanBase because of the following characteristics:

• Powerful distributed capability. OceanBase supports horizontal scaling and can seamlessly handle the explosive growth of metro business data, ensuring system performance doesn’t degrade as data increases.
• High-availability assurance. Metro operations systems can’t tolerate interruptions; OceanBase’s multi-replica mechanism and automatic failover enable high availability of the database service, guaranteeing that critical systems such as ticketing and monitoring run stably 24/7.
• Compatibility and usability. Compatible with MySQL syntax, it has a low cost of integration with the metro’s existing business systems, the development team can get up to speed quickly, and it reduces the difficulty of system migration and modification.

The project’s server configurations before and after transformation are shown in Table 2.

Table 2: Server configurations before and after the project transformation

Before using OceanBase, a traditional relational-database architecture was used; the server-cluster scale was fixed, and in the face of surging data, scaling was difficult and costly, with a risk of single points of failure. After adopting OceanBase, with its distributed architecture at the core, only a relatively streamlined server-cluster configuration is needed, and data growth can be easily handled through horizontal scaling. Its elastic compute-resource allocation mechanism makes server-resource utilization more efficient, meeting business needs without large-scale hardware investment.

In addition, after the OceanBase transformation, stability improved significantly. Since going live, there has been no business interruption caused by database-layer problems. In the face of high-frequency writes and complex query scenarios for equipment-monitoring data, OceanBase has consistently run stably, providing solid support for the real-time maintenance of metro equipment. Operations-efficiency improvements are mainly reflected in the boost from OceanBase’s automated-operations features, such as auto-scaling and self-healing, which greatly reduce the operations team’s workload. Complex operations that previously required manual intervention can now be completed automatically by the system, improving operations efficiency by more than 20%.

Although OceanBase has already demonstrated outstanding value on this line, there’s still room to explore its potential further in the future: for example, digging deep into OceanBase’s features for real-time data-analysis scenarios, combining them with metro passenger-flow patterns to optimize operation-scheduling strategies; and strengthening the technical team’s training on OceanBase’s advanced features, so that database capabilities integrate more deeply with business innovation. We believe that as the technology continues to iterate, OceanBase will create a more efficient and intelligent data-management experience for more rail-transit lines, continually leading smart-metro construction to new heights.

V. Future Plans: Expanding the Scope of OceanBase Usage

OceanBase is a scalable, highly available, high-performance, natively distributed database system with powerful data-processing capabilities that can support the needs of various business scenarios. In the future, we plan to apply OceanBase to a wider range of business areas, mainly across the following four dimensions.

(1) Business type. Expanding from business data to real-time data, and further to the system’s real-time data and historical data, to better meet the needs of different business scenarios and improve data-processing efficiency.

(2) Business scope. Moving from the central control center toward multi-level collaborative clusters, to better support large-scale business scenarios and improve system reliability and other performance.

(3) Cluster scale. Moving from a high-spec small cluster to a high-spec large cluster, and gradually evolving into a multi-cluster scale, to better meet large-scale data-processing and scalability needs.

(4) Business direction. Using new-energy projects as an entry point, gradually applying OceanBase to industries such as heating, metro transportation, and smart buildings, to better support these industries’ digital transformation and innovative development.

In Figure 5, we currently use OceanBase only at the central control level. We hope that as OceanBase develops, we can more conveniently fuse and synchronize OceanBase data across different clusters at multiple levels, ultimately achieving a unified database across multiple clusters and business types, and gradually promote OceanBase to other projects.

Figure 5: Outlook for application in the new-energy field

In addition, we are very optimistic about OceanBase OBKV’s NoSQL capabilities for building a more comprehensive integrated database. We are confident in OceanBase’s future and look forward to OceanBase bringing us higher performance, lower costs, and better returns, providing stronger support for the company’s business growth.

Finally, we’d like to recommend the WeChat account of Lao Ji, the head of OceanBase open source: “Lao Ji’s Tech Talk.” It continuously publishes all kinds of technical content related to #Database, #AI, and #Tech Architecture. If you’re interested, feel free to follow!

“Lao Ji’s Tech Talk” not only hopes to keep bringing you valuable technical sharing, but also hopes to contribute to the open-source community together with everyone. If you recognize the value of the OceanBase open-source community, light up a little star ✨! Every Star you give is the motivation behind our efforts.