国产主流数据库调研

作者： angryart 原文来源：https://tidb.net/blog/4a70bb91

国产数据库现状

2018 年，我国数据库市场目前仍被国外厂商主导，主要包括 Oracle、IBM、微软、SAP 等，且国外品牌的市场份额一直在 70% 以上。2018 年，在国家政策的引导和支持下，国产传统数据库厂商稳步前进，互联网公司的自研数据库取得突破。国产数据库企业在可靠性、易用性等方面不断拓宽业务空间，并结合新技术革新推动数据库云化、服务化。目前，南大通用用户已经覆盖 17 个国家，国内 32 个省级行政区。部署总节点数超过 6500 个，总数据量超过 100PB，2018 年、2019 年连续两年入选 Gartner 分析型数据库管理解决方案魔力象限。人大金仓申报的“数据库管理系统核心技术的创新与金仓数据库产业化”项目荣获 2018 年度国家科学技术进步二等奖，产学研的融合进一步助力国家信息化建设。巨杉数据库坚持从零开始打造分布式开源数据库引擎，是中国首家连续两年入选 Gartner 数据库报告的数据库厂商。

新兴数据库发展浪潮日益高涨，多模数据库也备受关注。2019 年，华为发布了全球首款人工智能原生（AI-Native）数据库 GaussDB 和分布式存储 FusionStorage 8.0，并持续入选 Gartner 数据库报告。腾讯云推出云原生数据库 CynosDB，该款数据库的单节点读性能达到惊人的 130 万 QPS，并且是业界第一款全面兼容 MySQL 和 PostgreSQL 的高性能企业级分布式云数据库。阿里云的云原生数据库 POLARDB 闯入 2018 年全球数据库魔力象限的远见者（Visionaries）象限，为国内首次。

以上摘自中国电子信息产业发展研究院 的《2018-2019 年中国软件产业发展蓝皮书 行业篇》对数据库现状的描述。

再过两年形势大变，2021 年 6 月 1 日 OceanBase 数据库产品正式开源，而且开源的是最新版本 OceanBase3.1，表现得诚意满满。当初 OceanBase 曾经开源一段时间，但是马上就闭源，后面一直以商业软件定位。OceanBase 此番举措很大可能性原因是因为受了 TiDB 的影响 ，作为名门望族的儿子，OceanBase 背靠阿里巴巴、蚂蚁集团，能力肯定是有的，但是人气一直不如 TiDB。TiDB2017 年才开始开源，2018 年还是一个名不经传的小伙子，2020 年发布了 TiDB4.0，版本最大的创新是加入 Tiflash 列式引擎，这标识 TiDB 已经具备 HTAP 的条件，而 2021 年再次发布 TiDB5.0,Tiflash 的版本有一个大迭代。最重要 Tiflash 的使用用户覆盖面广，包括有互联网行业、制造行业、金融行业等等， 社区建设得非常不错，博客、论坛随处都可以找到 TiDB 的学习资料。 而 OceanBase 因为商业的性质，大多数人对 OceanBase 只闻其名，不见其影。无论是官方还是百度，关于 OceanBase 的资料少之有少。2020 年，OB 首先建立独立运营的公司，再推出免费的初级认证 OBCA，然后两个月又推 OBCP 中级认证，再过两个月推出了 OBCE 认证，OceanBase 急火攻心的攻势，表明它要扭转乾坤，重夺市场的态度和信心。华为 GaussDB 比 OceanBase 早开源一年，区别于 OB 和 TiDB，华为似乎没有什么雄心壮志成为数据库市场的龙头老大，数据库是信息应用必不可缺的一个基础工具，华为只希望把 GaussDB 打造成一个辅助工具，甚至自己定义了木兰协议，比 apache 协议还友好，openGauss 可以随时商标转让中小企业商业使用。

产品对比考虑因素

主要考虑从数据库关键核心技术以及分布式系统特点各种维度综合进行比较，同时也考虑产品的可用性、稳定性、运维性等用户使用体验因素 ，不考虑数据库的运行性能，因为很难量测，数据库太多调测的东西，每家都有自己的法门。

系统架构

去中心化架构在外部看来, 集群在逻辑上是个整体, 与任何一个节点的通信相当于与整个集群通信，每个节点之间都是平等的。而中心化在集群内部却是阶级分明，职责分清，有些节点要安装 A 服务，有些节点要安装 B 服务，外面只能与指定的节点进行通信连接，数据通信还需要和其它节点打交道。hbase 集群是典型的中心化架构，regionserver 作为数据存储节点和计算节点，同时还需要 hmaster 作集群管控服务管理，zookeeper 提供服务路由和集群状况感知功能，而同是属于 nosql 的 cassandra 就不一样了，Cassandra 属于去中心架构，每个节点都是存储节点，当客户端访问任意一个节点的时候，这个节点临时上升为协调节点 ，按照集群通信协议，它会跟踪解决客户请求相关调度的一系列工作。

