本文转载自CSDN，已获作者授权。

作者简介：苑泽福（阿福），个人开发者，Greenplum中文社区资深成员，OceanBase社区资深成员，曾供职于鼎兴达、瀚高，拥有丰富的数据库开发运维经验，近年来一直专注于分布式数据库研究与推广。

近些年国产数据库如雨后春笋般冒出并遍地开花。据某技术平台不完全统计，国产数据库（见图 ）已达 200余个，对于这些数据库的名字，即使作为多年数据库从业者的我，也有很多是第一次听说。在这竞争激烈的数据库行业里，要想长久占据一席之地，顺应市场发展并打磨好自己的产品才是硬道理。

图1 国产数据库部分截图

数据库发展需顺应市场变化

业界有一句老话叫作 “市场永远是对的”，大概意思是当前市场表现了所有影响因素，任何事物都应该遵循当前市场的发展规律。纵观国际市场数据库发展状况，曾经的数据库老大 Oracle 因为布局云计算太晚已经被亚马逊、微软甩开很长一段距离，老牌数据库 Db2 几乎没落；云数据仓库 Snowflake、云数据库 CoackRoachDB 等产品因为顺应云计算发展而一骑绝尘。在国内数据库市场，从早期集中式数据库需求旺盛的四朵金花时代，大步跨入当前集中式、分布式数据库势均力敌的百花齐放时代。在分布式数据库领域，为顺应市场发展不断改变自身的当属OceanBase ，从早期只服务淘宝收藏夹的简单业务，到 SQL 和 ACID 的支持，再到后来的多租户细粒度资源管控，现在又推出单机分布式一体化版本，在追求极致服务市场的路上，OceanBase 从未停歇。从整个市场上看，有能力有魄力频频做大版本变动的数据库，可谓是少之又少。

众所周知，OceanBase 社区版于 2021 年 6 月 1 日宣布开源，开放 300 多万行核心代码构建开源生态。开源开放不止意味着把自研数据库拿出来给大家用，还意味着 OceanBase 不能像以往一样只专注于金融类业务场景了，迎面而来的是各种各样的场景和需求。在开源后的短短一年多时间里，OceanBase 不断“挑战自我”，打磨内核能力，修复周边 bug。从数据库排行榜（见图2）中能看出市场也给予了 OceanBase 正向反馈。

图2 墨天轮数据库排行榜

今年云栖大会上，OceanBase 社区版4.0发布，不仅有许多亮眼的功能，还刷新了数据库的架构，在业界引发热烈讨论。本文我们就来一起聊聊，OceanBase 从分布式到单机，再从单机到分布式，在遵循市场发展规律的同时到底发生了哪些变化。

从分布式到单机，自我能力突破

OceanBase 自诞生以来，走的一直是分布式 NewSQL 的路，像其他类似产品一样，比如 CockRoachDB、YugaByteDB 等。分布式 NewSQL 从场景上来讲，是为了解决单机数据库在数据达到一定体量后性能急剧下降的痛点，当然在国产数据库发展如火如荼的今天，很多时候也被用来当作替换 Oracle 的首选。从实际的应用效果来看，分布式数据库在金融、运营商等核心业务的替换上，也扮演了重要角色。相比集中式数据库无论从性能、数据承载量、核心业务 RTO 和 RPO 保证上，达到的效果都比较令人满意。

分布式与资源的天然博弈

任何事物都具有两面性，分布式数据库在极力保证高可用、高性能的同时，也引入了一些问题：

• 分布式架构会增加事务处理成本，跨节点事务处理可能涉及多节点 JOIN、两阶段事务提交等。
• 代理层的引入，多一层网络转发，网络成本增加。
• Paxos 协议使数据至少三副本，存储空间层本增加。

