TiDB 7.1 LTS 发版:为关键业务提供业务稳定性和多租户场景支持

这篇具有很好参考价值的文章主要介绍了TiDB 7.1 LTS 发版:为关键业务提供业务稳定性和多租户场景支持。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

近日,企业级开源分布式数据库厂商 PingCAP 正式发布 TiDB 7.1 版本,这也是 2023 年度发布的首个 LTS(Long Term Support) 版本,汇集了来自 20+ 个真实场景带来的功能增强,累计优化和修复 140+ 功能,旨在提升关键业务的稳定性和性能,帮助开发人员和数据库管理员提高生产力并进一步降低总体拥有成本(TCO)。用户可在生产环境中使用 TiDB 7.1。

TiDB 半年版本回顾

TiDB 7.1 LTS 距离上一个 LTS 版本 6.5 已经过去了整半年,在这期间,PingCAP 对产品的关键能力做了大量的增强和优化,其中最重要的特性有:

● TiDB 7.0 提供了基于资源组的资源管控(Resource Control) :这使得 TiDB 在针对多租户场景有了很好的应对。事实上,经常有用户希望借助 TiDB 的可伸缩特性将多套业务系统归一到一个集群中,从而使得集群管理、资源利用都能得到有效的改进。资源管控特性提供了对多租户的支持,并解决了不同租户间资源争抢的问题。在新版本中,用户可以很方便地借助这个功能完善数据库整合的使用场景。

● Multi-RocksDB 特性 :借助将单一 TiKV 实例中的 RocksDB 拆成多份,TiKV 的写吞吐提升近三倍;此外,在新架构中数据分片(Region)大小将变得更大,由此减小维护分片所带来的开销,减少单位存储所需的固定 CPU 消耗,更节省成本。这使得大写入吞吐,或者需要大量存放温数据的 Data Serving 场景下,TiDB 的表现得到了本质的提升。

对于这些重要的重量级特性,在新版本中也将持续得到打磨和加强。这半年中,TiDB 在一些关键场景的性能也得到长足提升:

● 数据导入 Lightning 性能提升近 30% 

● 真实业务测试下,Analyze Table 性能提升 42%+ 

● 标准测试 TPC-H 和真实业务测试下,TiDB 分析能力分别提升 15% 和 25% 

● TiCDC 针对大型单表复制性能提升可达 90%+ 

TiDB 7.1 功能特性

TiDB 7.1 是PingCAP 计划在 2023 年发布的两个长期可支持(LTS)版本中的第一个,它提供了一个面向未来的数据库,可以为各种关键业务应用程序提供动力。TiDB 7.1 将为用户带来以下特性:

● 更稳定地支持关键业务负载 ,为 DBA 提供多工作负载稳定性控制,并显著改善尾部延迟;

● 以更少的资源提供更佳的性能 ,通过架构增强实现更高的吞吐以及更快的在线 DDL。

此外,TiDB 7.1 企业版增强了数据库审计功能,通过更细粒度的事件过滤控制、更友好的过滤条件设置方式、新增的 JSON 文件输出格式以及审计日志的生命周期管理,大幅提升系统的审计能力。

2.1 更稳定地支持关键业务负载

2.1.1 通过资源组改进资源管控的用户体验,提供更好的隔离性

PingCAP 在 TiDB 7.0 中增加了通过资源组进行资源管控的功能,为 TiDB database consolidation (数据库整合)方案奠定了基础,具有里程碑的意义。多个业务可共享同一个 TiDB 集群,DBA 可为不同的工作负载设置资源配额和优先级,例如为关键业务分配更高的优先级,确保其能够优先获得资源,避免受到其他工作负载的干扰。

在 TiDB 7.1 中,资源管控特性正式 GA 了,并加入了两个特性增强:

● 降低了在重写入密集型工作负载中出现的尾延迟:资源组通过资源配额和优先级控制工作负载。优先级由存储级别控制。当工作负载写入繁重时,基于优先级重新调度机制有时会造成更高的尾延迟(Tail Latency)。在 7.1 版本中,尾延迟被修正到预期水准。

● 增加原生负载校准工具,帮助用户设置更准确的资源资源分配:资源分配的基础是用户对负载的资源使用量有所了解。新增的校准工具将很好的帮助您评估相关信息,以合理配置资源组。最快的方法是从 SQL 接口运行校准命令来估计基准测试(如 TPC-C 和 sysbench)的资源使用情况。

2.1.2 多个热点场景下性能和稳定性提升

对 TiDB 的底层行存储 TiKV 有三个关键增强,以降低延迟提升稳定性(通过 p99 延迟衡量)。新版本引入了三项优化,分别针对三个级别热点进行处理:Key 级别、分片(Region)级别和节点级别:

● Key 级热点:锁冲突优化

● Region 级热点:TiKV 子任务的批处理化

● 节点级热点:引入了基于负载的副本读取

