4.0体验站｜OceanBase 4.0，从分布式到单机，从单机到分布式
作者：阿福（苑泽福），OceanBase 社区版深度用户、社区文档贡献者，Greenplum中文社区资深成员，曾供职于鼎兴达、瀚高，拥有丰富的数据库开发运维经验，近年来一直专注于分布式数据库研究与推广。本文为阿福对OceanBase 社区版 4.0 的测评体验，欢迎大家评论区与作者探讨交流！
图2 墨天轮数据库排行榜
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.01PostgreSQL 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 有优势。
纵观当前数据库行业，任何一款单机数据库，随着客户业务量增长、数据量增大，都会面临性能瓶颈，或者伴随着客户数据重要性的提升，必然会提出高可用的要求，任何一种负责任的数据库解决方案，都不会让客户的数据在单机上裸奔。
我们一起来看看行业内一些经典的解决方案是如何处理这些问题的。
*注：任何一款数据库都存在多种高可用/性能解决方案，本文受限于笔者经历，只部分引用，并不能以偏概全，所有引用仅用于本文特定论述场景。
▋ 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 集群，自带多副本高可用，统一访问入口对应用透明，读写分离提升整体性能，分布式架构支持灵活扩展。
经过多年市场验证，分布式数据库已经成为当前数据库发展的主要趋势，包括前面提到的以 OLTP 业务见长的 CockRoachDB、YugaByteDB 及以 OLAP 业务见长的 Greenplum、ClickHouse 等。在国产数据库领域，也有很多优秀的分布式数据库产品已经在金融、互联网等场景替换并超越 Oracle 等传统产品。随着 OceanBase 社区版 4.0 的正式上线，充分发挥架构在单机能力基础之上的分布式能力，其分布式集群一定会带来不一样的体验。
我们传统使用数据库的逻辑通常是从单体式数据库入手，此时如果遇到高可用需求，会采用日志复制的方式增加热备副本（也称为主备架构），随着数据量的增加，单体式数据库不能满足数据存储和查询的要求时，会采用分库分表的数据分片架构，或者直接从单体数据库迁移到分布式数据库（见图 8 ），这样的架构进阶其实是比较复杂且代价高昂的。
图8 架构需求演进
显然这种方式已经成为过去十几年解决单体数据库问题的主流方式，一旦业务量达到一个数量级，领导关心的是尽快解决问题，而不是如何优雅而低成本的完成架构升级，即使在这个过程中有一些波折也是能容忍的。但这也表明，市场需要的恰恰是简单且低成本的架构升级方式。
通过本文对传统分布式数据库架构解决方案及单机分布式一体化架构方案的梳理，能够感知到，我们在业务上如果采用单机分布式一体化架构方案，逻辑就可以简化为业务初期采用单机版本支撑，随着数据量的增加，可以适时转换为分布式集群（见图 9）。该方案不仅可以节约数据迁移的成本，降低架构复杂度，还能在保障业务连续性的同时起到提升数据库性能的作用。相比而言，留给用户的只有简单。
图9 单机分布式一体化架构方案
借用 OceanBase 对单机分布式一体化版本的定位：“兼顾分布式架构的扩展性与集中式架构的性能优势，用一套架构同时支持交易处理和分析处理的混合负载。在单机和分布式两种部署场景下具备相同的事务 ACID 能力。”不得不说，这种全新的架构方式，给大家带来了新的数据库使用思路，这样的架构演进也是符合市场需求与发展规律的。
历史推荐