工程角度上来说，中心化架构清晰分明，所有的节点都朝着一个中心，通过中心来协调每一个节点的节奏。无论是产品安装还是生产运维，都更容易管理。而去中心化架构，并非中心节点去掉，而是中心节点已经融化到每一个节点，当需要马上使用时激活，设计需要考虑诸多问题，普通节点到中心节点的转换，中心节点宕掉了谁来替代？遇到冲突时通过谁来解决问题？所以去中心化必然是复杂为牲牺代价的。

OceanBase 属于无中心化架构，TiDB 和 OpenGauss 属于中心化架构。

其实，早期的 OceanBase 也是属于中心化架构。那时候,OceanBase 的组件服务分为 rootserver、mergeserver、updateserver、chunkserver，rootserver 负责集群管理和数据分布、副本管理，相当于集群的大脑，而 mergeserver 负责 SQL 协议解析、请求转发、结果合并，updateserver 负责写数据，而 chunkserver 负责读数据。一个读写请求流求后 ，mergeserver 负责建立连接，解析请求后转发相应的 chunkserver 和 updateserver，合并数据返回给客户端 。 如今的 OceanBase，只有 Observer 和 Obproxy，Obproxy 主要面向客户端应用，把请求转发给 observer 集群，得到结果后返回给客户端。如果说早期的 OceanBase 是军工版，那么现代的 OceanBase 是民用版。通过 OCP 在安装 OceanBase 集群的时候，会提示你选择哪一个主机做 rootservice，rootservice 就是 ” 中心 ”。 与去中心化的 elasticserver 一样，OceanBase 提供自由选装的方式，你可以安装一个或多个 rootservice，但是只有一个 rootservice 是主节点，其它的是备节点，如果主节点发生故障，备节点将会托管主节点的工作。

相对于去中心化架构，中心化架构楚河汉界，泾渭分明，但是根据状况也会有适当变动。TiDB 的基础组件服务有计算节点 tidb，管理节点 pd，存储节点 tikv，而 opengauss 却是集群管理模块 CM, 全球事务管理器 GTM，协调节点 CN、存储节点 DN 等等。opengauss 把事务和数据分布等管理职能分开，而 TiDB 却把它们都集中在 PD 上面。opengauss 基于 pgxl 的基础上开发的，计算和存储紧密结合，都在 DN 上面，而 TiDB 却是计算存储分离。共同点是 TiDB 通过 PD 控制管理集群的读写操作和数据分区，opengauss 通过 GTM 管理读写操作，通过 CM 对数据分片进行管理。

集群架构

数据集群分为数据集中集群和数据分片集群。所有表的数据都在同一个节点，这个就是数据集中集群。所有表的数据打散分布在不同的节点上面，这个就是数据分布集群。最初，数据库是单点结构，随着读写压力增大，单点不胜负荷，进而读写分离，这是数据集中最初的雏形，也称为主从架构。所有的数据都写在主节点，从节点从主节点上同步数据，只对外提供读功能。所有的应用业务都是读多写少，如果读压力再多，那么就一主多从，多个从节点分摊读压力。数据集中的特征，无论是一主一从还是一主多从，主节点都是全量数据。

数据集中的弊端很明显，主节点存在单点瓶颈，于是产生了数据中间件技术。针对简单的业务场景，通过中间件可以达到多个节点写数据的效果，但有很多使用限制和不足，不能多表关连 JOIN 或增加维护使用十分困难。这样的环境催生了数据分片模式。

简而言之数据分片是把大量的数据分布均匀在每一个节点上后，对外来看数据还是一个整体，操作使用与单体数据库一样。从 NOSQL 到 NEWSQL 的产品大部分都支持分片模式。分片模式一般分为范围分布和哈希分布，或者综合两种特点的智能分布。

