业务背景：MySQL 带来的三个技术瓶颈
老乡鸡隶属于安徽老乡鸡餐饮股份有限公司旗下品牌，是以中式快餐为特色的连锁餐饮品牌，在全国有1000多家快餐店，从养土鸡起家，实现了从养殖到餐桌的全产业链模式。目前，北京、上海、深圳、杭州等一线城市都有门店，并以每年新增300家的速度发展。鸡类菜品是老乡鸡的招牌，其中以鸡汤为代表，选用养足180天的肥西老母鸡，再以农夫山泉水现炖，这碗汤一年就卖出了3000多万份，深受全国食客的喜爱。
老乡鸡的业务数据主要存储在MySQL数据库上，生产环境有近百套集群。数据库架构主要是 MySQL 主从架构，业务通过读写域名的方式访问数据库。同时，我们对 Orchestrator 做了定制化，能够管理 MySQL 主从的高可用。此外，我们也对一些核心的、数据量较大的集群做了分库分表。
在使用 MySQL 的过程中，我们遇到了三个主要的瓶颈。
第一，读写瓶颈。在疫情期间，老乡鸡的业务翻倍，流量猛增，由于 MySQL 这样的单机版数据库无法像分布式数据库一样做到平滑的水平扩展，线上许多集群存在明显的读写瓶颈。
第二，容量瓶颈。老乡鸡的数据增长很快，线上一些大表的性能问题逐渐暴露，随着数据量的增长，磁盘空间也慢慢地遇到了容量瓶颈。
第三，分库分表的历史遗留问题。由于一些历史原因，老乡鸡线上的分库分表分的并不彻底，分表之间也存在关联的一些操作。这些不合理、不规范的使用，导致数据库不断出现新的问题。
基于以上瓶颈，我们开始寻找新的数据库解决方案，并把目标投向了分布式数据库。
数据库选型时的五个考量因素
众所周知，分布式数据库自身具备水平扩展、高可用以及数据强一致等特点，除了这些能力，我们还十分看重它是否稳定、是否易运维、是否低成本、是否具备高性能、是否有丰富的生态。
稳定性。当我们将业务迁移至分布式数据库后，服务的稳定性是特别重要的。对于用户来说，他们或许并不在乎一个产品的底层存储是什么，但一定在乎服务是否足够稳定。
易运维。由于分布式数据库的门槛相对较高，如果它能提供一些智能化或平台化的运维工具，我们的运维人员所需的学习成本则会大大降低。
性能。我们希望能在有限的节点，且在可容忍的延迟范围内，考察一下分布式数据库能支撑多大的吞吐量。
生态。在将业务数据真正迁移到分布式数据库后，随着业务场景的丰富和数据量的增长，后续可能还会遇到各种各样的问题。如果数据库产品有一个良好的生态，就能帮助我们快速找到问题的解决方案。
成本。对于创业公司来说，降成本是一个无法避免的选型因素，就不再赘述了。
基于以上几个考察因素，老乡鸡选择了解并测试业内流行的两款分布式数据库：TiDB 和 OceanBase（见图 1）。
图 1 TiDB 和 OceanBase 的主要特点
TiDB
TiDB 是一款支持混合事务处理和分析处理（Hybrid Transaction Analytical Processing，HTAP）的融合型数据库产品，可以做到水平扩容和缩容，也能达到金融级高可用能力，数据能够达到强一致。TiDB 的表数据可以自动分裂，不需要 DBA 介入，这个功能非常好用。同时，TiDB 的社区也很活跃，当我们遇到问题时，在 TiDB 社区中基本能找到解决方法。
OceanBase
OceanBase 也拥有 HTAP 能力、并具备水平扩容或缩容、金融级高可用、数据强一致这三个特点。在 OceanBase 3.x 版本中，如果表的数据比较大，需要我们进行手动分区，在 OceanBase 4.0 版本后，开始支持大数据自动分区。
我们认为 OceanBase 具备一个特别吸引人的能力，就是它支持多租户和资源隔离。一个集群在承担众多业务的情况下，做到业务不互相影响是非常重要的。而且，当我们遇到问题时，在 OceanBase 社区也能快速得到解决方案。此外我们发现 OceanBase 为了能让客户及时收到别人对自己提问、解答的回复，设置了消息提醒，通过服务号绑定社区帐号就能在我们的问题得到解答时第一时间看到。
在初步对 TiDB 和 OceanBase 进行考察后，我们根据老乡鸡的业务场景对两款数据库做了进一步的对比和测试。
TiDB 和 OceanBase 的对比测试
我们的对比测试不局限于压力测试，因为两款数据库的压力测试都有极高的性能表现，甚至 OceanBase 在 TPC-C、TPC-H 中都取得了世界级的突破，所以我们并不担心两款数据库的性能，而是从两个具体的业务场景中测试慢日志、CPU、事务延迟、数据同步、在线 DDL、压测响应等。
测试场景一：OceanBase 慢日志少，CPU、延迟指标表现平稳
第一个场景是老乡鸡的某个 MySQL 业务集群（写峰值 1.3k，读峰值 3.5k，数据近 2TB），见图 2 ，其特点是单库分表，多分表之间存在关联查询，且存在多分表插入和更新等操作。
图 2 第一个测试场景概述
我们选择了 TiDB v6.1 和 OceanBase v3.1.4 进行测试与对比，测试所用的机器配置为 3 台 64C/256G/3T SSD。我们将线上的真实流量引入测试集群，测试的 TiDB 架构如图 3 所示，通过 DM 同步 MySQL 的 dml 操作，模拟写流量，写入 TiDB cluster 。再通过 TcpCopy 复制 MySQL 读流量，回放到 TiDB cluster 来模拟读流量。对 OceanBase 测试的架构也与其类似，通过 OMS 采集写流量，通过 Tcp Copy 拷贝和回放读流量，再回放到 OceanBase cluster。
图 3 TiDB 在第一个场景中测试的架构
通过对 TiDB 和 OceanBase 这两款产品的测试，我们得到了关于慢日志、CPU、延迟等方面的数据。
首先，对于慢日志，我们通过图 4 和图 5 可以看到。 TiDB 的慢日志比较多，OceanBase 也出现了慢日志，但次数较少。这是由于 TiDB 优化器不稳定，出现索引走错的情况，而 OceanBase 不支持倒序索引，其查询不走索引。
图 4 TiDB 慢日志测试数据
图 5 OceanBase 慢日志测试数据
其次，对于 CPU 指标，我们可以从图 6 和图 7 中的数据得知，由于 TiDB 的延迟发生了一些波动， TiDB 的 CPU 使用率也出现了较为明显的波动，而 OceanBase 的 CPU 使用率表现非常平稳。
图 6 TiDB 的 CPU 数据
图 7 OceanBase 的 CPU 数据
最后来看延迟指标，见图 8 与图 9，在整个测试过程中，TiDB 出现了几次小的波动，OceanBase 整体较为稳定。
图 8 TiDB 的延迟数据
图 9 OceanBase 的延迟数据
从延迟和 CPU 这两个角度来看，OceanBase 都要优于 TiDB。因为 TiDB 的数据在大于某个值后会自动拆分，数据会自动分散在各个节点上，而分表的查询或关联的更新基本走的都是分布式事务。OceanBase 支持本地事务，数据都在一个 zone 内，查询走的都是本地事务，所以其延迟比分布式事务低。
测试场景二： OceanBase 较 TiDB，数据清洗快 2.74 倍，数据同步快 2.6 倍
第二个测试场景是某业务需要从上游的多套 MySQL 集群汇集数据并清洗，数据清洗完成后提供线上服务。该业务场景的数据涉及多个上游集群，且清洗后的数据单表记录数最大达到 30 亿。
图 10 第二个测试场景概述
我们还是采用 TiDB v6.1 和 OceanBase v3.1.4 进行测试对比，机器配置仍为 3 台 64C/256G/3T SSD。在本次测试中，我们对两个数据库产品采用同一套清洗程序进行数据清洗，考察业务迁移后数据的压缩率、数据同步时间、数据清洗时间、在线 DDL 用时、业务接口压测响应时间。
测试 TiDB 的架构见图 11，通过 DM 把上游多个 MySQL 表的数据同步到下游的 TiDB cluster。在同步完数据后，业务程序会对同步过来的数据进行清洗，并将清洗完的数据写到本集群的新库中。
图 11 TiDB 在第二个场景中测试的架构
OceanBase 的测试架构如图 12 所示，与 TiDB 的测试架构类似。通过 OMS 采集上游的数据，再同步到 OceanBase cluster，业务程序也是在本集群进行数据的清洗，并将清洗完的数据写到本集群的新库中。
图 12 OceanBase 在第二个场景中测试的架构
经过测试，我们分别对比了 TiDB 和 OceanBase 在数据压缩率、数据同步时间、数据清洗时间、在线 DDL 用时、业务接口压测响应时间的表现。
1、数据压缩率对比
从图 13 来看，TiDB 和 OceanBase 对于单表各有优势。但前者的整体压缩率优于后者。
图 13 数据迁移后的压缩率对比
2、数据同步时间对比
我们并没有对同步的配置做优化，只是采用了默认的同步配置，发现 TiDB 所需的数据迁移时间是 50674 秒，OceanBase 只要 19406 秒。如图 14 所示，相当于 OceanBase 比 TiDB 的数据同步快 2.6 倍。
图 14 数据同步时间对比
3、数据清洗时间对比
数据清洗时间也关乎上线耗时，是业务迁移中比较重要的节点。我们的测试结果显示，同一套清洗程序，TiDB 的数据清洗用时是 OceanBase 的 2.74 倍，这意味着使用 OceanBase 的上线耗时比使用 TiDB 要短。因此，我们的研发人员对 OceanBase 的性能充满了信心和期待。
图 15 数据清洗时间对比
4、表在线 DDL 用时对比
如图 16 所示，OceanBase 在线 DDL 加索引的用时比 TiDB 短很多，尤其对于一些大表的改表用时，测试结果的差距非常明显。这一对比结果，让我们感到非常意外。
图 16 表在线 DDL 用时对比
5、接口压测相应时间对比
我们选取了五个核心接口，采用相同的压测线程数对同一接口进行压测，经过测试，我们发现 OceanBase 的响应比 TiDB 的响应快两倍。
图 17 接口压测响应时间对比
后续规划：核心业务迁移至 OceanBase
基于此次分布式数据库的选型及测试、对比数据，我们制定了两个计划。
首先，老乡鸡决定在核心业务中使用 OceanBase 数据库。目前，我们准备上线上面提到的 Y 业务。我们希望把 MySQL 集群数据汇聚到 OceanBase，通过租户隔离供大数据抽取和大后台业务使用。同时将部分增量数据通过 OMS 同步 Kafka 供大数据实时场景消费。此外，我们会陆续在其他业务中接入 OceanBase。
其次，老乡鸡会重点关注 OceanBase 4.0 版本，并尝试新功能。
- OLAP 能力。由于老乡鸡后台的查询会严重拖累线上的输出性能，因此后续我们会将后台查询尝试迁移至 OceanBase 中。
- OceanBase v4.0 支持 I/O 隔离，也是我们想尝试的一个功能。
- 以前的分布式数据库对机器的规格要求较高，测试成本比较大，OceanBase v4.0 支持单机分布式，对机器规格的要求更低，我们也会尝试用较低的机器配置来搭建 OceanBase，通过多租户的方式提供多套测试环境。
- 目前老乡鸡的数据库监控都依赖于 Zabbix，而 Zabbix 数据都存储在 MySQL 中，接入的设备越来越多后，MySQL 遭遇了读写瓶颈，OceanBase v4.0 针对 Zabbix 做了适配，我们会尝试把 Zabbix 监控存储也写到 OceanBase 中去。