关于数据库:从传统数据库痛点看分布式数据库选型问题

本文转载自：OceanBase 社区

作者简介：蔡鹏，领有十多年 DBA 工作经验，曾就任于饿了么、蚂蚁团体，现任货拉拉数据库部门负责人，负责数据库、缓存，音讯队列的治理与平台研发工作。

引言

近年来，随着互联网大厂掀起分布式数据库的技术浪潮，中小型互联网企业也在不同业务场景下纷纷试水分布式数据库，电信、金融、银行、保险等传统畛域的大型企业也逐步转向分布式数据库，这也成为 DBA 这个小圈子中热议的话题。的确，从事实需要上看，各行各行业的数据量一劳永逸，在这样的背景下，咱们须要“同流合污”布局分布式数据库吗？以下为集体通俗的思考，供大家简略参考、程度无限如有谬误烦请斧正。

传统数据库痛点

说起分布式数据库，必须先提一下传统单机数据库。以大家较为相熟的 MySQL 为例，如下图所示，传统单机数据库架构简略，由若干台节点通过 Binlog 复制形成一个集群，写集中在主库，读则摊派在集群的各个节点上。

不可否认的是，上述架构在一些重要个性上存在“天花板较低”的问题，如以下 5 个个性。

个性 1：高可用问题。

MySQL 自身是不具备高可用能力的，它的高可用能力通过内部工具帮助达成（MySQL 高可用计划随着复制的改良有漫长的演变历史）。家喻户晓，高可用工具往往只能最大限度解决数据一致性的问题，而不能解决 HA 切换后利用拜访的问题，通常一个残缺的高可用零碎是要 HA 工具 +Proxy 联动 +ClientDriver 连接池合理配置独特实现的。遗憾的是，时至今日不少中小公司并没有丝滑解决 HA 切换的问题，次要起因是 HA 工具 +Proxy 深度定制能力欠缺，篇幅起因不做开展。

个性 2：数据一致性问题。

数据复制是存在时差的，造成读一致性问题，但这通常不是太大的问题，通过 Proxy bindmaster 操作都能解决，不过，master 压力可能会同样面临性能瓶颈。

个性 3：容量、性能扩大、构造变更。

这是传统单机数据库的三宗罪。存储的扩大在肯定水平内能够通过堆硬件（垂直扩容）的形式来解决，但堆硬件也是有限度的，出于可运维、易运维的角度，通常 DBA 都不会让单实例或者单表太大。可能对于一个冷的日志表存储超过 1TB DBA 可能就会比拟缓和了，毕竟 DDL 一次可能要以天计算，而对于一个读写高频的订单表超过 500GB，预计 DBA 保护就会如履薄冰瑟瑟发抖了！这时辣手的问题就来了：给够你硬件你都不敢用。

通过堆硬件能在肯定水平上缓解存储容量下限的问题，但性能问题是无奈靠堆硬件齐全解决的。还以订单表为例，如果是日订单百万甚至千万级别，无论怎么折腾单表都会呈现重大的读写性能问题，此时通过扩容硬件的形式不能解决问题。一方面是因为数据库自身会因为热点表的高频读写造成重大的锁放大问题，另一方面数据库自身并不能充沛应用硬件资源，尤其 MySQL 5.6 之前的版本因为诸多子线程未从 Master 主程上拆分，造成 CPU 应用不充沛，这在 MySQL 5.7 版本后有了很大的改观。尽管如此，还是会受到网卡、磁盘 IOPS 下限因素的影响，注定单机形成的数据库集群存在性能下限。因而可怜的是：给你足够的资源你都用不到。

不敢用、用不到都很苦楚！为此就诞生了“拆”的想法，依据不同的“拆” 法诞生了不同状态的分布式数据库。值得一提的是明天做数据库拆分的初衷并不是为了解决性能瓶颈而是数据存储达到单机下限，更直白一点地说，拆的要害是解决大表运维窘境。

个性 4：HTAP。

新时代赋予数据处理新的诉求，目前解决方案还是通过数据流（ETL）的形式将数据写到其余剖析型数据库中。不论是链路保护复杂性还是利用健壮性（低提早、高稳定性）都有不小的麻烦。因而，心愿能通过一套数据库搞定所有问题。

个性 5：容灾能力。

近几年企业对容灾的要求越来越高，作为 DBA 也该当确保极其状况下（机房限电、被炸等）数据库具备逃逸能力。单机数据库通过主从（异地部署）形式也能实现，尽管保护较为简单但也能用。

