社区首页 >专栏 >TiDB 分布式数据库多业务资源隔离应用实践

TiDB 分布式数据库多业务资源隔离应用实践

原创

PingCAP

修改于 2025-03-27 03:05:08

1090

导读

随着 TiDB 在各行业客户中的广泛应用，特别是在多个业务融合到一套 TiDB 集群中的场景，各企业对集群内多业务隔离的需求日益增加。与此同时，TiDB 在多业务融合场景下的资源隔离方案日趋完善，详情可参考文章《你需要什么样的资源隔离？丨 TiDB 资源隔离最佳实践》。

本文将分享某客户在 TiDB 分布式数据库中实现多业务资源隔离的实践案例。该客户是中国领先的全球化消费电子品牌，专注于智能配件和智能硬件的设计、研发与销售。其业务起步于线上，销售网络覆盖全球主流电商平台。公司以创新为核心，致力于将富有科技魅力的产品带给全球消费者，旗下拥有多个自主品牌，在 AIoT、智能家居、智能声学和智能安防等领域表现出色，覆盖全球多个国家的海量用户。

业务背景

在引入 TiDB 之前，这家企业主要使用 MySQL 作为其核心业务数据库。自该公司上市以来，业务迅速扩张，数据量激增，MySQL 在一些关键业务场景中遇到了瓶颈：

库存管理系统 ：该系统具有高并发的读写需求，频繁进行库存的增减和查询操作，属于典型的在线事务处理（OLTP）系统。然而，随着数据量的持续增长，难以满足业务的性能要求。
业财一体化系统 ：此系统是一个典型的混合事务/分析处理（HTAP）系统，它不仅需要维护完整的事务一致性，还必须具备处理复杂 SQL 的分析能力。系统中的单表记录数已超过 15 亿行，且存在多表关联的分析需求。
业务报表系统 ：作为在线分析处理（OLAP）系统的代表，该场景经常需要处理涉及十几张表、数百行 SQL 的复杂查询，且对数据的实时性有极高要求。业务团队期望能够即时获取运营数据，以便实时分析和洞察运营状态。

基于 MySQL 的传统数据库架构难以应对上述挑战，该企业考虑引入新的数据库解决方案以更好地支撑业务发展。

充满挑战的选型测试

2022 年，这家企业与 TiDB 分布式数据库邂逅并开启了一段全新的旅程。TiDB 不仅在墨天轮数据库排行榜上稳居前列，在全球数据库排行榜 db-engines.com 上是国产数据库排名最靠前的一家，其在 GitHub 上的 Star 数也呈现出迅猛增长态势，社区的活跃度同样令人瞩目。TiDB 解决方案已经在互联网、金融、电信运营商以及新经济等多个领域展现出广泛的应用价值，这些优势吸引了他们的注意。同年 10 月，这家企业启动了对 TiDB 的评估选型工作，完成了以下几个关键环节的测试：

TiDB 集群部署 ：通过 TiUP 工具部署 TiDB 集群的流程极为顺畅。除了初期的基础环境检查，TiDB 本身的部署过程已高度自动化，实现了一键式操作，快速完成了 TiDB 6.1.3 版本的集群搭建。
数据同步链路测试 ：TiDB 集群利用 TiCDC 同步工具，能够将全量和增量数据准实时地同步到下游的数据湖。由于 TiCDC 不支持直接将数据写入 Databricks，采取了间接的同步策略：首先将数据同步到 MySQL，然后通过 Fivetran 将数据传输到 Databricks。TiCDC 支持 Avro Protocol、Canal-JSON Protocol 等多种数据格式。
数据备份测试：使用 TiDB 自带的 BR 备份工具对集群数据进行了全量备份和增量备份的测试。
性能测试 ：针对业务报表中的复杂 SQL（涉及十余张大表 join、多次 union all 操作和嵌套子查询）进行了性能测试，同时也测试了库存系统的简单 SQL 在高并发环境下（并发数超过 600）的查询性能。由于当时测试环境中没有部署 TiFlash 节点，这些复杂 SQL 对 TiDB 集群的性能产生了一些影响，偶尔会出现集群卡顿的现象。

测试结果表明，TiDB 作为一款高度兼容 MySQL 的原生分布式数据库，提供出色的扩展性、便捷的部署、优越的性能和丰富的生态系统。在整个测试过程中，原厂工程师提供了专业且积极的技术支持，有效解决了遇到的所有问题。总体来看，TiDB 充分满足了业务场景的需求，符合选型要求。

尽管在测试中发现，当时的 v6.1.3 版本（尚未具备 Resource Control 功能）版本在处理复杂的 SQL 查询和高并发的 OLTP 业务请求时存在相互干扰的问题，但这些问题并未掩盖 TiDB 在其他方面的优势。随着 TiDB 产品的不断迭代和优化，这些问题将逐步得到解决。

多业务隔离应用实践

在与 TiDB 原厂工程师的紧密合作下，这家企业针对测试过程中遇到的问题，根据业务特征对 TiDB 集群的配置进行了精心优化，即使在不具备资源管控功能的情况下，也通过 TiDB 原有的特性成功实现了多业务的有效隔离：