OceanBase 和 TiDB 默认用的是范围分布，，智能分布即类似的数据都放在同一个节点，少量的数据尽量不跨网，大批量的数据均匀放在每个节点，达到本地事务优先，数据计算速度更快。业界有一款既支持集中又支持分片的产品是 mongoDB, 但是 mongoDB 是文档型，opengauss 是唯一一个支持数据集中和数据分片的数据集群。其实数据分片不是很友好，最新的版本还没有应用 raft 协议。opengauss 未来的计算路线，不一定走分片路线，数据集中的瓶颈是存储性能，NVM 介质的使用方式是字节寻址，而且寻址速度更快。未来整个设计是以 NVM 为中心的新数据库，也是 openGauss 未来探索的一个大的方向

首要内存计算

众所周知，内存执行的速度很高，比硬盘不是高一两个级别。TiDB、OceanBase、openGauss 目前不支持首要内存计算，TiDB 和 OceanBase 的处理机制和算法相比 openGauss 更充分利用内存，但是还算不上首要内存计算。真正实现首要内存计算的有 Memql 和 VoltDB 两家，它们是把全量的数据都加载到内存里面，Memsql 号称是世界最快的数据库。先前的 OceanBase 吸收 memsql 的设计思想，它的 updateServer 写数据模块就是巨大的单点 memsql 数据库。为什么后来的 OceanBase 没有 updateServer 模块，笔者猜测内存是巨大的花销。世界没有几家公司能做到阿里巴巴和蚂蚁银行这样的流量。Google spanner 也不支持首要内存计算。值得一提的是，MongoDB 的社区版拥有所有的功能 ，只有上了商业版才支持内存计算引擎。

索引设计

索引一直是数据库的关键核心技术，索引也是数据库区别于基础软件的标志。技术上来说，索引就是数据的数据，索引是元数据，索引花了一部分硬盘空间的开销，却避免全盘扫描，获得快速的数据处理能力。

索引分类极广，早期数据库索引分类有 B 树索引、主键索引、哈希索引、聚簇索引、覆盖索引等等，现在分布式的数据库一般分为一级索引、二级索引、 单键索引、组合索引等等。从 RDBMS 到 NEWSQL，索引技术没有很大变化，都是尽可能的描绘查询数据的特征，再复杂的业务，二级索引也满足了。索引本质上是一个“词语查找技术”，查找词语越接近，越能避免回表。除了全文索引场景，索引可以应用所有的查找业务场景。

三者之中，OceanBase 在索引概念做得比较超前，它提出的全局索引和本地索引比较吻合分布式系统业务场景。TiDB 和 openGauss 显得有老生常谈，还是以前那套，但这并不能说明 OceanBase 比 TiDB 快，索引是数据库调优的其中一个手段。

分区设计

全表的数据默认安装在一个空间里面，通过分区技术，可以把表数据放多个空间里面，这个就是分区技术的作用。如果一个执行 SQL，你确认相关表已经做过索引和分区，并保障索引和分区已经生效，那么数据库优化基本完成了。

分区和索引的区别，分区是一对多，索引却可以做一对一，一对多（哈希索引、位图索引)，一些不适合索引的地方都可以用到分区。例如 HIVE, 一开始 HIVE 支持索引，但是路线图摒弃索引不用，支持分区却保留下来。分区在批处理场景更能发挥作用。

三者之中，还是 OceanBase 在分区概念做得比较超前，它提出二级分区的概念，这是 Tidb 和 opengauss 没有的。到底多复杂的业务才用上二级分区？笔者相信一般的电商使用一级是足够了。间中可见阿里巴巴的应用业务有多复杂。从分区类型来看，OceanBase 支持的功能也比 Tidb 和 opengauss 多。

并发控制

MVCC 是最成熟的并发控制技术，从 RDBMS 到 NOSQL，从 NOSQL 到 NEWSQL 用得都是 MVCC。高并发业务场景，当大量用户对同一个对象进行数据操作时。最终操作可以理解归纳为先读后读，先读后写，先写后读 ，先写后写 4 个状况。先读后读没有问题，MVCC 通过维护数据的多个版本，让读写不阻赛，解决先读后写和先写后读的问题 ，只留下先写后写的问题。过去，先写后写都是通过上锁解决问题，现在，先写后写还是通过上锁解决问题，差别是悲观锁还是乐观锁。乐观锁，从一开始每一个操作都允许被执行，但在事务提交的时刻，进行隔离性和完整约束性的检查，如果有违反事务马上被中止。显然，如果并发冲突少的场景，乐观并发控制方法是适合的。悲观锁，从一开始，即检查每一个操作是否会违反隔离性和完整性约束，如果可能违反，则阻塞这样的操作。如两阶段封锁，用读锁来阻塞另外一个事务的写锁。 2PL 两阶段技术属于悲观的方法，提前对异常现象做了预防。基于时间戳排序的并发控制技术也是悲观的。