锁冲突优化(GA)

TiDB 引入了处理 Key 级热点的优化。在遇到许多单点悲观锁冲突的负载中,唤醒等待请求的算法在新版本中将表现得更稳定,最大限度地减少了重试的资源浪费,从而节省了整个集群的资源并降低了尾延迟。测试表明,当启用锁冲突优化时,如果吞吐量相对较小,即使在冲突最严重的工作负载中,新版本的尾延迟也将降低 40-60%。

TiDB 7.1 LTS 发版:为关键业务提供业务稳定性和多租户场景支持

TiDB 7.1 LTS 发版:为关键业务提供业务稳定性和多租户场景支持

批处理 TiKV 子任务(GA)

选择性较差的查询可能会导致需要读取许多数据。在 TiDB 的分布式存算分离架构中,这样的查询可能会带来数万或数十万个 RPC 请求用于获取数据,如果使用索引读取则将更进一步加重这一负担。

TiDB 服务器作为 TiKV 客户端,现在可以识别针对同一分片的批处理任务,并将这些批量发送到对应的存储节点。这大大减少了网络的 RPC 开销,使得这些查询更稳定。这个增强可以将相应场景中的延迟减少多达 50%。

基于负载的副本读取(GA)

这个特性用于优化节点级读热点。当大批量查询以不均匀的方式发起读取,可能会出现节点热点。注入 Index Lookup JOIN 这类常见的事情都可能会导致这种情况。一旦发生,读取请求会排队,当队列塞满时,一些请求可能会等待相当长时间。PingCAP 希望通过更均匀地分配工作来减少延迟。

新版本中,TiDB 引入了基于负载的副本读取来实现这一点。它为队列提供了一个可配置的持续时间阈值,当超过该阈值时,它会告诉 TiDB 开始优先考虑副本读取。在读热点的情况下,与不打散读热点相比,该功能可提高读取吞吐量 70%~200%。

2.2 更少的资源,更佳的性能

TiDB 7.1 提升了 TiDB 读、写以及管理操作的性能,以提供更好的用户体验。新版本中,TiDB 增加了多值索引以提供对 JSON 的查询效率。此外,在写入吞吐、分析查询速度和后台任务效率方面也进行了大量的改进和优化。

2.2.1 多值索引(GA)以增加速度和灵活性

多值索引也称为“JSON 索引”,这种新型辅助索引在 TiDB 6.6 中引入并在 7.1 中 GA。多值索引支持索引记录到数据记录的 N:1 映射,使得查询可以快速检查存储在 JSON 数组中的特定值。

无论该数据存储为 blob,还是邮政编码直接存储为 zip 数组,用户都可以创建多值索引来定位特定邮政编码存在于哪一行。

索引是使用表达式创建的,该表达式将 JSON 数据逻辑解析为生成列(Generated Column)和该列上的二级索引。如果用户将 JSON 存储为 blob,并且需要支持遍历多层嵌套的查询,只需创建一个索引以检索。

2.2.2 更快的 TTL(GA)

TTL (Time to live) 在PingCAP 的 TiDB 6.5 中作为一个实验特性进行了介绍,而在 7.1 中这个特性 GA 了。此外在新版本中,TiDB 节点可以共享 TTL 相关任务并并发执行,从而拥有了更好的性能和资源利用率。

2.2.3 延迟物化加速分析查询(GA)

TiFlash 是 TiDB 的列式存储引擎,在 7.1 版本中延迟物化特性 GA。当表扫描拥有高过滤性的时候,TiDB 优化器可选择让 TiFlash 启用延迟物化。开启该特性后,TiFlash 支持下推部分过滤条件到 TableScan 算子,即先扫描过滤条件相关的列数据,过滤得到符合条件的行后,再扫描这些行的其他列数据,继续后续计算,从而减少 IO 扫描和数据处理的计算量。

此功能的影响取决于实际负载和数据分布。在某些情况下,它可以显著减少延迟(在PingCAP 的测试中延迟最高可降低 70%)。TiDB 的查询优化器可以决定是否使用它,默认情况下打开是安全的。

2.2.4 Multi-RocksDB 存储引擎带来巨大性能提升

在 TiDB 6.6 中,PingCAP 引入了对 TiKV 存储架构的重大更改。虽然这个架构仍然是实验性的(默认关闭,并且只能在新集群中启用),但在这个 LTS 版本中,该特性获得重大加强,并在预生产环境中收到了很好的测试反馈。

在 TiDB 6.6 之前,单一 TiKV 节点所有 Region 共享一个 RockDB 存储引擎。新架构则将不同 Region 分别存放在不同 RocksDB。新架构的好处是显著的:

● 减少 RocksDB 对应的 LSM 负担,增加了吞吐量,测试结果显示写入吞吐量 增加了 200% 

● 使用不同 RocksDB 也会 减少 Compaction 带来的写放大,降低资源消耗。

