小 T 導(dǎo)讀：為了讓大家更好地進行 TDengine 集群間的備份和遷移工作，一款名為 taosdump 的工具應(yīng)用程序被打造出來。在本篇文章中，我們對 taosdump 的使用方法和注意事項進行了相關(guān)匯總，給到有需要的開發(fā)者。

作為 TDengine 的一款工具應(yīng)用程序，taosdump 支持從運行中的 TDengine 集群備份數(shù)據(jù)，并將備份的數(shù)據(jù)恢復(fù)到相同或另一個運行中的 TDengine 集群中，其使用 Apache AVRO（https://avro.apache.org/）作為數(shù)據(jù)文件格式來存儲備份數(shù)據(jù)。

值得一提的是，taosdump 可以用 Database、超級表或普通表作為邏輯數(shù)據(jù)單元進行備份，也可以對 Database、超級表和普通表中指定時間段內(nèi)的數(shù)據(jù)記錄進行備份。在使用時，我們可以對 taosdump 指定數(shù)據(jù)備份的目錄路徑；如果不指定位置，它就會默認將數(shù)據(jù)備份到當前目錄；如果指定的位置已經(jīng)有數(shù)據(jù)文件，taosdump 會提示用戶并立即退出，避免數(shù)據(jù)被覆蓋。這意味著同一路徑只能被用于一次備份。如果大家看到相關(guān)提示，務(wù)必小心操作。

但需要注意的是，taosdump 是一個邏輯備份工具，它不應(yīng)被用于備份任何原始數(shù)據(jù)、環(huán)境設(shè)置、 硬件信息、服務(wù)端配置或集群的拓撲結(jié)構(gòu)。

安裝

taosdump 有以下兩種安裝方式：

• 安裝 taosTools 官方安裝包，你可以進入 http://www.fjzmyy.cn/all-downloads 此頁面找到 taosTools 并進行下載安裝。
• 單獨編譯 taosTools 并安裝，詳情請參考 taos-tools 倉庫（https://github.com/taosdata/taos-tools）。

常用使用場景

taosdump 備份數(shù)據(jù)

1. 備份所有數(shù)據(jù)庫：指定 -A 或 --all-databases 參數(shù)；
2. 備份多個指定數(shù)據(jù)庫：使用 -D db1,db2,... 參數(shù)；
3. 備份指定數(shù)據(jù)庫中的某些超級表或普通表：使用 dbname stbname1 stbname2 tbname1 tbname2 ... 參數(shù)，注意這種輸入序列第一個參數(shù)為數(shù)據(jù)庫名稱，且只支持一個數(shù)據(jù)庫，第二個和之后的參數(shù)為該數(shù)據(jù)庫中的超級表或普通表名稱，中間以空格分隔；
4. 備份系統(tǒng) log 庫：TDengine 集群通常會包含一個系統(tǒng)數(shù)據(jù)庫，名為 log，這個數(shù)據(jù)庫內(nèi)的數(shù)據(jù)為 TDengine 自我運行的數(shù)據(jù)，taosdump 默認不會對 log 庫進行備份。如果有特定需求對 log 庫進行備份，可以使用 -a 或 --allow-sys 命令行參數(shù)。
5. “寬容”模式備份：taosdump 1.4.1 之后的版本提供 -n 參數(shù)和 -L 參數(shù)，用于備份數(shù)據(jù)時不使用轉(zhuǎn)義字符和“寬容”模式，可以在表名、列名、標簽名沒使用轉(zhuǎn)義字符的情況下減少備份數(shù)據(jù)時間和備份數(shù)據(jù)占用空間。如果不確定是否符合使用 -n 和 -L 條件時，請使用默認參數(shù)進行“嚴格”模式進行備份。轉(zhuǎn)義字符的說明請參考官方文檔（https://docs.taosdata.com/taos-sql/escape/）。

需要注意

• taosdump 1.4.1 之后的版本提供 -I 參數(shù)，用于解析 avro 文件 schema 和數(shù)據(jù)，如果指定 -s 參數(shù)將只解析 schema。
• taosdump 1.4.2 之后的備份使用 -B 參數(shù)指定的批次數(shù)，默認值為 16384，如果在某些環(huán)境下由于網(wǎng)絡(luò)速度或磁盤性能不足導(dǎo)致 “Error actual dump .. batch ..” ，可以通過 -B 參數(shù)調(diào)整為更小的值進行嘗試。
• taosdump 的導(dǎo)出不支持中斷恢復(fù)，所以當進程意外終止后，正確的處理方式是刪除當前已導(dǎo)出或生成的所有相關(guān)文件。
• taosdump 的導(dǎo)入支持中斷恢復(fù)，但是當進程重新啟動時，會收到一些“表已經(jīng)存在”的提示，可以忽視。

taosdump 恢復(fù)數(shù)據(jù)