分布式数据库状态划分

分布式数据库依据不同“拆”法或者设计理念大抵有如下三种状态划分。

1、分布式中间件

典型的架构图（简化图），核心思想是通过中间件将多个独立的物理集群组联结起来形成一个逻辑集群，通过某种数据路由规定将用户申请打散到不同节点上。

该做法俗称分库分表，是绝大部分互联网公司在解决容量、性能扩展性问题上的首选计划。该计划将数据基于某种规定（sharding key）平均拆分到多个集群中来达到摊派存储与计算性能压力，代表的中间件产品 TDDL/Cobar/Vitess，及基于该思维诞生的“分布式 DB”代表产品 TDSQL、StarDB 等。这类计划尽管解决了容量、性能可扩大的问题，然而也存在如下的一些问题。

问题 1：技术简单。

通常是大公司专属玩法，广泛基于业务场景做了深度定制，周边有一套残缺的配套管控零碎反对。目前市面上尽管有一些开源的 Proxy 也能用，但对于中小公司来说很难从根上可控，应用过程中的辣手问题简直很难在短时间解决，而且开源产品为了通用性要想基于公司场景化定制有难度。因而，很多中小公司尽管做了分库分表但或多或少存在这样那样的问题。

问题 2：对业务有侵入。

从单表到分库分表的革新广泛要求带 sharding key 作为数据拆分及路由根据，这样业务逻辑被迫进行革新，比方对多表 join 的场景很难通过中间件去解决、非 sharding key 的查问被迫要扫片性能则非常低、排序 / 分页 / 聚合计算问题，等等。为了解决数据拆后聚合的问题，通常要在整个业务链路上部署简单的中间件，这给稳定性保护及业务健壮性带来一些挑战。

问题 3：扩缩容简单。

通常在决定分库分表的时候须要提前做好容量评估，分片数定义好后就不在扭转，十分不举荐前期再去扩大 / 缩容分片数。调整（reshard）分片数波及数据 rebalance 整个过程。为了保证数据一致性要做很多额定工作，通常是 DBA 定制开发一个平滑迁徙工具，或者研发双写 + 增量 Binlog 数据订阅做数据同步。如果 reshard 操作能内置到中间件，那对研发及 DBA 来说天然更敌对，但目前市面上开源的中间件简直没有见到有相似的性能！诸如 TDSQL、StarDB 等从公开材料上看是具备对用户通明的 reshard 能力的。

问题 4：分布式事务问题。

出于对 ACID 完整性反对的思考，由中间件状态形成的分布式数据库中解决分布式事务问题，通常解决方案都是差不多的，即两阶段提交（2PC）。

但实现过程非常复杂，也不可避免的对性能造成影响，通常在该状态的分布式数据库中都不太举荐用分布式事务。此外，这里分布式事务不能保证数据一致性或者说对集群而言实质还是最终一致性，该状态的分布式数据库在分布式事务实现上广泛相似，能够参考分布式中间件 Seata 的实现原理。

对于中小公司可行的做法是业务场景拆分得足够简略的状况下基于代理中间件 + 业务数据弥补来保证数据的最终一致性，应用分布式框架如 Seata 也是可行的，但太重了，对性能也会有显著的影响。

问题 5：运维复杂性。

分布式中间件状态的数据库往往都有十分欠缺配套的管控零碎来打包解决常见的运维问题，如果公司是基于某个开源的代理中间件做的，则不可避免的也要开发相干的管控零碎来对立解决诸如 DDL、研发数据勘误等问题。整体上还是能很好解决存储、计算能力有余等问题和大表运维窘境，只是对业务会有入侵，大公司专属定制，中小公司勉强也能玩转。

问题 6：HTAP。

目前看到的分布式中间件状态的数据库根本不具备 OLAP 的能力，广泛做法还是要将数据流向到剖析型数据库中。

问题 7：容灾能力。

跟单机主从无本质区别

2、存储计算拆散

该状态的分布式数据库核心思想是计算、存储拆散，计算与存储解耦，将有状态的数据和日志下推到分布式存储，多个无状态计算节点共享一份数据，代表产品 AWS Aurora、阿里 PolarDB。

这里简略看一下 Aurora 对性能、容量、构造变更上的优化。