为了尽量缓解这些缺陷带来的“疼痛”，实际生产过程中通常会通过提高硬件配置来解决，比如引入 I/O 性能更高的 SSD 硬盘、节点服务器之间采用带宽更高的万兆网络、服务器配置更多的内存以缓存更多的数据。过高硬件的投入，对很多正在业务发展初期的中小企业来说，无疑是一个巨大的负担。很多时候，在客户选型过程中，这些都会影响到最终的决策，尤其是在成本上。笔者曾经不止一次给朋友和客户推荐过分布式数据库，均由于公司对数据库所能提供的资源有限而放弃。

笔者曾经针对小数据量简单对比过 PostgreSQL 11 和 YugaByteDB 的 sysbench 性能。从下面的压测结果指标也能看得出来，引入了分布式组件的 YugaByteDB ，能力仅达到 PostgreSQL 的四分之一。在数据体量不够大时，引入一些分布式特性反而会增加资源整体的消耗，降低性能。

YugaByteDB 简单压测：

[ 300s ] thds: 16 tps: 24594.17 qps: 24594.17 (r/w/o: 24594.17/0.00/0.00) lat (ms,95%): 0.78 err/s: 0.00 reconn/s: 0.00

Throughput:

    events/s (eps):                      24240.1303

    time elapsed:                        300.0030s

    total number of events:              7272111

Threads fairness:

    events (avg/stddev):           454506.9375/16158.17

    execution time (avg/stddev):   299.6535/0.01

PostgreSQL 11 简单压测：

[ 300s ] thds: 16 tps: 92068.28 qps: 92068.38 (r/w/o: 92068.38/0.00/0.00) lat (ms,95%): 0.21 err/s: 0.00 reconn/s: 0.00

Throughput:

    events/s (eps):                      92761.8210

    time elapsed:                        300.0019s

    total number of events:              27828723

Threads fairness:

    events (avg/stddev):           1739295.1875/941.82

    execution time (avg/stddev):   299.0144/0.01

OceanBase 的自我突破

笔者个人认为，OceanBase 在架构设计之初针对以上提到的中小企业资源有限的场景也是做了考虑的，从图3的常用部署框架中我们可以看到，应用之下的数据库层由两部分构成：无状态的 OB Proxy 和有状态的 OB Server。做过 OceanBase 3.x 版本手动部署的朋友应该印象比较深刻，每一个 OB Server 都是一个单独的服务，可以直接接受应用程序的增删改查。在不考虑分布式特性的前提下，一台 OB Server 服务器也能支撑简单的单机业务。但是在实际生产使用过程中，OceanBase 3.x 不建议大家采用单机部署，因为 3.x 版本暂未正式支持单机部署，性能上单机版本也不如 MySQL 有优势。

图3 OceanBase 常用部署架构

从用户实际场景来看，单体式数据库市场是长期存在的。那么让 OceanBase 单机可用甚至好用，从 OceanBase 3.x 到 OceanBase 4.x 的进阶调整，我看到了两个变化。

1. 降低单机部署成本：解决用户普遍反映的资源消耗之痛，让更多人可以轻松入手。

2. 提升单机运行性能：为更多有单机 MySQL 生产需求的用户，提供更好的替换方案。

首先，为了降低单机部署成本，OceanBase 4.0 对 OB Server 做了很多深度优化，包括降低 CPU、内存、磁盘空间对服务器的要求，支持 4C8GB 的最小规格部署配置；提供了单机 all-in-one 版本部署包，支持 2 分钟快速拉起单机服务。这些优化带来的直观体验是，很多之前无法亲自上手的小伙伴也可以在自己的笔记本电脑上进行 OceanBase 开发和测试了。在 11 月初拿到了 4.0 版本的发布包后，我也迅速进行了体验测试，all-in-one 部署包使用起来确实很方便，并且对资源的消耗降低，不必再担心分配了 4C8GB 资源但是服务却无法启动的问题。