如果我們想要恢復(fù)指定路徑下的數(shù)據(jù)文件，方式是：使用 -i 參數(shù)加上數(shù)據(jù)文件所在路徑。如前文提及，我們不能使用同一個目錄備份不同數(shù)據(jù)集合，也不能在同一路徑多次備份同一數(shù)據(jù)集，否則備份數(shù)據(jù)會造成覆蓋或多次備份。

需要注意

taosdump 內(nèi)部使用 TDengine stmt binding API 進行恢復(fù)數(shù)據(jù)的寫入，為提高數(shù)據(jù)恢復(fù)性能，目前使用 16384 為一次寫入批次。如果備份數(shù)據(jù)中有較多列的數(shù)據(jù)，可能會導(dǎo)致產(chǎn)生 “WAL size exceeds limit” 錯誤，此時可以通過使用 -B 參數(shù)調(diào)整為一個更小的值進行嘗試。

寫在最后

如果大家想要查閱 taosdump 詳細命令行參數(shù)列表，可以進入 https://docs.taosdata.com/reference/taosdump/ 獲取。毫無疑問，如果你掌握了上述 taosdump 使用指南，一定能幫助你較為完美地解決所遭遇的數(shù)據(jù)遷移問題。但如果在應(yīng)用過程中出現(xiàn)了一些個性化難題，也無需心急，你可以進入 TDengine 用戶交流群尋找?guī)椭?/p>

有些公司為了避免麻煩，就選用 OpenTSDB，因為它把分布式版本也開源了。從使用的角度來看，OpenTSDB 底層的存儲引擎用的是 HBase，安裝維護極為復(fù)雜，存儲壓縮性能不夠，查詢效率也很低，不是一個優(yōu)秀的產(chǎn)品。但它仍然有相當多的用戶，這唯一的原因就是由于它支持分布式，可以水平線性擴展。

TDengine 的設(shè)計是基于單個硬件、軟件系統(tǒng)不可靠，基于任何單臺計算機都無法提供足夠計算能力和存儲能力處理海量數(shù)據(jù)的假設(shè)而進行設(shè)計的。因此 TDengine 從研發(fā)的第一天起，就是按照水平擴展、高可用架構(gòu)進行設(shè)計的。通過對數(shù)據(jù)進行分區(qū)、分片，而且采用虛擬節(jié)點(vnode)技術(shù)，保證系統(tǒng)的處理能力是水平擴展的。如果要增加系統(tǒng)的處理能力，只需要增加新的節(jié)點即可。

更好的是，和 InfluxDB集群功能閉源不同，2020年8月，TDengine 團隊將集群版開源了。
TDengine 是通過數(shù)據(jù)采集點以及時間兩個維度，對大數(shù)據(jù)進行切分，實現(xiàn)水平擴展的。

分片：在 TDengine Database 的設(shè)計與實現(xiàn)里，一個集群有多個節(jié)點，每個節(jié)點可以有一個或多個虛擬節(jié)點(vnode)，每個虛擬節(jié)點里存儲了一定數(shù)量的數(shù)據(jù)采集點的數(shù)據(jù)，而一個數(shù)據(jù)采集點的數(shù)據(jù)永遠只存放在一個 vnode 里。這樣如果有很多數(shù)據(jù)采集點，這些數(shù)據(jù)采集點的數(shù)據(jù)將會分布在多個 vnode 上，分布在多個節(jié)點里。數(shù)據(jù)寫入時，TDengine Database 的客戶端將要寫入的數(shù)據(jù)直接寫入對應(yīng)的 vnode，從而實現(xiàn)寫入的水平擴展。對于單個數(shù)據(jù)采集點數(shù)據(jù)的查詢，毫無疑問，是水平擴展的，節(jié)點越多，吞吐率就越大。對于聚合查詢，查詢請求將先發(fā)送到對應(yīng)的 vnode 里，vnode 先做完聚合操作，客戶端然后將來自多個 vnode 的查詢結(jié)果做第二次聚合，因為 vnode 數(shù)量有限，這樣在客戶端做的聚合查詢計算量不大，從而實現(xiàn)聚合查詢的水平擴展能力。

分區(qū)：除將數(shù)據(jù)分片之外，TDengine 還將一個 vnode 里存儲的時序數(shù)據(jù)按照時間段進行切分。每個時間段的數(shù)據(jù)都一定保存在一起，不同時間段的數(shù)據(jù)不會有交集，時間段可以是一天，幾天，一周，由用戶自己定義。按照時間段切分時序數(shù)據(jù)有很多好處，查詢數(shù)據(jù)時，根據(jù)時間段，可以直接定位要查找的文件，從而加快查詢速度。另外一方面，可以高效地實現(xiàn)數(shù)據(jù)保留策略。超過最長保留時間的數(shù)據(jù)，直接刪除一個時間段對應(yīng)的文件即可。而且按照時間段切分數(shù)據(jù)，還可以方便實現(xiàn)多級存儲，冷熱數(shù)據(jù)放在不同存儲介質(zhì)上，進一步降低存儲成本。