首先在性能上，the log(redolog) is the database，简略说 Aurora 没有间接存储 MySQL 的 innodb page 数据页，只有一份 redolog 日志（集体了解应该是区别于 innodb 的 wal，最多是概念的类似，没有做深度考据），当须要读取数据时将 redolog 转换为 data page。这样设计因为只存储了一份 redo 数据（批量 + 程序 I /O）无需写 data page 因而也不存在缓冲区刷脏跟随机 I / O 写的问题，这相比于 MySQL 写 I / O 放大要精简很多，因而性能要晋升很多。援用公开材料论断：事务 I / O 开销只有 MySQL 1/ 7 事务处理能力是 MySQL 的 35 倍。

不过无利就有弊，Aurora Server 层还是原汁原味的 MySQL Server（100% 兼容原生 MySQL），读取数据时不可能间接读取 redolog，须要将 redolog 转换为 data page，转换是要领取 CPU 代价的。当然基于该非凡设计还有一些其余比拟好用的性能如秒级备份（俗称拍快照），就不多介绍了。

其次在容量上，存储构建在 S3 共享存储之上，对于容量扩大能够撑持足够大的数据量 (64TB)，多个正本之间通过 Gossip 协定保障数据一致性的，得益于 S3 的设计正本间的数据同步是十分高效的，因而正本间的数据提早非常低。笔者在写该文档时顺便查了一下当天的正本提早监控 P90 竟然都不到 1s，比照原生 MySQL 即便是优化后的 GroupCommit+MTS 也很难做到这一点。

值得一提的是，正是基于 log is data 的设计 +S3 log 同步防止了多数据正本间为数据一致性采取的 2PC/3PC 提交或者更简单的 Paxos 算法，十分 niubility 的设计。最初 Aurora 的存储容量是弹性伸缩的，DBA 无需被动扩容，不过从应用教训上看，在业务开释空间后仿佛并没有做“缩”的动作，会持续依照此前实例应用的最大存储来计费（略坑），这点目前不分明具体起因是啥！

在构造变更方面，目前跟原生 MySQL 一样也是 fast ddl，在 lab mode（实验室模式默认敞开状态，官网不举荐用……）反对 Instant ddl，不过只针对 add column 操作，目前 DDL 操作其实还是以 pt-osc/gh-ost 为主。尽管大表容量的问题解决了但对于超大表的运维还会存在肯定的问题。即便通过 pt-osc/gh-ost 能丝滑变更，以及 MySQL 没有明确规定单表大小及行数下限，但出于 b -tree 的起因在行数过多后还是会影响到读写性能，笔者在理论应用过程中就呈现了一张 400G 的单表 DDL 超过 12 小时的状况，为此公布零碎不得不 block 这个表的公布长达一年的工夫。存储计算拆散的状态下，只管架构是分布式的，在具体的设计思维上也十分先进，但对于解决大表问题还是稍稍有一点小遗憾，不过相比传统单机数据库曾经不必放心容量问题了，这一点对于业务体量不大既不想用中间件也不想对业务动刀的公司而言仿佛也是不错的抉择，况且 SQL 协定 100% 兼容。

此外，通过将计算下推到分布式存储的多个存储单元上实现并行查问从而具备肯定的剖析能力，也很难满足剖析型场景要求。不过，存储计算拆散的状态人造具备同城 + 异地容灾能力。

在应用 Aurora 的应用体感上，笔者更偏向于把它当作一个不宕机的容量性能有限扩大的单机数据库来应用，当业务体量到肯定水平后出于易保护的角度思考，最初大概率还是要拆的。最初倡议如果中间件能力不足又不想因拆导致的后续一堆麻烦的问题，即便保护麻烦一点也能够持续应用。

PolarDB 与 Aurora 相似，也采纳了存储计算拆散架构，因而也能很好解决容量、性能问题，同时也做到 100% 的协定兼容与较低的数据提早，至于谁优谁劣，因为二者设计理念不同，以及集体程度无限，不做过多评估跟剖析。

PolarDB 在比较关心的大表解决方案上做了优化加强，次要解决办法就是通过分区表，如分区键跟主键 / 惟一键解耦（MySQL 则要求 pk/uk 必须蕴含分区键），分区锁反对将锁从表粒度升高到分区粒度显著加强并行能力。不过分区能力的加强仍旧不能防止大表下 btree 局限问题。为此，PolarDB 又将 btree 改成 Blink-Tree（没有深刻理解，简略说就是通过对节点增加额定字段实现 tree 调整时全局加锁到局部加锁，进而进步并发度 )。同时对于大表 DDL 问题，PolarDB 除反对 instant ddl 能力外还通过并行 DDL 能力充分利用存储 I / O 能力减速 DDL 进度。