数据隔离策略 ：利用 Placement Rules in SQL 能力将库存业务与财务结算、业务报表的底层 TiKV 数据进行了有效隔离。库存业务作为 OLTP 的代表，被标记为 Label A，而财务结算和业务报表则被标记为 Label B，从而有效避免了 TiKV 层面的 I/O 和 CPU 资源争用。
引入 TiFlash 节点 ：引入 TiFlash 节点将业务报表和财务结算中的复杂 SQL 查询转移到 TiFlash 节点执行，这一改变带来了性能的指数级提升。
tidb-server 层面的业务分组 ：在 tidb-server 层面实施了业务分组策略，将 tidb-server 分为三组，其中两组专门服务于库存业务，并通过 AWS 的 NLB（Network Load Balancer）进行负载均衡，另外两组服务于财务结算业务。该企业还单独分配了一个 tidb-server 用于业务报表的远程查询，实现了业务在 tidb-server 层面的隔离。

<center>图：数据架构示意图</center>

使用 TiDB Resource Control 功能进行更细粒度的资源管控 ：通过将 TiDB 集群从原来的 6.1.3 版本升级到 7.1.5 版本，引入了 TiDB 在 7.1 版本中提供的 Resource Control 能力，对更细粒度的资源进行管控，通过对不同的业务分配不同的资源单位（RU，Request Unit），来实现对 CPU、IO 等更细粒度的资源隔离，同时还可以采用该功能实现对 SQL 级别的流控（QUERY_WATCH）和后台任务的资源限制。

通过实施这些针对性的优化措施，该企业不仅成功克服了测试阶段遇到的挑战，还大幅提升了系统的综合性能和稳定性。这些积极成果进一步增强了他们继续使用 TiDB 的信心。

集群优化带来的收益

实现多业务隔离 ：利用 Placement Rules in SQL 的能力将 tikv-server 划分为两个不同的组以实现隔离。tidb-server 则根据业务层的分组进行隔离。由于 pd-server 的负载较轻，可以实现共用。这种架构设计使得单一逻辑集群能够支持多个业务，简化了管理维护工作，同时提供了统一的 HTAP 服务。
支持数据实时写入与事务特性 ：数据主要通过应用程序和接口实时写入 TiDB。TiDB 不仅支持实时的 insert、update、delete、replace 等 DML 操作，还确保了事务的 ACID 特性。这一点相较于许多仅支持追加写入的数据仓库平台，TiDB 展现出了明显的优势。
对接数据湖生态 ：部分经过 TiDB 加工处理的数据需要实时同步到数据湖平台，通过 TiCDC 同步工具，TiDB 能够将变更数据实时同步到数据湖。当时由于环境限制，TiCDC 暂时无法直接写入 Databricks，采用了 MySQL 作为中间跳转的方案。与此同时，TiDB 也提供了 TiDB to Databricks 的同步工具：tidb2dw ( https://www.pingcap.com/blog/tidb2dw-replicate-data-to-warehouses/ ) 给该企业使用，以逐步实现 TiDB 到数据湖生态的直接对接，并以此场景为契机，不断反向推动 tidb2dw 工具功能和能力。

选择 TiDB 的理由

技术领先性 ：TiDB 采用存储与计算分离的原生分布式架构，提供出色的扩展性，允许灵活地增加计算节点（tidb-server）和存储节点（tikv-server），以适应业务的不断增长和变化。
丰富的资源隔离手段 ：TiDB 分布式架构，提供了从计算、存储、OLTP、OLAP 等各个组件间粗粒度的资源隔离手段、同时也提供了在集群内部的 CPU、IO、资源组 SQL 级别的、后台任务级别等更细粒度的资源隔离手段。
自动分片特性 ：TiDB 的自动分片功能消除了业务开发中对表分片和分区规则的预先设计需求，使得开发过程更加直观、简便，使用体验与单机 MySQL 相似，对业务开发完全透明。
解决分库分表问题 ：与 MySQL 的分库分表架构相比，TiDB 支持分布式事务和在线 DDL 操作，为业务开发提供了更高的透明度和简化的维护流程。
HTAP 一体化特性 ：TiDB 集群提供了面向 OLTP 的 TiKV 行式引擎和面向 OLAP 的 TiFlash 列式引擎，能够一站式提供 HTAP 服务，满足业务对实时事务处理和复杂分析的需求。
完备的 MySQL 兼容性 ：TiDB 高度兼容 MySQL 5.7 和 8.0 的语法，以及 MySQL 的生态工具和开发框架，为主流应用开发提供了极高的匹配度，实现与现有系统的无缝对接。
原厂专业支持 ：TiDB 的原厂工程师无论是售前还是售后工程师都展现出极高的专业度和敬业精神，能够迅速协助解决各种问题，即使在节假日也能及时提供支持。

未来展望

升级 TiDB 版本，解决已知的问题

这家企业计划已经在去年 7 月底将原有的 TiDB v6.1.3 版本全面升级至 v7.1.5 版本，虽然升级过程出现一些小插曲，但是通过升级这件事看到了 TiDB 原厂的技术支撑的及时性和专业性，这是该企业从开源用户走向商业客户的价值所在。此次升级旨在提高创建索引的效率，创建索引的速度提升超过 10 倍。与此同时，该企业也在调研 TiDB 最新版本的能力，及时享受 TiDB 最新版本在功能、性能和稳定性上的技术红利。