● 更好的写入吞吐使集群的扩展 速度提高 500% 

● 在测试一些真实的客户工作负载时,PingCAP 观察到尾部延迟 减少了近 50% 

● 更小的单位存储消耗,使得集群可扩展性进一步增强。

在 TiDB 7.1 中,PingCAP 进一步提高了该特性的性能和稳定性,并添加了网络带宽优化。当前仍然缺失的是 TiCDC、BR 等生态工具的支持,当这些完成后PingCAP 将宣布这个特性 GA。

2.2.5 Online DDL 的大幅提升(实验特性)

在 TiDB 7.1 中,类似于前述 TTL 改进,PingCAP 引入了跨 TiDB 节点分配 DDL 作业的框架,以进一步提高性能。文章来源地址https://www.toymoban.com/news/detail-476960.html

到了这里,关于TiDB 7.1 LTS 发版:为关键业务提供业务稳定性和多租户场景支持的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 稳定性建设框架

    一、为什么要做稳定性建设 1、从熵增定律引出稳定性建设的必要性 物理学上,用“熵”来描述一个体系的混乱程度。卡尔·弗里德曼提出熵增定律,他认为在一个封闭的系统内,如果没有外力的作用,一切物质都会从有序状态向无序状态发展。 如果我们不希望系统变混乱,

    2024年02月08日
    浏览(30)
  • 3分钟了解Android中稳定性测试_手机稳定性测试,大厂软件测试高级多套面试专题整理集合

    先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7 深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前! 因此收集整理了一份《2024年最新软件测试全套学习资料》

    2024年04月26日
    浏览(33)
  • 如何做好垂直域稳定性

      一个小小的故障就可能造成巨大的负面影响,因此稳定性工作复杂却又至关重要。本文将通过故障预防、修复、复盘来讲解该如何建设一个稳定性体系。   来到阿里后,我的工作内容一直都是商品中心的稳定性,这份工作对于我个人在技术和经验上的成长提升是无比巨大的

    2024年02月11日
    浏览(49)
  • 【稳定性】秘密武器--功能开关技术

    继上篇【稳定性:关于缩短MTTR的探索】后,看到一些线上问题应急预案采用的是回滚方案, 但是在大部分牵扯代码场景下,开关技术才是线上问题快速止血的最佳方式 。比如履约平台组的Promise作为下单黄金链路,如遇线上问题的话, 采用通用的回滚方式需要5-10+分钟(500+台

    2024年02月08日
    浏览(41)
  • 如何区分排序算法的稳定性

            排序算法的稳定性是指在排序过程中保持相等元素的相对顺序不变。简单来说,如果一个排序算法能够保证相等元素的顺序不发生改变,那么它就是稳定的。以下是几种常见的排序算法的稳定性判断方法: 1.冒泡排序:         冒泡排序是稳定的,因为在比较相

    2024年02月09日
    浏览(29)
  • 主动发现系统稳定性缺陷:混沌工程

    这是一篇较为详细的混沌工程调研报告,包含了背景,现状,京东混沌工程实践,希望帮助大家更好的了解到混沌工程技术,通过混沌工程实验,更好的为系统保驾护航。 Netflix公司最早系统化地提出了混沌工程的概念。2008年8月,Netflix公司由于数据库发生故障,导致了三天

    2024年02月08日
    浏览(43)
  • 6.3 收敛性与稳定性

    数值计算方法的收敛性是指,当取步长趋近于零时,数值解趋近于精确解的速度。一般来说,数值计算方法的收敛性是判断其优劣的重要指标之一。 数值计算方法的收敛性可以通过数学分析来研究,一般需要对数值解和精确解之间的误差进行估计,以得到其误差的渐进界,从

    2023年04月23日
    浏览(39)
  • 使用monkey工具进行稳定性测试

    首先了解monkey是什么         monkey是Android系统自带一个命令行工具,可以运行在模拟器里或者真实设备中运行。monkey向系统发送伪随机的用户事件流,从而实现对正在开发的应用程序进行压力测试。 monkey包括很多选项,大致分为四大类: 1.基本配置选项,如设置尝试的事

    2024年01月25日
    浏览(54)
  • 灵魂三问之稳定性摸排

    前言 在之前写了篇文章《上线十年,81万行Java代码的老系统如何重构》,在文章后有同学留言问“ 这么复杂的改动,质量是如何应对的 ”,是一个特别好的问题,当时只是从现有的一些监控、测试、卡口手段上进行了回答。但在回答过程当中就在思考一个问题,交接过来的

    2024年02月08日
    浏览(36)
  • 数学建模之稳定性模型详解

    码字总结不易,老铁们来个三连: 点赞、关注、评论 作者:[左手の明天]   原创不易,转载请联系作者并注明出处 版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 对象仍是动态过程,而建模目的是研究时间充分长以后过程的

    2024年02月05日
    浏览(41)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包