正如(ru)我(wo)們(men)之前所言，在(zai) 3.0 當中(zhong)，我(wo)們(men)在(zai)產品底層(ceng)做了很大的變(bian)化調整，除了架(jia)構更加科(ke)學高(gao)效以(yi)外，用戶體驗也是(shi)我(wo)們(men)重點優化的方(fang)向。以(yi)之前一篇文章為(wei)例：對于 Update 功能，用戶不(bu)再需(xu)要任何配置 ，默認即是(shi)比 2.0 更完善的機制。（）
切換到 3.0 版本之后（《》），我們面對的第一個問題就是建庫建表，在 3.0 版本中，這部分邏輯發生了重大變化，這對于 3.0 初體驗的用戶來說是十分重要的，是數據庫后續查詢/寫入性能保障的根基。有些表數量比較多的用戶剛換到 3.0 的時候，會感覺性能和 2.x 差一些，其實就是因為建庫時使用了默認配置，導致 vgroup 數量只有 2 個，因此無法利用到 TDengine 多線程并行的特性來處理數據。
相比起 2.0 ，3.0 的建表策略控制是很簡單的，它可以讓用戶無難度無成本地找到自己適合的配置。
簡而言之：只需要在建庫的時候指定合適的參數即可。
在 2.0 版本中，很多用戶都閱讀(du)過這篇文章：，以(yi)期用自定義的(de)建表(biao)邏輯來獲得更好的(de)性能(neng)，更合理的(de)開銷。
這篇(pian)文章中的(de)(de)幾個(ge)參(can)數(shu)的(de)(de)邏輯(ji)著實(shi)是需要讀者好好理(li)解(jie)一(yi)番(fan)的(de)(de)，而(er)它(ta)復雜(za)的(de)(de)根本在于，在 2.0 版本下，每個(ge) vnode 的(de)(de)表(biao)數(shu)量在固定(ding)后(hou)是不可(ke)再調整的(de)(de)，所以只可(ke)以通過前(qian)期(qi)設定(ding)相(xiang)對(dui)復雜(za)的(de)(de)規則來實(shi)施控制。
而在 3.0 中，為了支持云原生場景下資源的靈活調配，不論是時序數據與元數據都需要分布式技術才可以做到。為此，我們把存在于 mnode 的普通表元數據移除（具體細節可參考：//yakult-sh.com.cn/engineering/14534.html），讓(rang)其完(wan)全(quan)分布到了 vnode 上(shang)，采取了一致性哈(ha)希這種具有(you)較好的容錯(cuo)性和(he)可擴展性的算法，以(yi)支持(chi) vnode 的可拆分的特性（該特性會在(zai)未來(lai)的 3.x 企業版本中(zhong)發(fa)布）
因此(ci)， 3.0 和 2.0 的建表流程是完全不(bu)一樣的，細節如下(xia)：
- 首先在建庫時，每個 vgroup 會負責存儲 0 至 2 的 32 次方-1 的等分長度；
- 建表階段，TDengine 3.0 首先會在客戶端通過對表名進行 hash 計算，得到一個 hash 值；
- 向管理節點發出 rpc 請求，取回數據庫配置和 vgroups 的相關內容等信息；
- 把建表請求中的 hash 值和取回的每個 vgroup 的 hash 范圍做一個比對；
- 把請求直接發送到對應的 vgroup 中的 vnode 上完成建表。（如果對 vgroup 和 vnode 的關系并不清晰，可以先移步?）
基于(yu)以(yi)上(shang)全新的建表方(fang)式，我們可以(yi)發現，所建的每(mei)一個表的走向完全是(shi)受哈希函數(shu)來控制(zhi)的，我們只需(xu)要控制(zhi)好容器的數(shu)量就行了。
因此，在 database 級別，我們引入了這樣一個參數—— vgroups ，用來指定該數據庫使用的 vgroup 的數量。
比如：
create database test vgroups 8 ;
就會創建一個擁有 8 個 vgroup 的數據庫 test ，你在這個庫下新建的所有表，都會均勻地分配在 8 個 vgroup 里面。
而在他(ta)的(de)上(shang)一級(ji)，還有(you)更(geng)高級(ji)別的(de)參(can)數(shu) supportVnodes（默(mo)認(ren) /etc/taos/taos.cfg 中配置），它(ta)決(jue)定了該數(shu)據節點可以支持(chi)的(de) vnode 數(shu)量，默(mo)認(ren)值為(wei) 0 ，代表(biao) CPU 核數(shu)的(de)2倍。
我們建庫時需要確保所有 dnode（數據節點）的 supportVnodes 之和，大于等于所有庫的 vnode 數目之和即可，否則會就報如下錯誤：Out of dnodes，提示你需要補充新的 dnode。
顯然(ran)，在 3.0 的架構下，用戶在建表的時候就省心多了(le)，大(da)家只需根(gen)據硬(ying)件資源規劃(hua)好 vgroups 的數(shu)量就行了(le)。
在 vgroups 參數值的估算上，對于大部分場景依然保持和 2.0 一樣的邏輯。即——由于每個 vnode 都是一個相對獨立的工作單元，具有獨立的運行線程和內存空間，所以不超過該機器 CPU 核數的 2 倍即可。
但對于一些特定場景，vgroups 的值則需要結合多方因素做更精細化的計算，需要自己理解和多多調試，也歡迎聯系企業版團隊得到更深層次的性能優化。