TiDB 支持乐观锁和悲观锁，一开始默认是乐观锁，在 v3.0.8 及之后版本默认使用悲观事务模式，openGauss 和 OceanBase 默认悲观锁。

openGauss 基于 pgxc 的架构开始，用的 postgres9.2.4，而 postgres9.2.4 用的是悲观锁。而 Tidb 基于 rocketDB，rocketDB 没有锁的概念，Tidb 早期技术选择了乐观锁，后期 v3.0.8 开始是悲观锁。OceanBase 的目标是 oracle，悲观锁让交易更安全。如今 OceanBase、Tidb 和 openGauss 默认使用金融级别强一致性的安全标准。

计算贴近数据

最简单的计算贴近数据的例子，hbase 的集群一个节点有 regionserver 服务，那么该节点合理也要有 datanode 服务。这样，regionserver 加载数据的时候直接从本机取，而不是跑网络去找。除了服务捆绑同一节点，还有 spark 采用延迟计算避免过多的网络调度。相对 mapreduce 和 spark，MPP 是在所有的机器运行 map 任务，最后数据并合只有一个 reduce 任务,MPP 计算处理引擎某个意义也是让计算贴近数据的处理方式。因为它避免了 shuffle。计算贴近数据的目标是努力减少数据不必要的传输。

现在我们说的是 HTAP 的计算贴近数据，与大数据的计算贴近数据，有一些类似，但是还是有差别。

数据从哪里来，数据要到哪里去，最终数据的价值是要做什么？数据自应用产生，然后保存到 OLTP 处理库，新的数据是热数据，保存久的数据是冷数据，这些数据都要给 OLAP 分析处理，最后更新反映到应用，为应用赋能新的变化是数据最好的归宿。

TiDB 是把应用数据保存到 OLTP 引擎，同时通过 raft 协议有相同一份数据落到 OLAP 引擎，马上就可以进行数据分析。传统数据还需要 ETL，TiDB 避免了不必要的 ETL 的开销，但是 TiDB 的分析模型默认与事务模型一样，事务模型一般不是星型、雪花型，分析模型遇到海量数据进行多个数据集的关联运算会有很多消耗。TIDB5.0 开始支持 MPP，这样会缓解 TIDB 分析的一些压力。TiDB 曾经的广告是适应 30% 的业务分析场景，如果分析更复杂，可以借助 tispark 解决。

OceanBase 只有一个引擎，引擎对数据组织先按行组分割，再从行组内进行按列分割。应用数据保存在引擎，你以后可以对进行事务处理，你可以对它进行分析处理，一物两用。业界 HAWQ 也是一个支持 HTAP 的产品，在存储模型比较灵活，对数据有横切、纵切、纵横切的策略。OceanBase 的目标是 Oracle，肯定行式优化。行式再切列式，不是真正的列式引擎 ，肯定性能打折扣。

OpenGauss 支持建表的时候选择使用行存储引擎还是列存储引擎，从而可以在 OLTP 系统中对历史数据做 OLAP 处理，部分支持 HTAP 的场景。相对 TiDB 没有那么自动化，换言之还是要从行式导数据到列式，实际还是要发生 ETL。好处还是有的，我们可以想好怎么符合业务方向的分析模型。

数据分布

数据分布与数据分区不一样，分区是面向应用开发者，而数据分布是底层的数据存储组织。数据分布是指数据分片按什么样的策略持久化在硬盘上，主要分为两个。一个是数据发散性的特征分布在每一个节点的哈希分布，一个是数据连续性的特征分布在每一个节点的范围分布。

打个比喻，哈希分布是集群中的每个节点身材均称，不肥不瘦。而范围分布让集群每个节点因为集中的特性有些很胖、有些很瘦。OceanBase 和 TiDB 选择了范围分布，因为范围分布找指向性较多的数据，我可能找一两个节点就好，而不是向所有的节点都要一点，这样会有较多的网络消耗。至于太胖太瘦，我就找一个节点实时对它管理，胖的时候减肥切数据到瘦的，TiDB 的 pd 服务和 OceanBase 的 rootservice 负责这个职能，按时对数据进行负载均衡处理。

OpenGauss 支持哈希分布和范围分布，笔者还不知道范围分布怎么用，目前看到一些材料都是哈希分布。

隔离级别

隔离级别是事务之间的隔离级别, 该隔离级别定义一个事务必须与由其他事务进行的资源或数据更改相隔离的程度，业界隔离有 4 个级别

• Read uncommitted 存在脏读