TDengine 還通過虛擬節(jié)點組技術(shù)來提供系統(tǒng)的高可用。不同物理節(jié)點上的 vnode 可以形成一個虛擬節(jié)點組，這個虛擬節(jié)點組里的數(shù)據(jù)是通過 Master-Slave 來進行同步的，來保證這個虛擬節(jié)點組內(nèi)數(shù)據(jù)的一致性。數(shù)據(jù)寫入只能在 master 進行，但查詢可以在 master 和 slave 上同時進行。如果 Master 出現(xiàn)故障，系統(tǒng)將自動選主，這樣來保證系統(tǒng)的高可用，不會由于某臺機器宕機，而無法對外提供服務(wù)。

關(guān)于集群的具體使用，請看《集群管理》。

TDengine 的設(shè)計是基于單個硬件、軟件系統(tǒng)不可靠，基于任何單臺計算機都無法提供足夠計算能力和存儲能力處理海量數(shù)據(jù)的假設(shè)進行設(shè)計的。因此 TDengine 從研發(fā)的第一天起，就按照分布式高可靠架構(gòu)進行設(shè)計，是支持水平擴展的，這樣任何單臺或多臺服務(wù)器發(fā)生硬件故障或軟件錯誤都不影響系統(tǒng)的可用性和可靠性。并且和 InfluxDB 不同的是，TDengine 選擇將集群功能開源。本文重點講解 TDengine 集群的主要邏輯單元的設(shè)計。

TDengine 分布式架構(gòu)的邏輯結(jié)構(gòu)圖如下：

一個完整的 TDengine 系統(tǒng)是運行在一到多個物理節(jié)點上的，邏輯上，它包含數(shù)據(jù)節(jié)點(dnode)、TDengine 應(yīng)用驅(qū)動(taosc)以及應(yīng)用(app)。系統(tǒng)中存在一到多個數(shù)據(jù)節(jié)點，這些數(shù)據(jù)節(jié)點組成一個集群(cluster)。應(yīng)用通過 taosc 的 API 與 TDengine 集群進行互動。下面對每個邏輯單元進行簡要介紹。

物理節(jié)點(pnode)： pnode 是一獨立運行、擁有自己的計算、存儲和網(wǎng)絡(luò)能力的計算機，可以是安裝有OS的物理機、虛擬機或 Docker 容器。物理節(jié)點由其配置的 FQDN (Fully Qualified Domain Name)來標識。TDengine 完全依賴 FQDN 來進行網(wǎng)絡(luò)通訊，如果不了解 FQDN，請看博文《一篇文章說清楚 TDengine 的 FQDN》。

