大家都聽過這樣的一句話：在物聯(lián)網(wǎng)大數(shù)據(jù)的場景之下，TDengine最大的優(yōu)勢之一，就是寫入速度——這是由于TDengine獨特設(shè)計的成果。但是，一些用戶在初次使用TDengine的時候會覺得寫入性能并沒有達到自己的預(yù)期。這些用戶中，有的是直接使用TDengine的服務(wù)端，有的是使用了TDengine的客戶端，還有的用戶使用各種不同的連接器，可以說是形形色色不一而同。

那么——究竟要如何解決這些種類繁多的寫入“慢”呢？我們提倡的思路就是——在確保服務(wù)端本身的參數(shù)和配置已經(jīng)調(diào)整到最優(yōu)的情況下，逐層向外排查硬件軟件網(wǎng)絡(luò)等因素。

對于通過連接器使用TDengine的用戶來說，由于涉及了更多的模塊介入以及網(wǎng)絡(luò)問題，遇到性能問題要稍微麻煩一些。但即便如此，也要對數(shù)據(jù)庫本身的做好性能相關(guān)的配置。而在此之前，用“我的xxxx連接器寫數(shù)據(jù)特別慢”是不精準(zhǔn)且不利于排查問題的。

所以不論你的場景多么復(fù)雜，我們都要首先去服務(wù)端檢測TDengine的性能。而最省時高效的方法就是使用官方的工具taosdemo觀察寫入速度是否大致相同。這樣做的好處是，可以在第一時間定位問題是否出現(xiàn)在數(shù)據(jù)庫服務(wù)端本身。然后，我們就可以針對性地排查其余因素。比如服務(wù)端與客戶端的網(wǎng)絡(luò)通信，客戶端內(nèi)部是否異常。

taosdemo的具體使用方式可以通過使用“taosdemo –help”來了解，這個工具可以通過設(shè)置表數(shù)量、表行數(shù)、數(shù)據(jù)類型、單批插入行數(shù)，甚至模擬亂序?qū)懭氲雀呒壒δ軄砟M出你在工作使用中遇到的類似場景。跑起來后，taosdemo會自動生成數(shù)據(jù)完成寫入，并在最后給出性能數(shù)據(jù)。

如果在使用taosdemo依然性能很慢的話，我們就可以做如下優(yōu)化了：

1. 要提高寫入效率，不能一次insert只寫入一條記錄，那樣將是對資源的浪費。建議一條SQL語句寫入多條記錄，一次寫入的記錄條數(shù)越多，插入效率就越高。典型的情況是，一條SQL寫入多個表各一條記錄，如：insert into tb1 values(….) tb2 values(….) tb3 values(…)。但一條記錄不能超過16K，一條SQL語句總長度不能超過64K（可通過參數(shù)maxSQLLength配置，最大可配置為1M，具體內(nèi)容官方文檔可查）。在使用taosdemo模擬的時候，可以通過-r參數(shù)來指定單次insert的寫入行數(shù)，但是要注意計算SQL長度不要超過maxSQLLength。

注：當(dāng)前最新的版本（2.1.0）里taosdemo的默認(rèn)maxSQLLength已經(jīng)為1MB，無需自己調(diào)整。

2.TDengine支持多線程同時寫入，要進一步提高寫入速度，一個12核CPU的客戶端可以打開20個以上的線程同時寫。但線程數(shù)達到一定數(shù)量后，速度就無法再提高，甚至還會下降，因為線程切頻繁切換，帶來額外開銷。在使用taosdemo模擬的時候，線程數(shù)可以通過-T來指定，一般為cpu核數(shù)或二倍核數(shù)為最佳。

