共计 1753 个字符，预计需要花费 5 分钟才能阅读完成。
正如咱们之前所言，在 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 的值则须要联合多方因素做更精细化的计算，须要本人了解和多多调试，也欢送分割企业版团队失去更深层次的性能优化。
