国产主流数据库调研

国产数据库现状

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数据库核心技术 李国良 周敏奇
• 数据存储技术与实战 查伟
• 从零开始学架构 李运华
• 数据库事务处理的艺术 事务管理与并发控制 李海翔