數(shù)據(jù)節(jié)點(dnode)： dnode 是 TDengine 服務(wù)器側(cè)執(zhí)行代碼 taosd 在物理節(jié)點上的一個運行實例，一個工作的系統(tǒng)必須有至少一個數(shù)據(jù)節(jié)點。dnode 包含零到多個邏輯的虛擬節(jié)點(vnode)，零或者至多一個邏輯的管理節(jié)點(mnode)。dnode 在系統(tǒng)中的唯一標識由實例的 End Point (EP)決定。EP 是 dnode 所在物理節(jié)點的 FQDN (Fully Qualified Domain Name)和系統(tǒng)所配置的網(wǎng)絡(luò)端口號(Port)的組合。通過配置不同的端口，一個物理節(jié)點(一臺物理機、虛擬機或容器）可以運行多個實例，或有多個數(shù)據(jù)節(jié)點。

虛擬節(jié)點(vnode)： 為更好的支持數(shù)據(jù)分片、負載均衡，防止數(shù)據(jù)過熱或傾斜，數(shù)據(jù)節(jié)點被虛擬化成多個虛擬節(jié)點(vnode，圖中 V2, V3, V4等)。每個 vnode 都是一個相對獨立的工作單元，是時序數(shù)據(jù)存儲的基本單元，具有獨立的運行線程、內(nèi)存空間與持久化存儲的路徑。一個 vnode 包含一定數(shù)量的表（數(shù)據(jù)采集點）。當創(chuàng)建一張新表時，系統(tǒng)會檢查是否需要創(chuàng)建新的 vnode。一個數(shù)據(jù)節(jié)點上能創(chuàng)建的 vnode 的數(shù)量取決于該數(shù)據(jù)節(jié)點所在物理節(jié)點的硬件資源。一個 vnode 只屬于一個 DB，但一個 DB 可以有多個 vnode。一個 vnode 除存儲的時序數(shù)據(jù)外，也保存有所包含的表的 schema、標簽值等。一個虛擬節(jié)點由所屬的數(shù)據(jù)節(jié)點的EP，以及所屬的 VGroup ID 在系統(tǒng)內(nèi)唯一標識，由管理節(jié)點創(chuàng)建并管理。

管理節(jié)點(mnode)： 一個虛擬的邏輯單元，負責所有數(shù)據(jù)節(jié)點運行狀態(tài)的監(jiān)控和維護，以及節(jié)點之間的負載均衡(圖中 M)。同時，管理節(jié)點也負責元數(shù)據(jù)(包括用戶、數(shù)據(jù)庫、表、靜態(tài)標簽等)的存儲和管理，因此也稱為 Meta Node。TDengine 集群中可配置多個(最多不超過 3 個) mnode，它們自動構(gòu)建成為一個虛擬管理節(jié)點組(圖中 M0, M1, M2)。

mnode 間采用 master/slave 的機制進行管理，而且采取強一致方式進行數(shù)據(jù)同步, 任何數(shù)據(jù)更新操作只能在 Master 上進行。mnode 集群的創(chuàng)建由系統(tǒng)自動完成，無需人工干預(yù)。每個 dnode 上至多有一個 mnode，由所屬的數(shù)據(jù)節(jié)點的EP來唯一標識。每個 dnode 通過內(nèi)部消息交互自動獲取整個集群中所有 mnode 所在的 dnode 的EP。

虛擬節(jié)點組(VGroup)： 不同數(shù)據(jù)節(jié)點上的 vnode 可以組成一個虛擬節(jié)點組(vnode group)來保證系統(tǒng)的高可靠。虛擬節(jié)點組內(nèi)采取 master/slave 的方式進行管理。寫操作只能在 master vnode 上進行，系統(tǒng)采用異步復(fù)制的方式將數(shù)據(jù)同步到 slave vnode，這樣確保了一份數(shù)據(jù)在多個物理節(jié)點上有拷貝。一個 vgroup 里虛擬節(jié)點個數(shù)就是數(shù)據(jù)的副本數(shù)。如果一個 DB 的副本數(shù)為 N，系統(tǒng)必須有至少 N 數(shù)據(jù)節(jié)點。副本數(shù)在創(chuàng)建DB時通過參數(shù) replica 可以指定，缺省為 1。使用 TDengine 的多副本特性，可以不再需要昂貴的磁盤陣列等存儲設(shè)備，就可以獲得同樣的數(shù)據(jù)高可靠性。虛擬節(jié)點組由管理節(jié)點創(chuàng)建、管理，并且由管理節(jié)點分配一個系統(tǒng)唯一的 ID，VGroup ID。如果兩個虛擬節(jié)點的 vnode group ID 相同，說明他們屬于同一個組，數(shù)據(jù)互為備份。虛擬節(jié)點組里虛擬節(jié)點的個數(shù)是可以動態(tài)改變的，容許只有一個，也就是沒有數(shù)據(jù)復(fù)制。VGroup ID 是永遠不變的，即使一個虛擬節(jié)點組被刪除，它的ID也不會被收回重復(fù)利用。

TAOSC： taosc 是 TDengine 給應(yīng)用提供的驅(qū)動程序(driver)，負責處理應(yīng)用與集群的接口交互，提供 C/C++ 語言原生接口，內(nèi)嵌于 JDBC、C#、Python、Go、Node.js 語言連接庫里。應(yīng)用都是通過 taosc 而不是直接連接集群中的數(shù)據(jù)節(jié)點與整個集群進行交互的。這個模塊負責獲取并緩存元數(shù)據(jù)；將插入、查詢等請求轉(zhuǎn)發(fā)到正確的數(shù)據(jù)節(jié)點；在把結(jié)果返回給應(yīng)用時，還需要負責最后一級的聚合、排序、過濾等操作。對于 JDBC、C/C++、C#、Python、Go、Node.js 接口而言，這個模塊是在應(yīng)用所處的物理節(jié)點上運行。同時，為支持全分布式的 RESTful 接口，taosc 在 TDengine 集群的每個 dnode 上都有一運行實例。

以上就是 TDengine 集群的主要邏輯單元，我們將會通過更多文章，向大家解讀 TDengine 集群的更多設(shè)計秘籍。

有人在知乎上提問：“作為國產(chǎn)開源的時序數(shù)據(jù)庫，TDengine 的哪些優(yōu)點最吸引你？”。這促使我將自己對一些問題，包括創(chuàng)業(yè)本身的思考整理出來，分享給大家，希望能給眾多研發(fā)同學和創(chuàng)業(yè)者帶來一些啟發(fā)。

當我在 2016 年底開始啟動 TDengine 這個項目，瞄準時序數(shù)據(jù)庫（Time-Series Database）這個方向時，市場上已經(jīng)有很多時序數(shù)據(jù)庫，包括 InfluxDB、OpenTSDB、TimeScaleDB、KDB+、Prometheus、RRDTool 以及 Graphite 等。在傳統(tǒng)行業(yè)里，有實時數(shù)據(jù)庫，比如 PI、iHistorian 等。那如果我再做一個，到底有什么優(yōu)勢？怎么做出差異化，怎么推廣它？作為一個創(chuàng)業(yè)者，是必須認真思考的。我下面從幾個點來分析。 

1：分布式

從 2016 年底到現(xiàn)在，大部分時序數(shù)據(jù)庫都不是分布式的，換句話說，它們不支持水平擴展。即便是 InfluxDB，也只有企業(yè)版支持集群，開源版是不支持的。而傳統(tǒng)實時數(shù)據(jù)庫更是沒有一個支持水平擴展，最多是雙機熱備。但是隨著物聯(lián)網(wǎng)、車聯(lián)網(wǎng)的高速發(fā)展，IT 基礎(chǔ)設(shè)施規(guī)模的增大，數(shù)據(jù)的采集量越來越大，單機是沒有辦法解決問題的，底層數(shù)據(jù)庫必須具有水平擴展能力。 

很多企業(yè)使用的是開源時序數(shù)據(jù)庫的單機版，后續(xù)為了應(yīng)對海量數(shù)據(jù)的處理，只好自己投入人力物力，在單機版的基礎(chǔ)上，開發(fā)自己的 Proxy，對數(shù)據(jù)進行分片處理。對于數(shù)據(jù)寫入，這種方法簡單而且有效。但是對于查詢，往往牽涉多個節(jié)點，那么 Proxy 就要做各種查詢的聚合，因此開發(fā)的工作量很大。有些公司為了避免麻煩，就選用 OpenTSDB，因為它把分布式版本也開源了。 

從使用的角度來看，OpenTSDB 底層的存儲引擎用的是 HBase，安裝維護極為復(fù)雜，存儲壓縮性能不夠，查詢效率也很低，不是一個優(yōu)秀的產(chǎn)品。但它仍然有相當多的用戶，這唯一的原因就是由于它支持分布式，可以水平線性擴展。

因此，在 2016 年底，整個 TDengine Database 的設(shè)計從第一天起，就是支持分布式的。為了便于更多使用開源版本的用戶用得更好，在 2020 年 8 月，我們將 TDengine 的分布式版本開源了。分布式版本開源后，TDengine 的用戶量持續(xù)增長，全球安裝實例數(shù)已經(jīng)超過 10 萬，每天新增實例都在 200 以上，這是一個相當可觀的數(shù)字。這證明了我們將 TDengine 分布式版本開源是非常明智的決定。 

2：高性能

時序數(shù)據(jù)及時序數(shù)據(jù)的應(yīng)用有其典型特點（詳細請看官網(wǎng)博客 )，如果充分利用時序數(shù)據(jù)的特點，我們可以將數(shù)據(jù)寫入和查詢性能大幅提高，數(shù)據(jù)壓縮率也能大幅提高。 我之所以在 2016 年決定開發(fā) TDengine，其中一個核心原因是我認為 InflxuDB 并沒有充分利用時序數(shù)據(jù)特點。如果我充分利用，就能在性能上碾壓它。

