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

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

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

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

taosdemo的具體使用方式可以通過使用“taosdemo –help”來了解，這個工具可以通過設置表數量、表行數、數據類型、單批插入行數，甚至模擬亂序寫入等高級功能來模擬出你在工作使用中遇到的類似場景。跑起來后，taosdemo會自動生成數據完成寫入，并在最后給出性能數據。

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

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

注：當前最新的版本（2.1.0）里taosdemo的默認maxSQLLength已經為1MB，無需自己調整。

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

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

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

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

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

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

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

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

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

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

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

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

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