小 T 導讀：為什么我的集群數(shù)據(jù)分布得不均勻？這篇文章就是為了解決這個問題而寫的。但即便是沒有遇到“TDengine集群數(shù)據(jù)不均勻分布”這個現(xiàn)象的用戶，我們也推薦一讀。因為可能你目前只是在通用場景下使用集群，當一些特殊的場景出現(xiàn)時，深入地了解集群參數(shù)和數(shù)據(jù)庫架構原理才會真正地讓你做到游刃有余。至于集群如何搭建并不是本文主題，請嚴格根據(jù)官方文檔指示操作即可。官方文檔地址：https://taosdata.com/docs/cn/v2.0/cluster

為了充分理解文章內(nèi)容，首先大家一定要先了解vnode這個概念——每個 vnode 都是一個相對獨立的工作單元，是存儲時序數(shù)據(jù)（表）的基本單元，具有獨立的運行線程，內(nèi)存空間與持久化存儲的路徑。如果覺得不夠清晰的話，接著往下讀，隨著知識點的串聯(lián)，或許您會豁然開朗起來?，F(xiàn)在，我們來根據(jù)不同的場景給出具體分析：通常來說，數(shù)據(jù)分配不均勻有兩種。

場景一：表分布不均勻

需要測試表數(shù)量很少的數(shù)據(jù)庫性能時比較容易發(fā)生這個現(xiàn)象：你建了1200張表，但是卻發(fā)現(xiàn)有1000張表都在同一個vnode里面，只有200張表在另一個vnode里面。這種場景的壞處是，大部分表都進入了同一個vnode數(shù)據(jù)分布不均勻。此外還會導致只有兩個線程在為TDengine工作，因此無法利用計算機的多核（假設你的服務器CPU是雙核以上），從而浪費了TDengine的橫向擴展性。我先來簡單說說導致上述情況的原因——在TDengine中有這樣三個參數(shù)：

• maxVgroupsPerDb: 每個數(shù)據(jù)庫中能夠使用的最大vnode個數(shù)（單個副本），默認為0；
• minTablesPerVnode: 每個vnode中必須創(chuàng)建的最小表數(shù)，即是說這是第一輪建表用的步長（就是滿多少表寫下一個vnode），默認1000；
• tablelncStepPerVnode：每個vnode中超過最小表數(shù)后的遞增步長（即是后續(xù)滿多少表寫下一個vnode），默認1000。

在持續(xù)的建表過程中，TDengine就是靠這三個參數(shù)來控制表的分布的。大家可以在使用taosdemo批量建表的時候觀察一下：打開另一個taos窗口，在建表的時候一直輸入show vgroups命令，就能看到上述參數(shù)所控制的建表過程了：在第一個vnode中，表數(shù)量從0開始逐漸遞增，隨著數(shù)量達到minTablesPerVnode后，開始創(chuàng)建下一個vnode并繼續(xù)在其中建表。之后，重復該過程直到vnode數(shù)量達到maxVgroupsPerDb。之后，TDengine將回到第一個vnode繼續(xù)創(chuàng)建新表，在補充每個vnode的表數(shù)達到tablelncStepPerVnode數(shù)量后，后續(xù)以tablelncStepPerVnode為步長繼續(xù)在vnode中依次創(chuàng)建表，直到建完全部表。（描述看著繁瑣，自己動手跑一遍會很直觀）

明白了這個邏輯后，我們可以再來回頭看為什么會出現(xiàn)場景一的情況。答案已經(jīng)很簡單了，因為minTablesPerVnode這個參數(shù)的值默認是1000，所以前1000個表肯定會只出現(xiàn)在第一個vnode里，這就給用戶造成了數(shù)據(jù)分配并不平均的錯覺。

那么要如何調(diào)整成我們預期的效果呢。

別急——在此之前我們還需要再多了解一下這個參數(shù)：maxVgroupsPerDb。大家可能在taos.cfg中留意過maxVgroupsPerDb這個參數(shù)的值默認是0，根據(jù)參數(shù)描述，0代表的是自動配置。但是關于這個自動配置的詳情在官網(wǎng)上是有解釋的：“每個 Database 可以創(chuàng)建固定數(shù)目的 vgroup，默認與 CPU 核數(shù)相同，可通過 maxVgroupsPerDb 配置”。

如果不了解vgroup概念，建議到官網(wǎng)查看：https://taosdata.com/docs/cn/v2.0/architecture

?結合文章開頭說過的vnode概念——每個vnode都是具有獨立的運行線程的，這樣就一目了然了——如此設計默認值的原因就是希望vnode數(shù)等于cpu核數(shù)，從而充分地利用CPU資源，達到最大化服務器性能的目的。

好，現(xiàn)在我們終于可以回到場景一并提出我們的解決方案了。

假設我們是4核服務器，那么默認的最大vgroups就是為4個。進入場景一當中，每個vnode只要存儲300個表就好了。這時候只需要調(diào)整minTablesPerVnode值為300，這樣就可以做到表均勻分布在數(shù)據(jù)節(jié)點中了。

