Evolution and Architecture of OceanBase Distributed Database
OceanBase, a fully proprietary distributed NewSQL database, has evolved over eight years to support high‑availability, strong consistency via Paxos, flexible replica management, OBProxy routing, LSM‑Tree storage, and migration tools, enabling seamless scaling, disaster recovery, and Oracle compatibility for large‑scale financial services.
OceanBase, a 100% self‑owned NewSQL database, originated in 2010 and has grown into a commercial, ACID‑compliant, distributed relational database used extensively in Alibaba’s Alipay core services.
Core Architecture : The system consists of multiple zones, each containing several OBServer nodes. Data is replicated three‑way across zones, providing strong consistency and high availability through a Paxos‑based consensus protocol.
Paxos Protocol : Each partition has a leader and two followers. The leader’s transaction log is replicated to followers, and Paxos ensures that a majority of replicas persist the log, enabling fast leader election and guaranteeing zero data loss.
OBProxy : To simplify client access, OBProxy acts as a lightweight SQL parser and location cache. It determines the correct OBServer for a query, forwards the request, and returns results, reducing client‑side routing complexity.
Storage Engine : OceanBase uses an LSM‑Tree design. Writes are first accumulated in memory as incremental data, then merged to disk in bulk, which reduces random I/O and enables sequential writes, lowering hardware costs while providing row, block, and bloom‑filter caches for fast reads.
Architecture Evolution : Over the years, OceanBase has tackled challenges such as seamless scaling during peak traffic, multi‑active‑active deployments, cross‑region disaster recovery, and flexible replica type changes (leader, follower, read‑only) to support elastic promotions.
Elastic Promotion Example : By deploying read‑only replicas in remote zones and later promoting them to followers, the system can temporarily expand from three to five replicas during a promotion, then revert back without service interruption.
Disaster Recovery via Hot‑Standby : For customers with limited data‑center availability, OceanBase can place multiple replicas across two cities (e.g., Beijing and Suzhou). If a primary site fails, remaining replicas continue serving, and a fail‑over process can promote standby replicas to full‑function nodes.
OMS Migration Service : OceanBase Migration Service (OMS) provides an end‑to‑end solution for moving workloads from Oracle, MySQL, etc., to OceanBase. It includes compatibility assessment, SQL validation, and a one‑click cut‑over with built‑in, lossless rollback capabilities.
Future Directions : Upcoming OceanBase releases aim to improve Oracle compatibility (targeting 20‑30% now), achieve deeper compute‑storage separation for cost‑effective scaling, and add HTAP capabilities to support mixed transactional and analytical workloads.
Overall, OceanBase demonstrates how a proprietary distributed database can evolve to meet the demanding scalability, availability, and migration needs of large‑scale financial services.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