在仔細研究之后，我提出了“一個數(shù)據(jù)采集點一張表”的設(shè)計，讓一個采集點來的數(shù)據(jù)按照時間順序一塊一塊的存，并且使用列式存儲。這樣就會使得寫入變成簡單的追加操作，而且一次讀的 IO 操作就能把一個數(shù)據(jù)采集點的數(shù)據(jù)點成片讀出。而時序數(shù)據(jù)的查詢分析往往是一個時間段，數(shù)據(jù)命中率一下提高很多，這樣就會使查詢效率極其之高，而且壓縮率也會極其之高。同時我提出“超級表”概念，來解決多個數(shù)據(jù)點數(shù)據(jù)高效聚合的問題。通過標簽將需要聚合的數(shù)據(jù)采集點先過濾出來，大幅減小需要掃描的數(shù)據(jù)集，從而大幅提升聚合速度。 

那么性能重要嗎？毫無疑問非常重要，因為如果用戶不關(guān)心性能，那選擇通用數(shù)據(jù)庫來處理時序數(shù)據(jù)就可以了。如果都是時序數(shù)據(jù)庫，用戶當然也會選擇性能或效率更高的產(chǎn)品。因此從研發(fā)的第一天起，我和整個團隊一直在追求極致的性能。 

3：SQL 支持

任何一款新產(chǎn)品，都有入門門檻。降低門檻最好的方法就是不改變用戶習慣。SQL 是全球最流行的查詢語言，學過計算機的人都會用 SQL 寫查詢語句。

