黄东旭解析 TiDB 的核心优势
617
2024-04-10
在我的设想里面,我应该不会这么早用到这个特性,原因很简单,整个TiDB集群根本不涉及多租户的使用场景。 应该说目前TiDB集群中的用户就2个:dmuser用户负责把上游mysql写入流量接入tidb集群;biuser只有只读权限配置到了metabase里面,给metabase查询用。 即便是我要用到这个特性,也应该是在有一天真的使用tidb集群替换上游的多套mysql之后。那个时候是个典型的多租户使用场景。 然而,首先让我对这个特性感兴趣的原因是RU。
资源管控的基本单位是RU。 https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control#%E4%BB%80%E4%B9%88%E6%98%AF-request-unit-ru
Request Unit (RU) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的计量单位,用于表示对数据库的单个请求消耗的资源量。请求消耗的 RU 数量取决于多种因素,例如操作类型或正在检索或修改的数据量。
如果让我说RU好在哪里,首先就好在RU是抽象的。
看看我这个4核8g乞丐版集群的监控吧。
接入上游mysql写入流量后,cpu一直不怎么高,除非执行大表的导入。但tikv的内存一直不低,tikv内存超80%的告警一直在。所以我干脆设置了一个长达1年的静默期忽略了它。io图的单位不是百分比,我看对应的数值很难评估当前io离极限有多远。
那问题来了,当老板问我,我准备上游再切10台同样mysql进TiDB集群,你的集群能抗的住吗?
我该怎么回答他呢?这3项指标有高有低,甚至有些本菜鸡都没有量化的标准。我敢说——行,放马过来;或者:不行,得加钱吗?
以上这个情况是我不能接受的。
经过抽象的RU却可以解决我的问题。我现在已经接入了10+套上游的mysql写入流量。
因为dmuser基本都是写入操作,我只要进入资源管控界面,看下预估的oltp_write_only RU是多少,再看看当前的RU是多少就可以回答老板的问题了。
对于我这种非专业人士,我不需要关注cpu,内存,io。这些太专业,太具体。也许有朝一日,我可以成为大佬靠这些指标来更加准确的评估集群的负载,但不是现在。
资源管控界面显示,预估oltp_write_only RU是3w6,当前是800.我可明确的告诉老板,再来10套绝对没有问题。
非专业人士使用预估oltp_write_only RU/oltp_read_only RU,再结合当前实际的RU消耗量,来评估集群的读写负载,可能是比cpu,内存,io这些更加直观的。
正是在这种对比下,我才确认当前的TiDB集群负载很低——即便某些节点内存占用高。
那下一个问题就是这个oltp_write_only RU的评估准确吗?
通过负载校准RU需要一定的负载。
想想我之前一导入大表,tikv就轮流挂的盛况。来点负载根本不是事,安排。
于是在我执行了一个大表导入后,
校准的值比预估高一些
但是付出的代价也是触目惊心的
负载校准的值是比实际要高一些,不过从tikv的表现来看,它更像是在警告我,最好不要跑到这么高的RU。
听人劝吃饱饭,改。
tikv的内存告警一直是让我觉得战战兢兢的原因。而tikv也经常用实际行动告诉我,4核8g这个乞丐版的配置对tikv来说是不靠谱的。
经过上面的测试,我决定还是按照预估的数字36000RU来设置dmuser这个偏向写的用户的RU上限,负载校准后的值是比这个高,但代价是不稳定,这就没有办法采纳了。
CREATE RESOURCE GROUP max_write_rg RU_PER_SEC = 36000 PRIORITY = MEDIUM;BURSTABLE参数不采用。原因同样是集群的稳定,我怕临时BURSTABLE一下,tikv又挂了。
绑定dmuser到这个资源组。
ALTER USER dmuser RESOURCE GROUP max_write_rg;因为绑定后只对新建会话有用,干脆重启一下角色为tidb的节点
tiup cluster restart <cluster_name> -R tidb再执行导入,4核8g的配置,cpu最高也就在350%左右徘徊,不会再跑到380%以上去了。
执行导入的时候对读取任务也没有任何影响。
可以看到导入开始,写流量和读流量就变成两条平行线。中途有读取进来的时候,读流量会快速越过写流量,但写流量不会有任何抖动。有序,多么美妙。
在导入期间的database time拆解如下:
可以看到dm大表导入任务相关的replace和commit耗时明显变长。其他读取相关的操作时间也变长了一些,但绝对在可以接受的范围内。delete和update耗时也在可以接受的范围,说明其他进入到sync环节的dm同步任务并没有受到显著的影响。
既然看上去稳定多了,就该浪一点了。
上一篇完成了生成列的改造,上游10+个库的日志表都需要全部重新导一遍。7.1版本之前我反复提醒:大表的导入task最好是错开执行,那现在就多起几个大表的导入task看看。把task中的pool-size调回默认值。不特别关注该参数设置。起多个task。观察tikv一直稳定运行,再也没有发生tikv轮流挂的情况。
事实上,自从将dmuser加入资源管控之后,即使是我这个乞丐版的4核8g配置的tikv也再没有挂过。一直稳定运行到现在。
从我粗浅的认知来说:资源管控的问题在于,读写RU不能分开限制
从某种程度上,我觉得资源管控对我的系统稳定性的贡献这么大,完全是因为在当前这个场景下,我的读写用户是完全分离的。 我可以根据oltp_write_only估算的RU数量给dmuser设置资源组。 我还可以根据oltp_read_only估算的RU数量给biuser设置资源组。 这两个组都能确保各自RU的用量不会超过他们各自实际行为的上限。 哪怕我能看到如下这个提示信息,
而实际使用过程中,集群的稳定,确实是被资源管控有力的保证了。
但如果以后从mysql完全转向TiDB,情况就会变得复杂,每个游戏服执行的是读写混合负载。 当前集群读写RU并不均衡,读只有7000,而写是3w6000. 我估计到时候我只能设置一个7000RU的资源组取读写这两者的最小值,作为混合负载的用户的资源组。 当然这个判断是武断的,因为我的集群实际已经是生产系统了,我也没想出更好的混合负载测试方案。 这方面我还要多学习其他大佬的资源组设置方式。
从4月开始有想法,到目前基本改造完成,对数据库再无任何数据获取死角。 大部分统计都可以在10s以内获得结果——在没有资源上tiflash的情况下。如果业务人员对这个结果有任何疑问,只要慢慢去掉聚合的维度和聚合的函数,就可以直接追踪到原始记录。 这个上钻/下钻的过程是流畅的。因为不会影响上游生产环境,可以大胆的鼓励业务人员在数据中探索。 从mysql迁移到TiDB的过程也是愉快的。 全部使用4核8g来组成这个集群,也来我自己对于分布式系统的一个根深蒂固的认知。 即,分布式系统从诞生的第一天起,就不是为了让更大马才能拉更大的车。它从诞生的第一天起,解决的问题就是蚂蚁如何咬死象。 虽然有点运气的因素——7.1版本恰好发布了资源管控特性,保证了集群资源不足时的稳定性。 但这也同时证明了,TiDB是一个好的分布式系统。 好的分布式系统就应该能应付这种情况。 TiDB证明了自己。也证明了我的选择没有错。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。