• Read committed 避免了脏读，但是可能会造成不可重复读

• Repeatable read 避免了不可重复读，但还有可能出现幻读

• Serializable 事务依序进行，防止脏读，不可重复读外，还避免了幻读

TiDB 剑走偏锋， 支持的隔离级别是 Snapshot Isolation（SI），它和 Repeatable Read（RR） 隔离级别基本等价，详细情况如下：

● TiDB 的 SI 隔离级别可以克服幻读异常（Phantom Reads），但 ANSI/ISO SQL 标准中的 RR 不能。

所谓幻读是指：事务 A 首先根据条件查询得到 n 条记录，然后事务 B 改变了这 n 条记录之的 m 条记录或者增添了 m 条符合事务 A 查询条件的记录，导致事务 A 再次发起请求时发现有 n+m 条符合条件记录，就产生了幻读。

● TiDB 的 SI 隔离级别不能克服写偏斜异常（Write Skew），需要使用 Select for update 语法来克服写偏斜异常。写偏斜异常是指两个并发的事务读取了两行不同但相关的记录，接着这两个事务各自更新了自己读到的那行数据，并最终都提交了事务，如果这两行相关的记录之间存在着某种约束，那么最终结果可能是违反约束的。

SI 再往上走，就是 SSI（Serializable Snapshot Isolation）, 可串行化的快照隔离是一个乐观并发控制，在这种情况下，如果发生潜在冲突，事务会继续执行而不是中止，寄希望一切相安无事，而当事务提交时（只有可串行化的事务被允许提交时），数据库会检查是否发生了冲突，如果是的话，中止事务并接下来重试。

TiDB 走的是一条技术新路线，它采用的隔离级别与 CockroachDB 一样。

分布式原子性

ACID 事务特性中的原子性，要么是成功，要么是失败，不充许一半成功，有些失败的意外状况。单机数据库因为是本机原子性操作没有任何问题，但是分布式系统的原子性操作不一样，它需要 2PC 去实现。2pc 分为两个阶段，由协调者和参与者一起工作，第一阶段是提交准备阶段 ，每个执行节点做出自己的判断 YES 或 NO，第二阶段协调节点收集需求，如果部分有 NO 就回滚，全部是 YES 就提交。

只要是 OLTP 和写业务的需求，几乎所有的分布式系统都免不了 2PC，2PC 是保障所有的数据节点对数据对象进行操作的一致性。cassandra 廖廖无几的不需要 2PC 的分布式系统之一，我们都知道 HBASE 是 CP，而 cassandra 是 AP，AP 会比 CP，其中一个原因在于 cassandra 是去中心化，每个节点都可以写入数据，另一个原因是 cassandra 采用读写时修复的技术代替 2PC。2PC 一个是复杂的网络操作，会造成大量的性能损耗，但是它却带来事务的稳定性和可靠性。

数据库大厂商都会在 2PC 的基础优化，TiDB 参照 Percolator 模型来对 2PC 协议进行优化。Percolator 模型简化了协调者和参与者的通信流程，让协调节点只跟其中一个 primary 参与通信，一方面，减少了通信开销，另一方面，避免了因为单点故障，commit 阶段部分节点通信失败导致的数据不一致问题。

OceanBase 另辟溪径，2PC 优化如下。

• 协调者不写日志，变成了一个无持久化状态的状态机

• 事务的状态由参与者的持久化状态决定

• 所有参与者都 prepare 成功即认为事务进入提交状态，立即返回客户端 commit

• 每个参与者都需要持久化参与者列表，方便异常恢复时构建协调者状态机，推进事务状态

两者的优化手段不同，笔者认为是由于 TiDB 用的是 RAFT 协议，而 OceanBase 用的是 PAXOS 协议有关，这里下节我们再说。我们聊一下 openGauss 的为什么没有 2PC。

前面我们说了 2PC 是一个保障集群事务原子性的技术。而一主一从或一主多从本质上是单机系统，只有一个节点接受写数据，其它节点再从这个节点同步数据，所以用不上 2PC。至于单点写性能，未来 openGauss 可能会探索 NVM 的新型存储。早期的 OceanBase 架构也是单点，updateserver 是一个巨大的只允许写入数据的单点的内存数据库，因为是单点所以也不需要 2PC, 笔者把这时候的 OceanBase 称为军工级数据库，你想像一下阿里巴巴的业务一天要装入多少的数据。民用级 OceanBase 简单廉价了很多，那是为了每个人都可以用得起数据库。

分布式事务一致性