其次，为了提升单机运行性能，进而也能完善分布式运行性能，OceanBase 做了很多改进，包括：向量化引擎开源，可以提升复杂查询性能，降低复杂查询响应时间；数据编码开源，可以进一步提升压缩比例，为客户节约存储空间，同时也降低分布式部署时三副本对存储空间的损耗；支持租户级备份，提供更灵活的备份恢复策略；MySQL 兼容性完善，逐步为替换单机 MySQL 做准备。

简单总结一下，从分布式可用到单机可用，对于 OceanBase 来说，是一个自我突破的过程，架构的大调整也意味着官方承认 3.x 版本存在一些架构不足，不能支撑单机能力的提升。还是那句话，在追求极致服务市场的路上，OceanBase 从未停歇。当前的 OceanBase 4.0 单机版本的性能指标已经部分超越 MySQL，随着版本迭代更新，我相信 OceanBase 的性能优势会越来越明显，在满足中小企业市场对单机数据库的需求也会越来越有优势。

从单机到分布式，殊途同归

纵观当前数据库行业，任何一款单机数据库，随着客户业务量增长、数据量增大，都会面临性能瓶颈，或者伴随着客户数据重要性的提升，必然会提出高可用的要求，任何一种负责任的数据库解决方案，都不会让客户的数据在单机上裸奔。

我们一起来看看行业内一些经典的解决方案是如何处理这些问题的。

备注：任何一款数据库都存在多种高可用/性能解决方案，本文受限于笔者经历，只部分引用，并不能以偏概全，所有引用仅用于本文特定论述场景。

Oracle 共享存储架构

Oracle 在这么多年的单体式关系型数据库行业里，一直扮演龙头老大的角色，一直被模仿从未被超越。当 Oracle 遇到单机性能瓶颈，或客户有高可用需求时，通常会采用 Oracle RAC 架构，如图4是一张 Oracle 19C 的 RAC 集群架构图，其底层采用共享存储，存放数据文件；上层采用多台服务器，扩展计算性能。据 Oracle 官方文档，RAC 集群最多支持 168 个节点，根据实际生产使用经验，集群节点数超过 10 个，基本没什么意义，网上能找到的公开资料显示，4-6 个 RAC 节点的性能最好。

图4  Oracle 19C 的 RAC 集群架构

MySQL 分库分表架构

受益于互联网的发展，MySQL 一直稳居开源数据库头把交椅。MySQL 在处理性能瓶颈及高可用问题时，通常采用分库分表结合binlog 日志复制的方式，比如MyCAT、ShardingSphere。如图5是一张 ShardingSphere 架构图，底层的数据库，通过 Sharding-Proxy 指定的规则，将数据进行分片，分布到不同的数据库节点（橙色）上。这种轻量级解决方案，曾经是解决 MySQL 性能瓶颈的不二之选。但是像其他技术解读文章提到的一样，中间件解决方案，并不能完全发挥数据库自身优势，覆盖的场景往往是有限的。并且把数据库使用的复杂性带给了用户，体验比较差。

图5 ShardingSphere 架构

PostgreSQL Citus 双层架构

Citus 的架构就比较有意思了，Citus 是以 extension 插件的方式对外提供分布式能力（不了解的朋友可以查询一下 PostgreSQL extension 架构），它采用了双层架构：Coordinator + Worker。体量较小的数据，可以直接放到 Coordinator 节点上，一旦数据体量增加，可以将表一键转化为分布式表，将数据存储分片存储到 Worker 节点。这种架构使用较为灵活，特别是在微软收购 Citus 后，将 Citus 所有核心能力均开源。但是这种架构欠缺一整套解决方案，例如：高可用仍然需要自行配置流复制、集群组建没有一体化监控运维工具等。

图6 PostgreSQL Citus架构

OceaBase 4.0 单机分布式一体化架构

