数据库选型实践：如何避开分库分表痛点 | OceanBase用户实践_oceanbase 分库分表

随着企业业务的不断发展，数据量往往呈现出快速的增长趋势。使用MySQL的用户面对这种增长，普遍选择采用分库分表技术作为应对方案。然而，这一方案常在后期会遇到很多痛点。

分库分表的痛点

痛点 1：难以保证数据一致性。由于分库分表方案使得数据被分散存储于不同的数据库或数据表中，这在一定程度上使数据之间的关联变得更为复杂，确保数据的一致性的难度也随之增加。

痛点2：查询性能下降。分库分表会导致查询的性能下降，因为查询需要对多个数据库或数据表进行查询，增加了查询的时间和成本。非分区键查询需要借助其它的中间件或索引表进行查询。

痛点3：业务变更难度大。分库分表会增加系统的复杂度，当业务变更时，需要对所有分片进行修改和调整，增加了业务变更的难度和风险。

痛点4：数据迁移成本高。分库分表的场景下，数据的迁移成本很高，迁移过程中会涉及数据的拆分、合并和迁移等环节，增加了数据迁移的难度和成本。

痛点5：运维难度高。分库分表会增加系统的运维难度，需要对多个数据库或数据表进行管理和维护，增加了系统的故障排查和维护难度。尤其是自建 MySQL 集群。

痛点6：分库分表后的历史问题数据追溯困难。在分库分表的场景下，历史问题数据追溯问题是一个普遍存在的问题，由于数据被分散存储在多个数据库或数据表中，导致历史数据的追溯变得困难。

另外，使用 MySQL 分库分表的方案时，不仅需要依赖第三方工具，而且数据读写都比较复杂。

以上的常见挑战，也是OceanBase的客户，绿普惠所遭遇过的，因此，他们舍弃了 MySQL 分库分表方案，转而使用分布式数据库。经过绿普惠的初步筛选，在一众分布式数据库中，OceanBase 可以支持 HTAP 混合负载，且在 TPC-C 和 TPC-H 的评测中均取得了好成绩，故而展开了进一步的调研和测试。

一、绿普惠的业务背景

系统上指数级增长的数据，要求技术人员在运营上采用有效的应对方案，而诸如分库分表的措施也带来了后期维护成本。在绿普惠的系统中，其中的关键平台之一是“绿普惠云-碳减排数字账本”。数字账本平台主要包括三个模块：租户查询系统、碳减排量交易系统和运营端报表系统。

• 租户查询系统：租户可以通过 API 进行减排量指定维度和场景查询操作，查询系统将返回相应的减排数据。
• 碳减排量交易系统：交易核心减排量处理，可以支持大数据量低延迟，满足事务 ACID 要求。
• 运营端报表系统：用于统计分析和生成报表，可以处理大量大事务和复杂查询。

由于业务数据量庞大，目前绿普惠的存量数据表行数达到上亿行，还有每天上千万条的增量数据。面对庞大的数据量，他们采用了一种常见的数据处理方案 —— MySQL 分库分表。即通过将一个大的数据库拆分成多个小的数据库，或将一个大的数据表拆分成多个小的数据表来减轻单一数据库或数据表的负载压力，提高系统的性能和可用性。但是，其存在的痛点也让人束手无策。

二、调研过程及功能测试

在深入调研过程中，绿普惠了解到 OceanBase 已经应用在诸多行业，覆盖行业头部企业和一些中小型企业。对于绿普惠而言，他们看中了 OceanBase 的原生分布式无需分库分表、HTAP混合负载、并行执行优秀、存储成本低、数据迁移方便等特点。

（一）原生分布式

OceanBase 是原生的分布式数据库，可以保证多个数据副本之间的一致性，利用基于 Paxos 分布式一致性协议保证了在任一时刻，只有当多数派副本达成一致时，才能推选一个 Leader，通过保证主副本的唯一性来对外提供数据服务。相比分库分表方案，大大降低了绿普惠的运维难度和业务变更难度。利用 OceanBase 的多地多副本架构，以及高效的 Paxos 一致性协议工程实现，还支持数据副本分别存储在同城和异地，实现异地容灾。

（二）HTAP 混合负载