分布式是原子性和分布式事务一致性的不同点是，分布式原子性是让所有的节点对集群操作达成一致认识，而分布式事务一致性是让所有的节点对数据值达成一致认识。共同点是分布式原子性和分布式事务一致性在分片模式才有。分片也称为副本，即支持写数据也支持读数据，事务一致性决定读写顺序和读写权重以及意外处理、响应返回客户端等等。

分布式事务一致性分为 Paxios、RAFT、ZAB 等等，我们聊聊老大 Paxos，某个程度上 RAFT 和 ZAB 都是 Paxos 衍生出来的。Paxos 协议非常复杂，理论非常高深，难以应用于信息工程实践上。据说 goole spanner 用的就是 paxos，goole spanner 是世界上规模最大、应用最多的 NEWSQL。Paxos 的节点人人平等，每一个节点是一样的，既能对外提供访问，又能对内互相协调。但没有多少人能达到 GOOGLE 工程师的水平写好这样的算法，基于 Paxos 协议的 Raft 强化 LEADER 的作用 ，通过 LEADER 来保证分布式一致性。分布式一致性问题用 Raft 的方式分为 3 个子问题来简化算法： Leader 选举、日志复制、安全保证。

Raft 是一个基于日志的算法，spanner 的开源版 CockroachDB 用的就是 Raft,mongodb 用的也是 Raft。另外一个 ZAB 与 RAFT 差不多，都是 PAXOS 的不完整版。但是 Paxos 与 Raft 用的是 state machine replication(active replication),ZAP 用的是 primary backup（又称 passive replication)，两种实现差异如下

• state machine replication: 节点之间复制的是操作，然后每个节点自己执行操作。

• prmary backup： 节点执行操作，将执行结果复制给其它操作。

OceanBase 基于 Paxos，而 Tidb 基于 Raft 协议，OpenGauss 暂不支持，以后可能支持 Raft 协议。

存储机制

存储引擎主流核心技术分为两块，一个是 B 树，一个是 LSM 树。

B 树是基于页面的 B 树数据结构管理方式，页是数据库的存储单元，数据库是基于磁盘的存储引擎，因此存储格式的设计遵从段页式设计，存储结构需要以页面为单位，方便与操作系统内核以及文件系统的接口进行交互。也是由于这个原因，页面的大小需要和目标中一个 BLOCK 的大小对齐。在比较通用的 LINUX 内核中，页面大小一般默认为 8192 字节，简言之充分榨干操作系统的文件系统性能。

LSM 的基本原理是写数据时增量数据优先保存在内存，内存数值到了一定阀值，触发转储批量写到硬盘上，读数据时优先从内存里面找数据，如果需要合并磁盘中的历史数据。LSM 充分利用了系统内存，有效规避了磁盘随机写入的问题，但是读取可能需要访问更多文件。

两种技术各有特色，各具千秋。传统数据库 oracle 就是基于 B 树 (平衡树)，数据按页面有序组织存储在树结构里，查找再按序查找，理论 B 树数据读会比 LSM 要快。缺点是随着时间推移数据增长，写操作都触动页拆分或合并，数据写会越来越慢。ORACLE 解决单机性能问题是切换到磁盘阵列方向上，所有的数据读写都发生在磁盘阵列上，读写中心数据容器依然只有一个。虽然能解决高并发问题，但是成本昂贵。保持 B 树不变，换更好的设备换取性能，这是硬件换性能的解决方案。 B 树之上变体有有 B+ 树、wiredTiger 等数据结构，pgxc 是基于 postgres 的分布式数据库，它选择 B+ 树作为底层架构，国外 NOSQL 厂商 mongoDB 选择了 wiredTiger 做默认引擎，两者同样基于 B 树上，但是在市场存活得很好。

新一代数据库都是大多数 hbase、cassandra、spanner 基于 LSM，我们的 TiDB 和 OceanBase 也是 LSM，OceanBase 还改善了 LSM 的缺点，增 加数据分发的概念。 数据合并是很大的操作，在合并前，提前把数据分到合并的节点上，让数据更贴近存储。而 TiDB 的亮点之处是做 LSM TREE +DELTA TREE 的融合，即行列共存，LSM tree 为事务数据服务，delta tree 为分析数据服务，opengauss 的创新都是围绕 pgxc 源代码基础 上改的，全量 checkpoint 变成增量 checkpoint，更快把内存中的增量数据写入到数据文件。

笔者认为 OceanBase 和 TiDB 更理解 LSM，并适应做出改变，而 opengauss 最多是边缘创新，不算核心创新。