時序數(shù)據(jù)庫并不新鮮，已經(jīng)有相當長的歷史，但相當多的時序數(shù)據(jù)庫或?qū)崟r數(shù)據(jù)庫都有自己的查詢語言，比如 InfluxDB、OpenTSDB、Prometheus 等都有自己的查詢語言，這樣大大增加了學習成本，而且也增加了應(yīng)用的遷移成本。 

采用 SQL 還有一個好處，就是能與眾多的 BI、可視化工具對接，生態(tài)豐富很多。如果采用自己研發(fā)的查詢語言，所有工具都要定制化開發(fā)，難度一下大了很多。kdb 就是最典型的例子，完全是自有語法，因此雖然很多性能指標相當不錯，但十幾年過去，還是不溫不火。 

從 TDengine 研發(fā)的第一天起，我就決定采用標準 SQL 做查詢語言，并且采用關(guān)系數(shù)據(jù)庫模型，而不是 InfluxDB、OpenTSDB 和 Prometheus 等數(shù)據(jù)庫的 tag-set 模型。其根本原因就是想降低學習成本。目前看來，這個策略是極其正確的。 

濤思數(shù)據(jù)團隊還將在查詢分析上投入相當大的研發(fā)力量，希望 TDengine 具有強大的時序數(shù)據(jù)分析功能。 

4：開源

基礎(chǔ)軟件在開源大勢所趨的情況下，如果不將代碼，特別是核心代碼開源，想要贏得市場是完全不可能的。因此，我們才將 TDengine 完全開源。開源使?jié)紨?shù)據(jù)獲得了高速增長，這是一個完全正確的決定。 

但從產(chǎn)品角度來看，開源是 TDengine 的一大優(yōu)勢嗎？看起來是，但細想一下，其實不是，它只是取得成功的一個必要條件。因為全球市場上開源的的時序數(shù)據(jù)庫產(chǎn)品很多，中國本土開源的時序數(shù)據(jù)庫也不止 TDengine 一家，大家不會由于 TDengine 是開源的就選擇它，而是有其他特點才會選用它。 

如果市場上還沒有開源的時序數(shù)據(jù)庫，那么開源就是 TDengine 最大的亮點。我決定將集群開源，根本的原因是由于 InfluxDB 沒有把集群開源，這給了我們高速增長的機會。只有別人做不到或比不上你的功能或性能，那才是你需要宣傳的特點。功能或性能指標的跟隨者永遠不值得做任何推廣。 

5：其他

TDengine 還有很多其他優(yōu)點，比如 All in One 的特性，TDengine 自身帶有緩存、流計算、數(shù)據(jù)訂閱等功能，因此在很多場景下，用戶不再需要集成 Kafak, Redis, Spark, Zookeeper 等軟件，TDengine 就可以作為一個大數(shù)據(jù)平臺來使用，能大幅降低整個系統(tǒng)的復(fù)雜度和運維成本。與大部分研發(fā)同學一樣，我也喜歡羅列各種開發(fā)的功能和亮點，我還可以羅列 TDengine 的很多很多其他優(yōu)點。 

但是作為一個連續(xù)創(chuàng)業(yè)者，很清楚無論是產(chǎn)品還是市場宣傳，必須做減法。研發(fā)出身的創(chuàng)業(yè)者最喜歡的就是不斷加功能，在宣傳上胡子眉毛一把抓，不突出重點，這是創(chuàng)業(yè)者的大忌。用戶能看上你的產(chǎn)品，往往不是你功能全，而是產(chǎn)品的某一個亮點打動了他，特別是早期的用戶，完全是喜歡產(chǎn)品的某項功能才容忍了諸多其他方面的不足。宣傳上也是，眾多的特點無法讓人記住，能記住一個就相當不錯。我們要做的是，把真正的亮點做到極致，而且做最大程度的傳播，讓人人都知道它，喜歡它。 

做減法對于研發(fā)同學是極其困難的，因為不將自己花精力沒日沒夜開發(fā)的功能宣傳出去，太讓自己沒有成就感。但作為創(chuàng)業(yè)者，就是與要習慣思維做斗爭。只有聚焦，你才會真正思考產(chǎn)品在市場的獨特定位，把某個亮點做到極致。只有獨特，才能真正吸引用戶，才能真的受人喜歡。 

因此過去的幾年，我們一直強調(diào) TDengine 是一個物聯(lián)網(wǎng)大數(shù)據(jù)平臺，聚焦在物聯(lián)網(wǎng)細分市場，強調(diào)的是 All in One 的特性，這樣就能與其他時序數(shù)據(jù)庫做出差異化來。 

