暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

TiDB 资源管控的原理与实践

TiDB Club 2024-11-01
258

👆 立即咨询 TiDB 企业版 👆

在数据库运维管理中,资源管控技术扮演着至关重要的角色。TiDB 7.0 版本引入的资源管控功能,不仅保障了在负载波动时的服务质量,还实现了多租户环境下的资源隔离,从而降低了数据库的运行成本。


本文涵盖了 TiDB 资源管控的设计思路、配置策略以及实际应用场景,旨在帮助读者深入理解 TiDB 资源管控的内在机制,并掌握其在提升数据库性能和优化成本效益方面的应用。


新特性解析

TiDB 资源管控的设计思路与场景解析


背景


资源管控旨在解决共享集群中业务负载突变影响其他业务、混合负载下资源竞争、高可用性业务系统中后台任务影响服务质量,以及灰度上线时小流量引发性能问题等挑战。


TiDB 6.6 引入资源管控技术,并在 7.0 版本中增强,通过资源组划分逻辑单元,限制资源使用,并允许在集群资源空闲时超额使用,优化资源利用。


核心优势


双层资源管控:TiDB 实现了包含流量控制和调度控制的双层资源管控机制,以确保操作在资源限额内执行,并在负载变化时优先处理高优先级任务。


I/O 资源限制:基于存储计算分离架构,TiDB 对关键的 I/O 资源进行限制,解决了数据库系统的资源瓶颈问题。


资源抽象与统一单位:TiDB 将资源抽象成统一单位进行分配和限制,简化管理并保持灵活性,以自适应地完成最佳调度。


资源利用率提升:在资源充足时,TiDB 允许业务超过资源组限制,以提高资源的整体利用率。


用量统计与反馈:TiDB 提供精确的用量统计反馈,帮助用户通过监控面板优化配置,并进行成本分摊。


灵活的资源绑定:TiDB 支持在不同级别(用户级、会话级、语句级)绑定资源,以适应多样化的资源控制场景。


管理方式


资源管控引入了“资源组(Resource Group)”的概念,通过设置“用户”和“资源组” 的对应关系,把会话与用户组进行绑定,利用“用量 (RU)”对资源限额进行定义。结构如下:



资源组(Resource Group):是 TiDB 中用于资源管理的逻辑单元,每个会话都归属于一个资源组,共享该组的资源限额。TiDB 允许将数据库用户映射到不同的资源组,未明确指定资源组的用户则默认关联至系统预设的default 资源组。


资源限额:TiDB 通过资源组(RU)配置用量,统一衡量CPU、IOPS 和 IO 带宽,支持 BURSTABLE 模式超用空闲资源。用户可通过监控面板优化资源配置,通过实际负载测试确定系统用量上限。


配置步骤:

  • 启用资源管控

  • 估算集群容量

  • 根据实际业务目标规划和创建资源组

  • 将用户 usr1 的资源组设置为 rg1


场景演示


假定我们有三个租户分别运行三种不同的业务形态,每类业务有不同的管控目标:


面对多租户资源管理,若采用物理隔离,则需为每租户分配资源,导致资源浪费;若共用集群,则难以避免相互影响。TiDB 的资源管控技术允许创建不同资源组,实现资源的有效隔离与合理分配。


为租户 oltp 分配一个较高的用量,租户 batch 和 租户 hr 则相对低,这样在系统资源紧张的情况下,保证租户 oltp 的服务质量。


租户 oltp 和 batch 的资源组设置为 burstable, 这样租户 oltp 发生超预期的负载,仍旧可能会保证质量;而当整个集群负载有空余时, 租户 batch 可以利用空闲资源加速其工作。


创建资源组


创建租户对应租户,并设置其所属的资源组


通过 TiDB 资源管控技术,我们模拟了不同租户负载,发现其能及时响应负载变化,保持 oltp 租户低响应时间,限制 hr 租户吞吐量。这证明了 TiDB 能在一套系统中满足多个租户需求,同时提升资源效率。


资源管控技术协助企业

兼顾质量与成本


资源管控技术解决了负载波动导致的服务质量问题,防止应用资源过载,适用于新业务灰度测试。它还支持数据库多租户隔离,帮助企业降低运行成本。成本的节约主要来自几个方面:


节省预留资源:通过合并多个业务系统到一个 TiDB 集群中,减少预留空间,利用 TiDB 的透明扩展性应对负载波动和业务增长,避免资源浪费。


缓解峰值谷值波动:整合不同负载峰谷的系统,降低整体负载波动,提高资源利用率,减少低负载时的硬件浪费。


快速扩展与收缩:面对业务活动,共享资源并快速调整计算资源,无需重复部署,节省人力和成本。


提升运维效率:集成多个业务系统,减少管理实体和系统数量,降低运维难度和成本。


点击此处阅读原文


中泰证券 x TiDB

TiDB 7.1 多租户在中泰证券中的应用


项目背景


受国际环境和国家政策推动,国产化系统在全国范围内快速推广。中泰证券在改造中采用 TiDB 及国产软硬件,增强自主可控能力。中泰科技研发部使用两套 TiDB V7.1 集群整合业务系统,分别服务外部和内部客户。TiDB 优化了大表处理和复杂 SQL 性能,简化了运维,降低了成本,提高了开发效率。然而,由于这两套集群共用多套业务系统,迫切需要资源管控技术,以确保每个业务系统拥有独立的资源池。


TiDB 多租户介绍