存储引擎

存储引擎是数据库很重要的一个组件，无论你把数据库架构分成两部分还是三部分，其中一部分必然是存储引擎, 存储引擎相当于汽车的发动引擎。mysql 的存储引擎有 myisam、innodb、memory、列式引擎、归档引擎等。其中 myisam 和 innodb 都是行式，但是只有 innodb 支持事务。使用内存做数据库可能是个不明智的选择，但是内存里面的数据很容易丢失, 目前 memsql 和 voltDB 就把这个事做成了。 Memsql 号称是业界最快的内存数据库，支持事务处理，连 OceanBase 也借鉴了 Memsql 的设计思想。

tidb 的存储引擎 tikv 少不了 RocksDB，RocksDB 是一个嵌入式数据库。TiKV 会将数据存储到 RocksDB，RocksDB 是一个 key-value 存储系统，所以对于 TiKV 来说，任何的数据都最终会转换成一个或者多个 key-value 存放到 RocksDB 里面。每个 TiKV 包含两个 RocksDB 实例，一个用于存储 Raft Log，我们后面称为 Raft RocksDB，而另一个则是存放用户实际的数据，即 KV RocksDB，KV RocksDB 是行式存储，主要用于事务数据。TiDB 的另外一个存储引擎是 Tiflash，TiDB4.0 就已经诞生，Tiflash 应该属于 TiDB 完全自主研发的存储引擎，以后应用于数据分析场景。TiDB 的口号是 100% 的 OLTP 场景，30% 的 OLAP 场景，将来的发展趋势是 RocksDB 以后会要给替换。

OceanBase 的口号是 0 到 1 完全自主研发，没有借助任何开源，也没有集成其它产品。OceanBase 存储引擎从最小的单元开始组装，SST 是一个 key value 文件，是 RocksDB 的持久化文件，rocketsdb 也是起源于 SST 的数据结构组织。OceanBase 目前没有纯列式引擎，它现在有且只有一个存储引擎。而且与 Orc 类似，它并不是一个单纯的列式存储格式，它的全表是首先根据行组分割，在每一个行组内进行按列存储。

openGauss 有三个引擎，行式引擎、列式引擎、内存引擎。其中行式引擎是 pgxc 本身就有的，列式引擎和内存 openGauss 后面研发加上去的。

• 副本复制

从主节点复制数据到从节点，从主分片复制数据到从分片，从 OLTP 复制数据到 OLAP，副本复制归纳有以下多种方式。

• 基于语句的复制

VOLTDB 使用基于语句的复制，它通过事务级别的确定性来保证复制的安全。

• 基于预写日志传输

所有对数据库写入的字节序列都写入日志。因此可以使用完全相同的日志在另一个节点上构建副本，除了将日志写入磁道之外 ，主节点还可以通过网络将其发送给从节点。postgres 采用此法，构造主从环境 。

• 基于行的逻辑日志复制

数据写入预写日志后，最后修改变化记录在 MYSQL 的二进制日志 BINLOG，通过 BINLOG 进行数据同步。

• 基于触发器的复制

HANA 就是基于触发器的方式把 OLTP 的数据传到 OLAP 系统。

• 基于一致性协议的复制

基于一致性事务协义 paxos、raft、zab 同步数据副本。

在分布式系统中，同时查询两个不同的副本可能会得到不同的答案，如何使系统看起来只有一个副本，这个就是可线性化思想。不可线性化的分布式系统可能会看到滞时的数据。

主从复制的架构和基于一致性协议复制满足线性化的条件，OceanBase、TiDB、openGauss 都可以达到可线性化。

SQL 引擎

你可以 SQL 引擎看成是一套衣服，里面分为语法层，解析层、转换层、优化层、执行层，输入的 SQL 语句至少要经过五层计算。

我们用个比喻句来形容五层计算的作用，想像一个演员要上舞台剧给大众表演，首先他和观众进入第一个语法层大门，守卫一看是演员，马上放行通过，其它观众禁止立令返回。第二个解析层大门，演员取出本次安排表演的证明，也放行通过。第三个转换层，演员更衣沐浴进入状态。 第四个优化层演员把自己调优到最好阶段，第五个执行层，演员直接上台表演 。这个演员就是 SQL。

这个衣服太厚重，NOSQL 就舍弃了这套衣服，因为占据 CPU 大量的资源和调度运算,hbase 有自己的专属语言，cassandra 有专属轻量专属语言，甚至 mysql 曾经也把 sql 去掉，成立自设的 handlesocket 提高性能。