但 TDengine 開源 2 年多時間，大部分用戶還是把我們當做時序數(shù)據(jù)庫來使用，而且不僅是物聯(lián)網(wǎng)行業(yè)用戶在用，金融、IT 運維、能源、汽車、工業(yè)互聯(lián)網(wǎng)等行業(yè)的用戶也在用。經(jīng)過很多思考之后，我決定將 TDengine 重新定位為時序數(shù)據(jù)庫。

6：三大優(yōu)點

那么作為時序數(shù)據(jù)庫，怎么與眾多的時序數(shù)據(jù)庫 PK 或差異化，我個人認為就是：高性能、分布式與 SQL 支持。這三個特點足以讓我說服 InfluxDB, OpenTSDB, TimeScale 的客戶切換到 TDengine 上來。因此在我們最近的網(wǎng)站改版時，大膽地將 TDengine Database 的 Slogan 定為：高性能、分布式、支持 SQL 的時序數(shù)據(jù)庫。 

貪多嚼不爛，用戶沒法記住你那么多特點優(yōu)點，因此我們列出高性能、分布式、支持 SQL 這三個優(yōu)點足夠，其他優(yōu)點由用戶自己去總結(jié)和體會，讓他們有驚喜。只要將三個優(yōu)點做實做得足夠好，TDengine 與其他時序數(shù)據(jù)庫就會有足夠的差異化，就一定能贏得開發(fā)者的信賴，贏得市場。

陶建輝

2022 年 2 月 26 日

最近，在TDengine Database的一個社區(qū)群中突發(fā)了一場嚴重的灌水事件。幾位群友不眠不休地聊天，可以說是廢寢忘食。那么到底是什么話題能讓他們凌晨四點還在忘我地討論？

這個話題就是——如何完善Docker環(huán)境下TDengine Database的集群搭建?！笆裁?？除了你們官方自己人之外，怎么會有用戶加班加點地討論如何完善Docker環(huán)境的集群搭建，這也太假了。”

好吧，我們承認：其實是有一個叫Oliver（群昵稱）的用戶遇到了這樣的問題——辛辛苦苦搭起來Docker環(huán)境下的TDengine集群在客戶端連不上了。接下來，就引發(fā)了群里的二位熱心大佬的討論不休，直到想出最后的解決方案。

事情的經(jīng)過是這樣的：

該用戶的數(shù)據(jù)庫集群裝在這臺Linux服務(wù)器上（ip:10.0.31.2），容器ip所在的網(wǎng)絡(luò)是由Docker在宿主機創(chuàng)建的虛擬網(wǎng)絡(luò)172.19.0.0/16。三個容器的hostname和節(jié)點ip分別：taosnode1（172.19.0.41）、taosnode2（172.19.0.42）、taosnode3（172.19.0.43）。

各個節(jié)點配置如下：

taosnode1: firstEp=taosnode1:6030,secondEp=taosnode2:6030,fqdn=taosnode1;端口映射：16030-16042:6030-6042（tcp/udp）
taosnode2: firstEp=taosnode1:6030,secondEp=taosnode2:6030,fqdn=taosnode2;端口映射：26030-26042:6030-6042（tcp/udp）
taosnode3: firstEp=taosnode1:6030,secondEp=taosnode2:6030,fqdn=taosnode3;端口映射：36030-36042:6030-6042（tcp/udp）

按照官方文檔的指示努力折騰一番后，Oliver終于搭起了這個集群。添加完節(jié)點之后，他忐忑地敲下了“show dnodes”，隨著三個READY映入眼簾后———舒坦了。

服務(wù)端沒有問題，接下來該客戶端了。他打開了自己的一臺ip為10.0.31.5（與集群宿主機同一網(wǎng)段）的Windows主機，迅速地在上面安裝了個TDengine客戶端，添加hosts信息，做好路由，2.8MB，傻瓜式安裝，輕松便捷，連接集群一氣呵成?！皊how dnodes”隨著三個READY再次映入眼簾后———又舒坦了。

Oliver十分滿意，然而，他馬上發(fā)現(xiàn)事情可能并不像想象中的那么簡單。

由于業(yè)務(wù)需要，他還需要完成客戶端（10.0.2.61）跨網(wǎng)段連接服務(wù)端集群（基于ip:10.0.31.2的Docker環(huán)境下的集群）。ping得通宿主機，telnet得通集群映射出來的端口，使用taos連接集群，一樣的操作也和此前一樣順利。于是他再次敲下“show dnodes”——萬萬沒想到，這時令所有TDengine用戶都深惡痛絕的“DB error：Unable to establish connection”出現(xiàn)了。于是，他便在群中拋出了自己的問題。

上文說到的兩位熱心的同學就是在這個時候出現(xiàn)的。一位是TDengine的外部Contributor——Freemine。另一位是路見問題拔刀相助的熱心大佬pigwing。

