在很多物聯網系統中，都需要對聯網的裝置進行監控，並對監控取樣到的資料進行持久化。對取樣資料進行持久化，其實很多年前在工業領域已經有專門的資料庫來完成這個任務了。在工業領域，這個叫實時資料庫。
工業領域的實時資料庫具有資料採集、實時資料快取、資料回寫（向裝置傳送指令）、取樣資料歸檔存檔等主要功能。目前工業領域實時資料庫基本上被國外廠家所壟斷，**昂貴。以pi資料庫為例，基礎版本（只有5000個測點）就需要大約10萬美元，每個資料採集介面需要6000美元。這個**對新興的物聯網公司來說代價太大了。
幸好，最近幾年it公司針對it裝置運維提出了一種新型的資料庫:tsdb，時序資料庫。該資料庫專門用來儲存時序資料，物聯網系統從裝置上採集的資料就是一種時序資料，物聯網系統完全可以用tsdb來儲存裝置取樣資料。
但假如你的物聯網應用是執行在封閉式的區域網或者專網中的，又該如何選擇呢？
假如你想對各種tsdb做乙個測試，並根據測試結果來選擇，我的建議如下：
1、測試其寫入速度，並關注寫入速度的波動性。所有的tsdb在實現的時候肯定都用來記憶體來快取寫入速度的，它們需要在特定時機把快取的資料寫入到磁碟進行歸檔。所以，在考察寫入速度的時候，一定要關注它在對記憶體資料進行歸檔化處理時候的寫入速度。
2、在寫入的同時測試其查詢速度。因為物聯網系統中裝置時刻都在產生資料，你的每個查詢都是和大量的寫入操作同時執行的。
3、測試其資料完整性，前面我們提到tsdb在執行寫操作時都是先寫記憶體的，然後在特定時候歸檔到磁碟。 這樣一來就存在"tsdb資料庫正常關閉或者異常關閉時候 丟失資料"的可能性。作為tsdb的使用者，當然希望它關閉重啟的時候盡可能少丟失已經寫入的資料。
4、測試其在時序錯位情況下的資料完整性，時序錯位有兩種情況：取樣資料的時間和tsdb伺服器當前時間有較大偏差；兩個不同測點之間，幾乎同時寫入的資料，但被標記為不同的取樣時間（有較大的時差）；在這兩種情況下，重啟伺服器後，測試其資料丟失情況。
5、測試其磁碟佔用率，假如你的系統中連線了1000的裝置，每個裝置有10個測點，每個測點沒秒鐘持久化一次，那麼你每天需要持久化的時序資料有864兆，每份資料最少包含一下內容：乙個測點id、乙個時間戳、乙個值。測點算它4個位元組、時間戳8個位元組、值4個位元組。在不壓縮的情況下至少需要13g磁碟空間。所以壓縮效能是tsdb的一項關鍵指標。
6、了解其查詢介面是否豐富，既然把這麼多歷史資料都儲存下來，那當然是希望這些資料能發揮出其價值。乙個強大的查詢介面是這些資料發揮價值的前提條件。除了普通的按照時間和標籤查詢某些測點在某個時間段的所有值之外，我覺得tsdb還應該包括：降頻查詢（在時間軸上分組聚合），聚合查詢（把一些測點按照某個演算法計算相同取樣時間點的值，可以在查詢時聚合或者寫入時聚合）。
物聯網系統開發如何選擇時序資料庫
在很多物聯網系統中，都需要對聯網的裝置進行監控，並對監控取樣到的資料進行持久化。對取樣資料進行持久化，其實很多年前在工業領域已經有專門的資料庫來完成這個任務了。在工業領域，這個叫實時資料庫。工業領域的實時資料庫具有資料採集 實時資料快取 資料回寫 向裝置傳送指令 取樣資料歸檔存檔等主要功能。目前工業...
時序資料庫
看到這類資料處理基本是要對乙個時間範圍的資料，根據時間段，維度進行歸類，做一些聚合運算。時序資料庫要解決的問題就是如何能在海量資料中，快速響應使用者的此類查詢。序資料庫的一些基本概念 不同的時序資料庫稱呼略有不同 metric 度量，相當於關係型資料庫中的table。data point 資料點，相...
MongoDB資料建模小案例 物聯網時序資料庫建模
注 本案例來自mongodb官方教程ppt，也是乙個非常典型的case，故此翻譯，並結合當前mongodb版本做了一些內容上的更新。本案例非常適合與iot場景的資料採集，結合mongodb的sharding能力，文件資料結構等優點，可以非常好的解決物聯網使用場景。案例背景是來自真實的業務，美國州際公...