除了原生分布式无需分库分表的特性，OceanBase 可以同时支持 OLTP 业务与 OLAP 业务，故而被称为 HTAP 数据库。但这不单是一句口号，背后涉及四个关键技术。

1. 读写分离

分库分表会导致查询的性能下降，而数据库的读写分离策略是一种将数据库的查询操作和写入操作分离的方案，目的是降低读写操作的相互影响并提升资源利用率。在 HTAP 数据库中，读写分离的应用场景非常普及。OceanBase 数据库天然支持读写分离的功能，即通过 OBProxy 代理服务和修改 OBServer 的配置即可实现业务的读写分离策略。

OceanBase 数据库在读取数据时，提供了两种一致性级别：强一致性和弱一致性，有效解决分库分表的查询性能问题。强一致性是指请求路由给主副本读取最新数据；弱一致性是指请求优先路由给备副本，不要求读取最新数据。通过应用侧为执行的 SQL 添加 SQL Hint 来显性开启弱一致性读就可以实现基于注释的读写分离功能，同时也衍生出种各种各样的读写分离策略，比如备优先读、只读 zone、只读副本，企业可以根据实际情况，对读写分离策略进行灵活的配置。

2. 大查询队列

对于数据库来说，相比于单条复杂大查询，让大量的 DML 和短查询尽快返回更有意义。为了避免一条大查询阻塞大量简单请求而导致系统吞吐量暴跌，避开分库分表的查询性能局限，当大查询和短请求同时争抢 CPU 时，OceanBase 会限制大查询的 CPU 使用。当一个线程执行的 SQL 查询耗时太长，这条查询就会被判定为大查询，一旦判定为大查询，就会进入大查询队列，然后执行大查询的线程会等在一个 Pthread Condition 上，为其它的租户工作线程让出 CPU 资源。

配置大查询的参数为 large_query_threshold，执行时间超过这个参数设置的阈值，则认为是大查询。

如果系统中同时运行着大查询和小查询，OceanBase 会将一部分 CPU 资源分配给大查询，并通过配置参数 large_query_worker_percentage（默认值为 30%）来限制执行大查询最多可以使用的租户活跃工作线程数。

OceanBase 数据库通过限制大查询能使用的租户活跃工作线程数来约束大查询最多能够使用的 CPU 资源，以此来保证系统还会有足够的 CPU 资源来执行 OLTP（例如交易型的小事务）负载，通过这样的方式来保证对响应时间比较敏感的 OLTP 负载能够得到足够多的 CPU 资源尽快地被执行，无需面对分库分表导致查询的性能下降。

3. 资源隔离

资源隔离并不是一个新概念，传统方式下不共享物理资源，可以理解为物理资源隔离方案。这种方案下不同租户或同一租户内 OLAP 和 OLTP 使用不同的副本，只读副本服务 OLAP，全功能副本服务 OLTP，两种业务不共享物理资源。如果不考虑成本，物理资源隔离无疑是更好的选择。但现实中，大部分企业都会考虑硬件成本及其资源利用率。一方面，数据库硬件的购买和维护成本高昂，而所有硬件都需要定期换新；另一方面，数据库硬件在进行单项业务处理时，平均占用率水平较低。如果不能充分利用硬件资源，无疑会造成巨大的资源浪费。并且，基于此进行的分库分表方案需要对多个数据库或数据表进行管理和维护，增加运维难度。

而要充分利用硬件资源，不同租户或同一租户内 OLAP 和 OLTP 共享物理资源的逻辑资源隔离方案，自然脱颖而出。实际上，物理资源隔离和逻辑资源隔离不是二选一，而是互为补充的关系。理想的资源隔离方案是在完全物理隔离和逻辑隔离中找到平衡点，OceanBase 会给用户更多自由，帮助绿普惠在面对各类场景下都可以做出最合适的选择，有效降低分库分表带来的系统复杂度。

4. SQL 执行优化

SQL 的执行引擎需要处理很多情况，为什么要对这些情况进行细分呢？是因为 OceanBase 希望在每种情况下都能自适应地做到最优，不依赖现行的分库分表方法。从最大的层面上来说，每一条 SQL 的执行都有两种模式：串行执行或并行执行，可以通过在 SQL 中增加 hint /*+ parallel(N) */ 来决定是否走并行执行以及并行度是多少。