上面各家单机关系型数据库，针对性能和高可用的解决方案，要么像 Oracle 聚焦集群性能损失扩展性，要么聚焦扩展性损失单机综合能力。在 OceanBase 3.x 阶段，其作为一款高性能 HTAP 分布式数据库，提供了高性能、灵活的扩展性、高可用性和可管理性等能力。在升级到 OceaBase 4.0 的单机分布式一体化架构后，不仅提供了分布式能力的进一步提升，还提供了单机生产可用的能力，相比 3.x 版本，OceanBase 4.0 做了以下改进。这些能力的提升和完善，让 OceanBase 4.0 兼具上面几种解决方案各自的优势。

• 自适应日志流：从以表分区为单位提升为以 Unit 为单位，减少分布式操作的代价，尤其是日志。
• 支持超大事务：重新设计事务引擎，提升分布式多场景应对能力。
• RTO < 8s ：全新的自动选主协议以及全面的探活机制，将故障场景下系统恢复时间从 30s 降低到 8s。
• NTP 服务优化：取消 NTP 依赖，将时钟偏差从 100ms 提升到 2s，提升集群稳定性。
• 支持全链路追踪：OceanBase v4.0 版本设计了一套全链路追踪的机制，能够提升全链路问题定位的效率，贯穿从业务 APP > 客户端驱动(JDBC, OCI) > 代理（OBProxy）> 数据库节点（OBServer）到全部流程。

在这些能力的加持下，OceaBase 4.0 的单机分布式一体化架构，给大家带来了一种新的选择。当大家的数据库需求比较小，只需要单体数据库时，可以从 OceanBase 单机版本入手，随着业务发展、数据量增加，对数据库的要求越来越高，此时可以无缝进阶为 OceanBase 集群，自带多副本高可用，统一访问入口对应用透明，读写分离提升整体性能，分布式架构支持灵活扩展。

图7 OceaBase 单机分布式一体化架构

经过多年市场验证，分布式数据库已经成为当前数据库发展的主要趋势，包括前面提到的以 OLTP 业务见长的 CockRoachDB、YugaByteDB 及以 OLAP 业务见长的 Greenplum、ClickHouse 等。在国产数据库领域，也有很多优秀的分布式数据库产品已经在金融、互联网等场景替换并超越 Oracle 等传统产品。随着 OceanBase 社区版4.0 的正式上线，充分发挥架构在单机能力基础之上的分布式能力，其分布式集群一定会带来不一样的体验。

架构升级取决于需求推动

我们传统使用数据库的逻辑通常是从单体式数据库入手，此时如果遇到高可用需求，会采用日志复制的方式增加热备副本（也称为主备架构），随着数据量的增加，单体式数据库不能满足数据存储和查询的要求时·，会采用分库分表的数据分片架构，或者直接从单体数据库迁移到分布式数据库（见图8），这样的架构进阶其实是比较复杂且代价高昂的。

图8 架构需求演进

显然这种方式已经成为过去十几年解决单体数据库问题的主流方式，一旦业务量达到一个数量级，领导关心的是尽快解决问题，而不是如何优雅而低成本的完成架构升级，即使在这个过程中有一些波折也是能容忍的。但这也表明，市场需要的恰恰是简单且低成本的架构升级方式。

通过本文对传统分布式数据库架构解决方案及单机分布式一体化架构方案的梳理，能够感知到，我们在业务上如果采用单机分布式一体化架构方案，逻辑就可以简化为业务初期采用单机版本支撑，随着数据量的增加，可以适时转换为分布式集群（见图9）。该方案不仅可以节约数据迁移的成本，降低架构复杂度，还能在保障业务连续性的同时起到提升数据库性能的作用。相比而言，留给用户的只有简单。

图9  单机分布式一体化架构方案

借用OceanBase 对单机分布式一体化版本的定位，“兼顾分布式架构的扩展性与集中式架构的性能优势，用一套架构同时支持交易处理和分析处理的混合负载。在单机和分布式两种部署场景下具备相同的事务 ACID 能力。“不得不说，这种全新的架构方式，给大家带来了新的数据库使用思路，这样的架构演进也是符合市场需求与发展规律的。