正如我们之前所言,在 3.0 当中,我们在产品底层做了很大的变化调整,除了架构更加科学高效以外,用户体验也是我们重点优化的方向。以之前一篇文章为例:对于 Update 功能,用户不再需要任何配置 ,默认即是比 2.0 更完善的机制。(https://mp.weixin.qq.com/s/7E8kl9W8IXROx_K0EGQPkg)
切换到 3.0 版本之后,我们面对的第一个问题就是建库建表,在 3.0 版本中,这部分逻辑发生了重大变化,这对于 3.0 初体验的用户来说是十分重要的,是数据库后续查询/写入性能保障的根基。有些表数量比较多的用户刚换到 3.0 的时候,会感觉性能和 2.x 差一些,其实就是因为建库时使用了默认配置,导致 vgroup 数量只有 2 个,因此无法利用到 TDengine 多线程并行的特性来处理数据。
相比起 2.0 ,3.0 的建表策略控制是很简单的,它可以让用户无难度无成本地找到自己适合的配置。
简而言之:只需要在建库的时候指定合适的参数即可。
在 2.0 版本中,很多用户都阅读过这篇文章:https://mp.weixin.qq.com/s/H2GCESF40wnWYf4IKP_-9g,以期用自定义的建表逻辑来获得更好的性能,更合理的开销。
这篇文章中的几个参数的逻辑着实是需要读者好好理解一番的,而它复杂的根本在于,在 2.0 版本下,每个 vnode 的表数量在固定后是不可再调整的,所以只可以通过前期设定相对复杂的规则来实施控制。
而在 3.0 中,为了支持云原生场景下资源的灵活调配,不论是时序数据与元数据都需要分布式技术才可以做到。为此,我们把存在于 mnode 的普通表元数据移除(具体细节可参考:https://www.taosdata.com/engineering/14534.html),让其完全分布到了 vnode 上,采取了一致性哈希这种具有较好的容错性和可扩展性的算法,以支持 vnode 的可拆分的特性(该特性会在未来的 3.x 企业版本中发布)
因此, 3.0 和 2.0 的建表流程是完全不一样的,细节如下:
1.首先在建库时,每个 vgroup 会负责存储 0 至 2 的 32 次方-1 的等分长度;
2.建表阶段,TDengine 3.0 首先会在客户端通过对表名进行 hash 计算,得到一个 hash 值;
3.向管理节点发出 rpc 请求,取回数据库配置和 vgroups 的相关内容等信息;
4.把建表请求中的 hash 值和取回的每个 vgroup 的 hash 范围做一个比对;
5.把请求直接发送到对应的 vgroup 中的 vnode 上完成建表。(如果对 vgroup 和 vnode 的关系并不清晰,可以先移步 https://docs.taosdata.com/tdinternal/arch/)
基于以上全新的建表方式,我们可以发现,所建的每一个表的走向完全是受哈希函数来控制的,我们只需要控制好容器的数量就行了。
因此,在 database 级别,我们引入了这样一个参数—— vgroups ,用来指定该数据库使用的 vgroup 的数量。
比如:
create database test vgroups 8 ;
就会创建一个拥有 8 个 vgroup 的数据库 test ,你在这个库下新建的所有表,都会均匀地分配在 8 个 vgroup 里面。
而在他的上一级,还有更高级别的参数 supportVnodes(默认 /etc/taos/taos.cfg 中配置),它决定了该数据节点可以支持的 vnode 数量,默认值为 0 ,代表 CPU 核数的2倍。
我们建库时需要确保该 dnode(数据节点)的 supportVnodes 参数大于等于所有库的 vgroups 参数之和即可(集群同理,但需要留意多副本导致的 vnode 数量翻倍),否则会就报如下错误:Out of dnodes,提示你需要补充新的 dnode。
显然,在 3.0 的架构下,用户在建表的时候就省心多了,大家只需根据硬件资源规划好 vgroups 的数量就行了。
在 vgroups 参数值的估算上,对于大部分场景依然保持和 2.0 一样的逻辑。即——由于每个 vnode 都是一个相对独立的工作单元,具有独立的运行线程和内存空间,所以不超过该机器 CPU 核数的 2 倍即可。
但对于一些特定场景,vgroups 的值则需要结合多方因素做更精细化的计算,需要自己理解和多多调试,也欢迎联系企业版团队得到更深层次的性能优化。
标签:vgroups,建表,TDengine,vgroup,vnode,3.0,2.0 From: https://www.cnblogs.com/taosdata/p/17479748.html