3. 在大量數(shù)據(jù)涌入內(nèi)存等待落盤的時候，vnode虛擬數(shù)據(jù)節(jié)點的內(nèi)存大小設(shè)置就顯得尤為重要。cache和blocks這兩個參數(shù)分別代表著內(nèi)存塊的大小和塊數(shù)，他們的乘積便是vnode的預(yù)留內(nèi)存。對于很多場景，默認(rèn)的blocks數(shù)量是不夠的。當(dāng)寫入緩存不夠時，數(shù)據(jù)不能一次落盤，將會被寫入.last臨時文件，客觀上增加磁盤的IO操作。這就需要根據(jù)你的場景酌情增加這個參數(shù)的值（3的倍數(shù)），在觀察寫入速度是否提升的同時，觀察內(nèi)存是否為性能瓶頸且保持在一個安全的使用范圍內(nèi)，直到找到最優(yōu)解。

點擊這里，查看taosdemo的使用手冊。

在這個過程中，大家要不停地控制變量，觀察自己的性能瓶頸出現(xiàn)在哪個環(huán)節(jié)。是預(yù)分配的內(nèi)存不足，還是操作系統(tǒng)內(nèi)存不足，抑或是CPU吃光，還是硬盤讀寫極限，然后做一個針對性的調(diào)整。

這樣調(diào)整過后，對于一個直接使用TDengine服務(wù)端的用戶來講，基本就算是足夠了。值得一提的是，大家不用過于專注于TDengine每秒寫了多少行。因為每行有多少列（測點）和每一列（測點）的數(shù)據(jù)類型都是不固定的。

而對于使用連接器或客戶端的用戶來說，如果以上操作還沒有解決您的寫入性能問題，接下來我們再來排查網(wǎng)絡(luò)、客戶端、應(yīng)用層面的因素。

由于服務(wù)端依靠網(wǎng)絡(luò)和應(yīng)用或客戶端連接，所以網(wǎng)絡(luò)問題是性能問題上不可忽視的環(huán)節(jié)。這里可以給出一個很典型的代表案例：

某用戶在使用C接口插入數(shù)據(jù)的時候曾遇到這樣這樣的情況： 插入速度時快時慢，整體上比預(yù)期速度慢了不少。

于是，我們一起配置好了內(nèi)存，線程數(shù)和單條SQL寫入行數(shù)?？墒窃谀侵?，問題卻依然存在。所以我們又一起看了日志發(fā)現(xiàn)了一些關(guān)于網(wǎng)絡(luò)通信的告警提示，再結(jié)合服務(wù)器的監(jiān)控數(shù)據(jù)，我們初步診斷寫入很慢的原因是網(wǎng)絡(luò)方面的路由阻塞。之后，該用戶便重新搭建了網(wǎng)絡(luò)拓撲只使用本地虛擬機組成局域網(wǎng)，問題便消失了。

另外，由于TDengine的客戶端功能很多（負責(zé)獲取并緩存元數(shù)據(jù)；將插入、查詢等請求轉(zhuǎn)發(fā)到正確的數(shù)據(jù)節(jié)點；在把結(jié)果返回給應(yīng)用時，還需要負責(zé)最后一級的聚合、排序、過濾等操作）所以很多時候，TDengine的性能問題并不是出在服務(wù)端而是客戶端。當(dāng)你發(fā)現(xiàn)你的性能遲遲上不去的時候，去看一下客戶端服務(wù)器的后臺，興許會有驚人的發(fā)現(xiàn)。萬萬沒想到——客戶端也會成為寫入性能的瓶頸。這個時候，就需要你酌情增加客戶端服務(wù)器性能或者數(shù)量了。

最后，連接器由于在邏輯上是很薄的一層，所以它的性能通常是受相關(guān)語言自身特性影響，排除遇到bug的情況下，一般是可以認(rèn)為是沒有優(yōu)化空間的，比如：Java就是會比C慢一些。

OK，大概就是這樣了，讀到這里的用戶應(yīng)該對于TDengine的寫入性能優(yōu)化已經(jīng)有了一個初步的輪廓。這樣一來，日后即便是需要官方的技術(shù)支持也能做到精準(zhǔn)提問，這樣對雙方都將會是一種非常愉快的體驗。對于很多社區(qū)版TDengine的新用戶來說，由于工作時間緊迫或者是其他原因，會導(dǎo)致大家沒有耐心去一步一步地閱讀文檔了解產(chǎn)品。

在這個時候，這篇文章就能夠發(fā)揮它該有的作用。