TiDB 6.6 引入资源管控(RC),7.0 版本优化,通过资源组限资源使用,引入 burst 属性,提高资源利用率。这个特性满足了目前一些企业的需求,也可以顺带解决了部分用户的痛点:


业务系统间影响和干扰:某个业务系统的非预期负载变化会影响其他业务系统的正常运行。


分析业务对交易的影响:对资源需求较高的数据分析或批量作业会影响其他业务系统的响应时间。


运维操作对资源的消耗:数据备份、统计信息收集等后台任务可能会影响服务质量。


具体应用和实施


资源评估:打开 Dashboard 页面,在左侧菜单列表中找到 Resource Manager,在 Estimate Capacity 中 根据标准测试类型进行资源评估。


应用绑定 RU:通过梳理数据库中的业务用户,确定哪些用户是属于哪些业务系统,方便后面将不同的资源组与不同的用户绑定。


观察应用 RU 使用情况:完成绑定后 ,TiDB 可以实时统计到各个业务消耗的资源情况。生产运行一段时间后,需要观察业务实际消耗 RU, 完成后续调整。


RU 使用收益


由于目前 TiDB 服务器资源充足,并且各个业务系统的峰值谷值都具有同一性,每个业务系统的重要程度也差不多。所以 TiDB 这个多租户特性带来的价值主要体现在资源的可观测性和可配置性上。


在资源可观测性上:有了 RU,结合 Dashboard,可以清楚的观察到每个业务系统使用了多少资源,TiDB 整个集群资源是否充足,是否需要添加资源。


在资源可配置性上:TiDB 能够在资源紧张时通过在线调整 RU 大小来控制资源减小对业务的影响从而实现有效管理资源。


点击此处阅读原文


多点DMALL x TiDB

从 100+ 套 MySQL 到一套 TiDB,

资源管控让多库整合后顾无忧


背景


多点 DMALL 推进零售 SaaS 私有化项目,以提高系统效率。SaaS 业务需频繁调整逻辑,对数据库要求极高,包括可扩展性、多租户管理、高可靠性等。TiDB 数据库满足这些需求,已在多点 DMALL 广泛应用。


系统改造中,通过整合应用和数据库降低复杂性和成本,将 Docker 实例和数据库集群数量减半。计划将多个 MySQL 集群合并为一个 TiDB 集群,利用其资源管控特性优化数据库合并流程,提升成本效率。


迁移实施


MySQL 合库到 TiDB 前提条件


在私有化项目中,计划将 QPS 较低的 MySQL 集群合并至TiDB,以优化资源。选择原则排除了高 QPS 业务、使用DDH 的集群,以及具有特殊数据库结构和未接入配置中心的集群。此次调整涉及 104 个 MySQL 集群,其中 75 个合并至 TiDB ,29 个下线,释放 212G 内存和 1.1T 磁盘空间。


合库目标 TiDB 版本升级至 7.5


升级前我们已经在测试环境中进行了充分的验证,并进行了备份兜底。本次我们通过 tiup 进行升级,过程相对顺利,升级前后读写延迟有降低 40-50% 左右,性能提升明显。


TiDB 计算节点新扩容两台


我们给 MySQL 服务器增加了两个计算节点,提高了性能,减少了高并发时的写入延迟,并通过智能资源管理确保了数据同步和合库操作的顺畅,支持业务的持续增长。


同步过程中的参数配置



对 TiDB 有压力库进行资源隔离


TiDB 资源管控特性提供了两层资源管理能力,包括在 TiDB 层的流控能力和 TiKV 层的优先级调度的能力。两个能力可以单独或者同时开启,TiDB 提供用户、会话级、语句级别设置资源组,可将压力大的应用绑定到某个资源组后,TiDB 层会根据用户所绑定资源组设定的配额对用户的读写请求做流控,TiKV 层会根据配额映射的优先级来对请求做调度。


通过流控和调度这两层控制,可以实现应用的资源隔离,满足服务质量 (QoS) 要求。TiDB 资源隔离不是分配 IO CPU 具体多少,而是通过配置 RU(Request Unit,是 TiDB 对 CPU、IO 等系统资源的统一抽象的计量单位,读写请求消耗不同的 RU)来实现。


全链路压测


TiDB 的资源管控特性提供 TiDB 层流控和 TiKV 层优先级调度,实现资源隔离和 QoS 。通过 RU 配置,而非具体分配IO、CPU,来管理资源。在 85 个数据库合并中,仅对 4 个大库开启资源管控。TiDB 集群预估可用 RU 2.7 万个,实际使用约 2 万个,其中 70% 分配给 4 个大库。RU 耗尽会导致 SQL 报错,需谨慎设置。7.5 GA 版本中,超 RU 会等待预估时间后报错,时间可调。Runaway Queries避免报错,但需等待 8.x 版本解决。


整体收益



简化系统架构与提高效率:将 100+套 MySQL 实例合并至 1 套 TiDB ,简化系统架构,降低复杂性,集中运维,提升开发团队效率。


降低硬件成本:TiDB 的高性能和资源使用效率减少了硬件需求,计算存储分离架构提高了资源利用率,存储成本降至原来的 1/3。


提升运维效率:运维成本降低 90%,统一监控管理简化部署维护,动态扩缩容提高了资源管理效率。


增强数据安全性:TiDB 的多副本和自动故障转移机制提高了数据安全性,资源隔离和动态扩缩容减少了业务中断风险。


点击此处阅读原文


 👇 立即咨询 TiDB 企业版 👇

文章转载自TiDB Club,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论