即使有上述优化伎俩也不能彻底解决大表问题，笔者感觉（纯正集体了解）基于上述优化后应该是比 Aurora 裸大表的形式要好一些，起码会大程度上推延性能瓶颈的到来，这又进一步了推延了用户分库分表的紧迫性。

对于 btree 拜访的优化，笔者此前还理解到 GreatSQL(万里数据库) 将 B + 树划分为若干子树，通过多个线程并行扫描同一张 InnoDB 表的不同局部，之后在将子线程后果汇总达到晋升查问性能的目标，也是一个很机智的设计。

至于 HTAP 能力，仿佛 PolarDB 有着更大的现实，其内置了 X -Engine OLAP 剖析引擎 (见下图)

这种一款数据库同时内置 TP(btree&row 存 e)+AP(lsm-tree& 列存) 两个引擎（两份数据），的计划，即数据通过日志的形式在各个引擎间同步，在近两年也逐步涌现进去 (将离线 ETL 过程给包了)，能够设想其在老本、复杂度上该有多高，注定了专属于顶级大厂的玩具，程度无限下文无奈合成！

3、原生分布式

代表产品 OceanBase、TiDB，该状态数据库通过人造的多正本设计 +Paxos/Raft 分布式选举协定实现分布式。

在高可用、数据一致性上基于 Paxos 协定实现，无需内部任何三方工具依赖数据具备强一致性，这一点跟存储计算拆散实现高可用也略有不同。

在解决容量、性能问题上自不必说，OceanBase 同样具备良好的弹性扩大能力

容灾能力同样也比拟灵便，能满足不同等级的容灾要求。

只须要增加节点即可实现容灾建设，操作过程也比较简单，当然其余状态的分布式数据库一样能够做到。

值得一提的是 OceanBase 具备租户的概念，且租户间资源是隔离的，这一点是有别于目前市场上绝大部分分布式数据库的。基于租户这个个性能玩的花色就多了，如对绝大部分公司而言大部分 DB 其实都不会面临容量、性能上的问题，这些小 DB 又有存在的理由，通常咱们还不能将它堆到一个集群里，因为无奈解决隔离问题，这里多租户就派上用场了。

这里集群租户间资源共享还是隔离是能够灵便设置的，个别有 cpu share（共享）、cpu set（独占）两种形式，能够基于场景设置，以实现业务的错峰部署，最大化进步资源利用率。同时，租户的呈现能够让 DBA 在进步资源利用率上具备更灵便的调度策略，如能够开发资源调度零碎动静调配不同租户在不同工夫的规格配置。这里资源隔离肯定要是物理隔离的，如果租户是逻辑隔离意义就小很多。

OceanBase 采纳了 LSM Tree 的存储形式，为了防止写放大等性能问题，OceanBase 的理念也很简略：能通过硬件解决的问题都不是问题。这让咱们看到了单 OBServer 竟然有恐怖的 700G 内存，这足以包容绝大部分业务 12 小时的变更量了，因而，读写尽量在内存中实现，待到低峰期在轻轻实现 Compaction。其余都挺好的就是贵！^_^……，

不过在硬件越来越便宜的明天，以及 OceanBase 4.0 开始小型化、单机化，使得 OceanBase 也能飞入寻常百姓家了。

在大表的保护上，OceanBase 相似 PolarDB 也是通过分区表的形式来解决，同样能够将分区散布到其余 OBServer，只是不分明是否也做了 PolarDB 在分区上的诸多优化。所以想当然的会认为 OceanBase 也存在大表下性能问题和变更问题。不过，OceanBase 并不放心大表 DDL 的问题，起因是得益于上述那个低廉的设计（OceanBase 自身也是保护了 schema version 的对于大部分 DDL 同城都是 online 的），通过低峰期发动 Major freeze 操作合并实现 DDL 天然也就实现了。同时为防止合并带来的影响，OceanBase 通过多个 Zone 间轮转合并防止对用户造成影响。不过 OceanBase2.0 开始在创立索引时就不必等到合并后失效了，用户创立索引就发动索引构建流程缩短失效工夫。

对于 OceanBase 兼容性，它同时兼容 Oracle 跟 MySQL 的。OceanBase 并不是像 Aurora 那样靠近原汁原味的 MySQL Server 对 MySQL 兼容，而是协定层的兼容 (小插曲：据说为了跟原汁原味的 MySQL 体现统一就连 Bug 都一起兼容了)。从笔者当初应用 OceanBase 的教训上看，对 MySQL 的兼容度也比拟残缺，值得一提的是从 MySQL 迁徙到 OceanBase 存储规模降落了 2 /3。