場景一屬于相對特殊的情況，而默認配置卻只能針對最通用的一個場景。對于大部分用戶來說，只要你的測試場景是創(chuàng)建萬表級別，都是可以看到表在vnode中按序且平均分配的。比如你有一臺4核CPU的機器，計劃創(chuàng)建4萬個表。那么使用默認配置就會生成4個vnode，最終的結果就是每個vnode存儲1萬張表，就不會出現(xiàn)數(shù)據(jù)不均的現(xiàn)象了。

這里我們可以多討論一下，既然默認配置的maxVgroupsPerDb是可以充分利用CPU的話。那么這個參數(shù)還有什么修改價值呢？如果沒有修改價值的話它為什么還會是一個對外公開的參數(shù)呢？

別急，我們接下來進入下一個場景。

假設你的CPU核數(shù)為4，但是我們把maxVgroupsPerDb設成8。其中只有前4個vnode的數(shù)據(jù)會比較熱，后續(xù)4個vnode中的數(shù)據(jù)的使用頻率則比較低。看似多開了很多vnode，但是這樣的設置和使用默認配置比起來，反而會降低前四個vnode的負擔從而增加性能。所以，默認參數(shù)雖然通用，但是有時候適當?shù)男薷臅寯?shù)據(jù)庫變得更好，這就需要使用者結合實際業(yè)務場景做評估了。目前，該參數(shù)仍是一個全局變量，未來或許會變成數(shù)據(jù)庫級別的變量以方便不同數(shù)據(jù)庫之間業(yè)務的差異。

而minTablesPerVnode，tablelncStepPerVnode這兩個變量由于使用相對復雜，所以目前并沒有出現(xiàn)在taos.cfg當中，屬于標題中提到的“神秘參數(shù)”。雖然它們設置了適當?shù)哪J值（1000）來應對大多數(shù)場景，但是當業(yè)務場景發(fā)生變動出現(xiàn)不適配的時候，就需要我們自己手動修改這些參數(shù)了。具體修改方式如下：打開taos.cfg后在空白區(qū)域添加如下內(nèi)容，重啟數(shù)據(jù)庫服務進程即可。如果是集群環(huán)境，那么需要在每一個節(jié)點的taos.cfg中都做一樣的配置后重啟數(shù)據(jù)庫服務進程。

場景二：vnode分布不均勻

這種情況就比較簡單了，在批量創(chuàng)建完很多表后，有時候你可能會發(fā)現(xiàn)：“咦？為什么這個數(shù)據(jù)節(jié)點上有6個vnode，另外一個節(jié)點只有2個vnode?！?/p>

在解釋這種情況之前，我們需要知道另一個TDengine相當重要的概念——mnode（管理節(jié)點）。

關于mnode，官方文檔的描述十分清晰：

管理節(jié)點(mnode): 一個虛擬的邏輯單元，負責所有數(shù)據(jù)節(jié)點運行狀態(tài)的監(jiān)控和維護，以及節(jié)點之間的負載均衡。同時，管理節(jié)點也負責元數(shù)據(jù)(包括用戶、數(shù)據(jù)庫、表、靜態(tài)標簽等)的存儲和管理，因此也稱為 Meta Node。在集群中，為了保證mnode的高可用，可以配置多個mnode副本，副本數(shù)由系統(tǒng)配置參數(shù)numOfMnodes決定，有效范圍為1-3。

可以看出，mnode和vnode一樣，都是以master-slave的模式分布在節(jié)點中的。因此，在做數(shù)據(jù)的負載均衡的時候，mnode也會是被計算在內(nèi)的，而具體的計算方式就是，一個mnode等價于n個vnode，這個n就是由下面這個參數(shù)控制的。

而查看mnode的分配情況的命令如下：

這回我們就知道為什么會出現(xiàn)場景二的情況了——只有2個vnode分布的數(shù)據(jù)節(jié)點上一定是有mnode在工作的。

正是它，頂替了原本應該出現(xiàn)在這的vnode名額。

尾記

寫到這里就差不多了，但作為作者很想和大家閑聊幾句。

TDengine雖然使用簡單方便，但是想要最大化它的價值還是需要一番研究的。而官方文檔是作為TDengine的百科全書而存在的，某種程度上，它可能并不適合串聯(lián)實際應用場景。所以，為了填補這塊空白，所以我們在推送的文章中會很注意產(chǎn)品與實際場景的結合以及串聯(lián)。最終的目標，是讓我們的文章能夠形成在很多實際使用場景下的閉環(huán)說明書。這樣，就可以讓TDengine用戶的使用體驗大幅上升。

空口無憑，我們?nèi)绾巫龅酱?lián)不同實際的應用場景呢。很簡單，讀完本篇文章可能您已經(jīng)了解了如何正確的配置集群的數(shù)據(jù)分布了。結合文章《TDengine 的用戶如何優(yōu)化數(shù)據(jù)的寫入速度？》，想必您又已經(jīng)對寫入數(shù)據(jù)的性能調(diào)試有了一定的認知。再讀文章《【社區(qū)精選】在Docker環(huán)境下，TDengine的客戶端為什么連不上集群？》，您又對在docker環(huán)境下搭建TDengine集群搭建有了一定的了解。

搭建TDengine的知識體系，就和搭建TDengine的集群一樣，需要一步一步慢慢積累起來。

開源文化的本質就是互相幫助，社區(qū)用戶為我們貢獻了很多。因此，我們也希望可以用同樣的方式回報大家。