Comprehensive Overview of OceanBase 2.2: Architecture, Core Features, and Enterprise Solutions

Today, Qing Tao from Ant Group's OceanBase team delivers a detailed presentation on OceanBase 2.2, introducing the product’s positioning as a commercial, distributed relational database designed to replace Oracle and MySQL in high‑traffic financial scenarios.

The talk reviews OceanBase’s nine‑year evolution, from its first deployment in Taobao’s favorite‑list service to successive versions (0.4, 1.0, 1.4, 2.0, 2.2) that added MySQL compatibility, Oracle‑compatible SQL, and large‑scale production use in Alipay, NetBank, and Nanjing Bank.

Key external customers now include NetBank, numerous city‑ and rural‑commercial banks, as well as insurance and securities firms that have migrated core business data to OceanBase.

Six core product capabilities are highlighted: (1) high availability with three‑replica design and RTO≈30 s, RPO = 0; (2) native distributed architecture supporting online scaling, load balancing, and multi‑site deployment; (3) compatibility with common Oracle and MySQL syntax (focus on Oracle); (4) high performance demonstrated by 25.6 k TPS during Alibaba’s Double‑11 and a TPC‑C result of 60.9 M tpmC; (5) low cost using commodity x86 servers, SSDs, and 10 GbE; (6) multi‑tenant capability that treats the cluster as a shared resource pool.

Version 2.2’s core functions are explained: a cluster consists of at least three zones, each zone containing multiple OBServer processes (single‑process SQL + storage engine) and a central RootService. OBServer consumes most CPU, memory, and disk on its host, forming a large pooled resource (e.g., 9 nodes → 270 CPU, 1.8 TB RAM, 36 TB storage).

The resource pool is divided into an internal management tenant and business tenants; resources are allocated on demand, enabling database provisioning within a minute. Data is partitioned at the table‑partition level, with each partition replicated three times across zones (leader, follower1, follower2). Replication uses Paxos‑based transaction logs (clog) to achieve strong consistency, and failover occurs at the partition level without data loss.

OBProxy acts as a stateless SQL router: it parses incoming statements, determines the target partition’s leader, forwards the request, and returns results. Multiple OBProxy instances are typically placed behind a load balancer (e.g., F5) for high availability.

SQL compatibility is presented as two parallel tracks: MySQL‑style features on the left and Oracle‑style features on the right, with current emphasis on expanding Oracle compatibility (≈75 % data types, 86 % functions, stored‑procedure support, read‑committed and serializable isolation levels).

Transaction processing uses a two‑phase commit protocol based on Paxos, providing strong consistency and transparent distributed transactions; autonomous transactions are also supported.

The surrounding ecosystem includes OCP (OceanBase Cloud Platform) for automated operations, ODC (OceanBase Developer Center) for secure developer access, and OMS (OceanBase Migration Service) for real‑time sync and cut‑over from Oracle/MySQL to OceanBase, illustrated by a banking migration case study.

Disaster‑recovery is achieved through the “two‑site three‑center” topology (three replicas across three data centers) with optional five‑replica (three‑site five‑center) configurations for workloads that cannot tolerate performance degradation after a failure.

In summary, OceanBase 2.2 delivers a low‑cost, highly available, scalable, and high‑performance distributed relational database with cloud‑like multi‑tenant features, making it a suitable Oracle‑compatible solution for financial‑grade, geographically distributed applications.