对于 HTAP 能够参考此前 OceanBase CTO 的一篇相干文章《真正的 HTAP 对用户和开发者意味着什么》，援用外面的一个重要观点：

真正的 HTAP 零碎有一个要求是基于”一份数据”同时做好交易和剖析。那么，什么叫做“一份数据”？想要答复这个问题，外围是要答复哪一种做法是对用户最敌对且性价比更高。我认为，数据的多个正本或者多种状态（列索引 / BTree 索引 / Bitmap 索引等）都能够被认为是”一份数据”，前提是可能在满足 HTAP 解决需要的前提下最大水平升高数据冗余。例如，OceanBase 往往存储多个正本（3 个正本 / 5 个正本），能够抉择让其中一个备正本专门做 OLAP 查问；Oracle IMC 反对对表格在内存中建设列索引，SQL Server 反对对表格在磁盘 / 内存中建设列索引，从用户的角度依然是“一个零碎，一份数据”。

从这里仿佛能够窥探到 OceanBase 对于 HTAP 的一些设计思维点：一个零碎，一份数据，多正本行列混合存，不搭积木。不过因为材料比拟少也没有从 OceanBase 的架构上看到 HTAP 是怎么体现的，当然必定有别于以 PolarDB 为代表的“多份数据”计划。多份数据实现上可能很简单但 OceanBase 抉择的路线仿佛也并不简略甚至更简单！

咱们再从 TiDB 架构图上看（如下图），比照之下，OceanBase 仿佛更加简洁一点，起码组件没那么多（部署不够敌对）不过这仿佛也不是什么大的问题，况且 TiDB 提供了简洁的部署计划，不得不说 TiDB 真的很聪慧特地懂用户心理，不论是对一个简略的部署，还是一开始抉择基于 MySQL 协定去研发，又或者是围绕 MySQL 生态打造的各种工具等等都深得用户情意，这一点跟竭力试图通过技术证实本人牛逼的产品，走的是不同路子。

对于性能、容量扩展性问题，TiDB 同样不逊色，其余分布式数据库也具备良好弹性能力，至于兼容性自身就是基于 MySQL 协定打造且在一些互联网公司也都验证过了。当然在一些场合下会拿各个数据库进行性能比拟，先不说比拟的基准是否统一，性能必定不是选型的第一思考因素，毕竟性能是能够通过资源去补救的，因而性能可扩展性十分重要，如最开始提到的：给够资源用不到那分布式就没有意义。稳定性应该更重要，这一点 OceanBase 在本身大规模金融领取场景下失去过验证这一点是具备足够的说服力的。

对于 HTAP，TiDB 通过内置 TiFlash 引擎来实现相似 PolarDB 的 X -Engine 做法跟 OceanBase 的“一份数据”理念仿佛还是有点不一样的，太简单看不清楚。也很难说谁优谁劣只能交给工夫跟市场去测验了。

在 TiDB6.0 外面有多租户概念、尽管也实现了物理隔离，跟 OceanBase 基于内核虚拟化技术不同的是，TiDB 是通过资源打标 + 调度的形式来实现的，集体感觉 OceanBase 在这方面要更胜一筹，分布式数据库下租户应该成为一种标配能力，一方面对公有云部署保护治理更加敌对，另外对用户而言分布式就是一个无限大的单机数据库不必放心容量跟性能问题，且资源是隔离的。

应用了分布式就能够一劳永逸地解决性能、容量问题了？其实不然，该做的数据拆分跟业务架构革新还是要持续做的，次要还是取决于你的业务体量到底有多大。蚂蚁的交易领取零碎体量足够大吧，也没有把所有数据都放到一套 OceanBase 集群里啊，同样也是将业务拆分（蚂蚁的单元化架构）到多集群的（俗称百库百表）。当然这是个极其的例子，如果对一个百万订单的零碎那兴许就不必了，或者更低一点的业务量还要啥分布式啊，单机数据库就挺好的。

比照总结

通过对三种状态的分布式数据库比照，针对可用性、一致性、容量、性能、保护、容灾、HTAP 的反对上做了一下简略总结，毕竟不论什么类型的数据库最终还是要回归到数据库的实质。须要阐明的是下表不具备选型倾向性，只是理念的不同带来格调的迥异并无高下之分！！！

中间件计划是历史的产物也有它存在的情理，长期看肯定会被淘汰，只是周期会比拟久（可能分布式数据库云化能减速降级进度），短期内仍旧是中小互联网公司的首选计划，毕竟绝对简略一些。