NEWSQL 时代这套衣服又回来，因为程序员的体验还是 SQL 最好，学好 SQL，走遍天下什么都不怕。

OceanBase 在 SQL 的语法层兼容 oracle 和 mysql 语法，换言之你是 oracle dba 或者 mysql dba，你可以快速上手 OceanBase，我估计 OceanBase 以后会更多与 oracle 兼容。而 tidb 开始只兼容 mysql，后来开源社区 神州数码 团队 开发了 Postgre SQL 接口，已经开始规模使用。openGauss 继续 pgxc，天生支持 postgresql 的语法，但是开源后，也陆续支持 mysql 的使用方式 。

权限管理

数据库权限管理一般是指库、表基于用户名、用户组的读写权限管理，目前 OceanBase、TiDB、openGauss 都可以做到数据权限细粒度度管理控制。资源上的权限控制，TiDB 通过事务处理提供一个行存引擎 TiKV，针对 分析处理提供一个列存引擎 TiFlash，两者进行资源隔离。云上的 openGauss 通过 IAM 服务提供用控制华为云资源的访问，IAM 服务可以精确到具体服务的操作、资源以及请求条件等。基于策略的授权是一种更加灵活的授权方式，能够满足企业对权限最小化的安全管控要求。

笔者认为多租户资源管理做的比较靠谱的是 OceanBase， 多租户关键是做到按照租户做到对 CPU、内存还有 I/O 的精细化的控制，OceanBase 已经做到按用户进行资源隔离划分，目前能做到做到 CPU 和内存的控制。而 TiDB 和 openGauss 的体验没有那么舒服。

社区运营

毫无疑问 TiDB 是社区运营中做得最好的，TiDB 一直致力于开箱即用，让用户快速使用 TiDB，多年来除了本身的开源项目，TiDB 也会积极开展各种活动和业界开发者互动，根据他们的反馈做各种优化。OpenGauss 开源的 1 年时间里，积极与中小企业合作，由于是木兰开放许可证， 几乎所有的中小企业都可以拿来就用，甚至改名当成自己的产品来用。OceanBase 起步较晚，甚至社群沟通交流工具用的还是自家的钉钉，可能就因此这个工具有一些用户不愿加入进来，另外 OceanBase 对硬件的配置 要求比较高，这也造成 OceanBase 门槛高的原因。

生态支持

生态支持方面笔者认为 TiDB 是做得最好的，30% 的分析不够用，就可以使用 Tispark，后面又支持 flink，TiDB 努力拥抱生态开源。应用产生数据，传到下一步数据消费，数据分析结果回馈哺乳应用形成一个数据闭环，这是所有应用的将来技术趋势，也是 HTAP 的思想初衷。

开源生态支持成熟度来看，TiDB 大于 OpenGauss，OpenGauss 大于 OceanBase。

综合比较

可用性、维护性、稳定性、扩展性都是产品的基本功能，我们聊聊应该有哪些特点。

• 可用性

• 怎么让用户快速使用安装

• 怎么让用户简单使用操作命令行

• 怎么让用户代码编程

• 怎么让用户操作使用其它服务组件

• 维护性

• 快速排查故障

• 统一监控界面可以了解每个节点的运行状况

• 历史监控日志

• 稳定性

• 压力测试

• 性能测试

• 基准测试

• 混沌工程测试

• 业务场景测试

• 扩展性

• 计算资源扩展

• 存储资源扩展

• 组件扩展

• 第三方工具扩展

过去，OceanBase 的运维性和可用性极差，虽然能够支持阿里巴巴和蚂蚁银行，OceanBase 更像是阿里业务独造的个人数据库，一直以来 OceanBase 团队在不断完善系统。现在的 OceanBase 已经是翻天覆地的变化，尤其去中心化非常方便管理。TiDB 一直强调开箱即用，2020 年发起一个项目叫 Tiup，志在简化 TiDB 的安装。这个非常不错，笔者体验一把，感觉非常不错。opengauss 在产品里面集成了很多 AI 算法，诸如慢 SQL 发现和参数调优，这也是辅助管理的创新。到此为止，三款产品谁好谁坏谁更强，根据业务需求任君选择了！

参考文档书籍

• 大规模分布式存储系统 原理解析与架构实战 杨传辉

• 数据密集性应用系统设计

• 数据库系统内幕

• openGauss 数据库核心技术 李国良 周敏奇

• 数据存储技术与实战 查伟

• 从零开始学架构 李运华

• 数据库事务处理的艺术 事务管理与并发控制 李海翔