Databases 12 min read

How OceanBase Delivers Cloud‑Native Distributed Relational Database Performance and Availability

This article explains OceanBase's public‑cloud deployment, its unique architecture without a central controller, horizontal scaling via partition groups, LSM‑Tree storage design, advanced SQL engine features, ACID‑plus‑Availability guarantees, and real‑world performance records, illustrating why it suits high‑availability financial workloads.

Alibaba Cloud Developer
Alibaba Cloud Developer
Alibaba Cloud Developer
How OceanBase Delivers Cloud‑Native Distributed Relational Database Performance and Availability

Public Cloud OceanBase Deployment

OceanBase is a native distributed relational database fully controllable at the code level. The public‑cloud OceanBase product (Figure 1‑1) uses three‑replica 3‑AZ deployment with the Paxos protocol to ensure data consistency across nodes, providing zero‑RPO and RTO < 30 seconds, achieving data‑center‑level high availability and future three‑region five‑center designs for city‑level failover. It supports flexible multi‑tenant resource management, allowing on‑line scaling of instances.

From a security and availability perspective, OceanBase is well‑suited for financial scenarios; while regulated financial services cannot run on public clouds, similar workloads such as insurance and funds can benefit.

Figure 1-1
Figure 1-1

OceanBase Architecture Principles

Unlike most distributed systems, OceanBase has no separate master server. Its global controller is the RootService integrated into an ObServer. The system dynamically elects an ObServer to run RootService, and automatically re‑elects a new one upon failure, simplifying deployment while reducing cost.

OceanBase achieves unlimited horizontal scaling through partitioning (Figure 1‑2). Each partition is replicated three times across different servers, making the whole system appear as a single logical table to users. OBProxy, the access proxy, routes requests to appropriate servers and delivers million‑level QPS on ordinary hardware.

Figure 1-2
Figure 1-2

To mitigate the performance penalty of two‑phase commit, OceanBase groups frequently accessed partitions into a "partition group" and schedules them onto the same server, reducing distributed transaction overhead. It also optimizes the two‑phase commit protocol by reconstructing global transaction state from participants instead of writing coordinator logs.

OceanBase Storage Architecture

OceanBase follows a shared‑nothing design; each OBServer has its own storage engine using an LSM‑Tree structure. Writes first go to an in‑memory MemTable, then are merged into on‑disk SSTables. Multi‑level SSTable compaction and various caches (block, row, log, position) improve query performance, with per‑tenant cache isolation.

Data compression uses algorithms such as LZ4 and ZSTD. A two‑layer compression (encoding + generic compression) reduces storage to about one‑third of MySQL InnoDB for the same dataset, while the LSM‑Tree architecture ensures zero impact on write performance.

Figure 1-3
Figure 1-3

OceanBase SQL Engine

OceanBase supports both Oracle and MySQL compatibility. It offers soft parsing like Oracle, parameterized SQL, and a plan cache that stores parsed templates and execution plans, eliminating repeated hard parsing overhead.

Built on the LSM‑Tree storage, OceanBase includes a cost model with statistics, enabling an optimizer to choose optimal access paths. It supports Nest Loop, Hash Join, Merge Join, and distributed SQL execution, with dynamic plan binding for emergency or efficiency scenarios.

Figure 1-4
Figure 1-4

OceanBase AACID Features

OceanBase adheres to ACID and adds an extra "A" for Availability. Paxos‑based multi‑replica logging ensures zero data loss on node failures. Consistency uses MVCC with multi‑version reads; isolation supports Oracle‑style read‑committed and serializable levels. Durability follows the traditional write‑ahead log approach.

Data safety mechanisms include a tenant‑level recycle bin that retains dropped tables for recovery, and flashback queries based on timestamps or SCN, allowing restoration of data to a specific point in time.

In October 2019, OceanBase topped the TPC‑C benchmark with 60,880 tpmC, twice Oracle’s record, and later achieved 61 million transactions per second during Alibaba’s Double‑11 promotion, demonstrating performance comparable to traditional heavyweight databases while running on commodity servers with high compression ratios.

Management tools such as OCP, ODC, and OTA are provided free of charge (aside from database instance fees), offering cluster, tenant, and SQL monitoring, as well as automated plan optimization.

Future Outlook

OceanBase will continue to add practical, high‑efficiency features and expand its ecosystem to meet evolving user needs.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Cloud NativeLSM‑Treehigh availabilitySQL EngineOceanBase
Alibaba Cloud Developer
Written by

Alibaba Cloud Developer

Alibaba's official tech channel, featuring all of its technology innovations.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.