也没有万能的数据库，下面介绍的分布式数据库还是以解决 OLTP 为主的，并不适宜解决所有场景需要，比方 json、图、kv、cache、schemaless、dt 等场景的须要还是要应用特定类型的数据库。

选型技术之外的考量因素

即便通过上述简略的比照，抉择根据仿佛还不够。还要从如下几个方面进行思考。

1. 成熟度。

一款数据库成熟度怎么样能够从历史版本公布状况来简略剖析，如果频繁的大版本公布及小版本修复各种致命 bug、缺点等，显然不能被个别内部用户承受。以 MySQL 为例，2005 年 MySQL 5.0 公布到明天 MySQL 8.0 成熟经验了 17 年，其中 MySQL 8.0 从 2016 年公布到明天一个版本的稳固打磨就经验了 7 年！数据库注定是要十年磨一剑的。

2. 标杆利用。

在业内是否被大规模验证过了，或者有标志性的胜利案例。很多国产数据库目前整体还是灵通的尽管号称在金融、电信、银行、保险等畛域上线了，但理论状况怎么样齐全不得而知，尤其互联网公司崇尚的是开源这一类的数据库很难被承受。

3. 技术底蕴 & 靠山

所谓大厂出品必属精品，轻易一个什么公司搞一个数据库是很难被承受的。大家广泛认可业内顶尖的一流公司做背书的产品，甚至在深刻理解一下开发这款数据库的团队靠谱吗？毕竟数据库的复杂度堪比操作系统，要求十分高，甚至团队规模怎么样，不要指望百十人的团队能写出靠谱的数据库（KPI 产品例外）。当然中间件计划的分布式例外，毕竟外围是做 Proxy，复杂度远不在一个数量级上。

4. 生态。

生态次要看技术、人才、文档、服务这四方面。

技术方面，业务接入的革新是否低成本，或者说是否能复用成熟的生态 (比方 TiDB 和 OceanBase 都是残缺反对 MySQL 协定的)，是否足够凋谢让社区或者相干从业人员尽可能参加进来？比方 TiDB 这方面做的就很好。周边生态工具是否齐全，比方业务研发高频应用的 IDE 工具，DBA 更加关怀的一些技术接口或者现成的实用运维工具等。

人才方面，市场是否有足够数量的从业人员如 DBA。

文档方面，此前国产数据库整体上文档完整性比拟弱，当初好很多了，不过整体文档程度跟 MySQL 这样的开文档比还有差距，很显著的感触是：通知你怎么用，很少通知你为什么或者原理性的货色比拟少，可能是写文档的同学不是内核研发。

服务方面，国产数据库的诞生有事实的需要，但整体相比传统商业数据库成熟度还不够，因而须要更好的售后服务及支撑体系能力补救整体的有余。分布式数据库将来上云是个大方向，毕竟对绝大部公司而言是很难有人力跟能力去驾驭一个简单的、成熟度有待打磨的产品。

5. ROI

次要看引入分布式要解决什么问题，如果是老本，很可怜小范畴引入分布式数据库可能老本会更高！毕竟相比单机数据库，分布式数据库广泛对硬件老本要求十分高，比方 TiDB 和 OceanBase 都有很高的硬件要求（OceanBase4.0 小型化后改观很多）。如果是性能优化那更可怜，通常 benchmark 可能跑不过单机数据库！分布式数据库的整体收益只能在达到肯定规模后能力施展出老本、性能劣势。因而，如果只是某个繁多场景引入分布式来解决可能不是太好的抉择。据说携程是做了大规模 MySQ/Oracle 降级 OceanBase，置信他们应该有相干的数据可供参考。

对于 ROI 能够简略的比喻：分布式是卡车，拉的多跑的慢，单机数据库是轿车拉的少跑的快，因而要有个均衡。最初援用一句话:“过早的优化是万恶之源”。

6. 兼容性验证

尽管很多数据库都号称 100% 兼容 MySQL 等协定，但还是要以本人的理论验证后果为准（99.99% 的兼容跟 100% 的兼容对后果的影响是微小的）。起码你要有 SQL 流量回放能力来验证执行打算跟执行效率的差别吧。此外，对于是否平滑迁徙，成熟的产品往往有一套残缺的解决方案，要思考上线后你真的能驾驭它吗。

**
** 最初的最初，也在最后的最后，咱们要思考的是：真的须要分布式数据库吗？