正如我们之前所言，在 3.0 当中，我们在产品底层做了很大的变化调整，除了架构更加科学高效以外，用户体验也是我们重点优化的方向。以之前一篇文章为例：对于 Update 功能，用户不再需要任何配置 ，默认即是比 2.0 更完善的机制。

（TDengine 3.0 的 Update 功能和 2.0 有何区别？）

切换到 3.0 版本之后，我们面对的第一个问题就是建库建表，在 3.0 版本中，这部分逻辑发生了重大变化，这对于 3.0 初体验的用户来说是十分重要的，是数据库后续查询/写入性能保障的根基。有些表数量比较多的用户刚换到 3.0 的时候，会感觉性能和 2.x 差一些，其实就是因为建库时使用了默认配置，导致 vgroup 数量只有 2 个，因此无法利用到TDengine 多线程并行的特性来处理数据。

相比起 2.0 ，3.0 的建表策略控制是很简单的，它可以让用户无难度无成本地找到自己适合的配置。

简而言之：只需要在建库的时候指定合适的参数即可。

在 2.0 版本中，很多用户都阅读过这篇文章：这几个神秘参数，教你TDengine集群的正确使用方式，以期用自定义的建表逻辑来获得更好的性能，更合理的开销。

这篇文章中的几个参数的逻辑着实是需要读者好好理解一番的，而它复杂的根本在于，在 2.0 版本下，每个 vnode 的表数量在固定后是不可再调整的，所以只可以通过前期设定相对复杂的规则来实施控制。

而在 3.0 中，为了支持云原生场景下资源的灵活调配，不论是时序数据与元数据都需要分布式技术才可以做到。为此，我们把存在于 mnode 的普通表元数据移除（具体细节可参考：聊聊 TDengine 3.0 中的事务机制 - TDengine | 涛思数据），让其完全分布到了 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 的关系并不清晰，可以先移步 整体架构 | TDengine 文档 | 涛思数据）

基于以上全新的建表方式，我们可以发现，所建的每一个表的走向完全是受哈希函数来控制的，我们只需要控制好容器的数量就行了。

因此，在 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 的值则需要结合多方因素做更精细化的计算，需要自己理解和多多调试，也欢迎联系企业版团队得到更深层次的性能优化。