由于集群本身沒有任何使用問題，唯一的區(qū)別就是客戶端連接服務(wù)器的方式變成了跨網(wǎng)段。所以，一開始大家的思路就是——既然走宿主機的端口不行，那就試試直接連到Docker環(huán)境下的ip吧。遺憾的是，跨網(wǎng)段連接Docker環(huán)境下內(nèi)部ip的想法沒能實現(xiàn)。

接著大家推測：TDengine靠的是EndPoint（EP）來識別數(shù)據(jù)節(jié)點，而EP=FQDN+端口?？煽蛻舳诉B接已經(jīng)成功，只是無法對數(shù)據(jù)操作，在FQDN無誤的情況下，大家猜測是集群內(nèi)的端口出現(xiàn)了問題，從而沒拿到集群的拓撲信息。接下來，從最初的了解環(huán)境，到一步一步的排查問題，三個鍥而不舍的工程師在群里從4月22日討論到4月25，最晚的時候凌晨4點多都有人在線。

終于，在三人的通力合作多次試錯下，4月24日凌晨1點——freemine提出了一個行之有效的最終解決方案（文字過多只截圖關(guān)鍵部分）

大功告成，經(jīng)過測試后，一切順利！

那么，freemine的集群搭建方案和最初的集群搭建有什么區(qū)別呢？

雖然過程曲折，但是最后我們仔細對比一下兩者的方案就會發(fā)現(xiàn)，它們的區(qū)別就只有在端口配置這一塊不一樣。freemine的方案是在每一個單機的serverport都修改了不一樣的值。taosnode1節(jié)點的serverport為6030—映射主機的6030端口；taosnode2節(jié)點的serverport為7030–映射主機的7030端口；taosnode3節(jié)點的serverport為8030–映射主機的8030端口。

而提問者Oliver最初的各個節(jié)點的serverport都是沒做修改的默認6030，映射到宿主機的時候是16030，26030，36030。就是這樣的配置在客戶端與集群宿主機的同網(wǎng)段連接時并沒有發(fā)生問題，而是在跨網(wǎng)段連接時出現(xiàn)問題。

看起來一絲小小的改動居然有這么大的區(qū)別？Why？

其實是這樣，當客戶端與服務(wù)端同屬一個網(wǎng)段的時候，在添加路由后，客戶端是可以直接訪問到Docker內(nèi)部的。這樣一來，IP地址就可以根據(jù)需要被正確地解析出來。如：taosnode1（172.19.0.41）、taosnode2（172.19.0.42）、taosnode3（172.19.0.43）。在不同的IP地址下，即便端口都是一樣的6030，TDengine還是可以完成不同節(jié)點的區(qū)分。

但是，當跨網(wǎng)段之后就不一樣了。對于不同網(wǎng)段的客戶端和服務(wù)端而言，客戶端要通過真實路由去連接服務(wù)端，但真實路由中并沒有注冊我們設(shè)置的Docker內(nèi)部網(wǎng)絡(luò)，所以客戶端自然就訪問不了Docker內(nèi)部的網(wǎng)絡(luò)。因此，當taosc需要得到集群提供的不同節(jié)點的信息時，F(xiàn)QDN已經(jīng)無法正確解析IP地址了。這時候，就需要通過端口來實現(xiàn)不同節(jié)點的區(qū)分。

這就是不能再在Docker環(huán)境下的節(jié)點中同時使用6030端口的原因。

因此，當你使用了Docker主機內(nèi)外一致的端口映射，且每個節(jié)點的serverPort參數(shù)不相同的設(shè)置時，集群就可以通過不同的端口來區(qū)分不同的節(jié)點。這樣一來，客戶端才可以拿到拓撲信息進行集群的順利操作。

這就是整個“案件”的最終答案。

總結(jié)一下，對于用戶使用而言，Docker環(huán)境下搭建TDengine Database集群的水還是頗深。由于環(huán)境的相對復(fù)雜，所以我們也并不是十分推薦大家使用這種方式搭建集群。所以，關(guān)于TDengine在Docker環(huán)境的使用，大家還是要小心謹慎。

最后我們想說的是，作為一個開源的產(chǎn)品，社區(qū)的活躍與專業(yè)是我們濤思數(shù)據(jù)最為關(guān)注的地方。雖然目前官網(wǎng)上并沒有關(guān)于Docker環(huán)境下TDengine集群搭建的文檔。但是這些社區(qū)用戶們的活躍思考顯然很大程度填補了這樣的一個空白。

真心感謝Oliver，freemine，pigwing三位朋友。十分希望日后可以繼續(xù)看到你們在物聯(lián)網(wǎng)大數(shù)據(jù)技術(shù)前沿群中的活躍身影，同時我們也希望有更多的朋友們能夠參與進來。

掃描二維碼，添加小T為好友，即可與各位熱衷開源的朋友一起在群內(nèi)互動哦～

點擊“這里”，查看Oliver整理的TDengine在Docker環(huán)境下的集群搭建筆記