時序資料庫系列
時序資料庫-01-時序資料庫有哪些？為什麼要使用
時序資料庫-02-聊一聊時序資料庫
時序資料庫-03-pentsdb-分散式時序資料庫
時序資料庫-04-InfluxData-分散式時序資料庫
時序資料庫-05-TDengine 是一款開源、高效能、雲原生的時序資料庫 (Time-Series Database, TSDB)
時序資料庫-05-TDengine Time-Series Database, TSDB
時序資料庫-05-TDengine windows11 WSL 安裝實戰筆記 docker
時序資料庫-06-01-vm VictoriaMetrics 快速、經濟高效的監控解決方案和時間序列資料庫
時序資料庫-06-02-vm VictoriaMetrics install on docker 安裝 vm
時序資料庫-06-03-vm VictoriaMetrics java 整合
時序資料庫-06-04-vm VictoriaMetrics storage 儲存原理簡介
時序資料庫-06-05-vm VictoriaMetrics cluster 叢集原理
時序資料庫-06-06-vm VictoriaMetrics cluster 叢集訪問方式
3.基本特點
時序業務和普通業務在很多方面都有巨大的區別，歸納起來主要有如下幾個方面：
3.1 持續產生海量資料，沒有波峰波谷
舉幾個簡單的例子，比如類似哨兵的監控系統，假如現在系統監控1w臺伺服器的各類指標，每臺伺服器每秒採集100種metrics，這樣每秒鐘將會有100w的TPS。再比如說，現在比較流行的運動手環，假如當前有100w人佩戴，每個手環一秒只採集3種metrcis(心跳、脈搏、步數)，這樣每秒鐘也會產生300w的TPS。
3.2 資料都是插入操作，基本沒有更新刪除操作
時序業務產生的資料很少有更新刪除的操作，基於這樣的事實，在時序資料庫架構設計上會有很大的簡化。
3.3 近期資料關注度更高，未來會更關注流式處理這個環節，時間久遠的資料極少被訪問，甚至可以丟棄
這個很容易理解，哨兵系統我們通常最關心最近一小時的資料，最多看看最近3天的資料，很少去看3天以前的資料。隨著流式計算的到來，時序資料在以後的發展中必然會更關注即時資料的價值，這部分資料的價值毫無疑問也是最大的。資料產生之後就可以根據某些規則進行報警是一個非常常見並重要的場景，報警時效性越高，對業務越有利。
3.4 資料存在多個維度的標籤，往往需要多維度聯合查詢以及統計查詢。
時序資料另一個非常重要的功能是多維度聚合統計查詢，比如業務需要統計最近一小時廣告主google釋出在USA地區的廣告點選率和總收入分別是多少，這是一個典型的多維度聚合統計查詢需求。這個需求通常對實效性要求不高，但對查詢聚合效能有比較高的要求。
4.TSDB核心特性
總結起來TSDB需要關注的技術點主要有這麼幾個：
4.1 高吞吐量寫入能力
這是針對時序業務持續產生海量資料這麼一個特點量身定做的，當前要實現系統高吞吐量寫入，必須要滿足兩個基本技術點要求：系統具有水平擴充套件性和單機LSM體系結構。系統具有水平擴充套件性很容易理解，單機肯定是扛不住的，系統必須是叢集式的，而且要容易加節點擴充套件，說到底，就是擴容的時候對業務無感知，目前Hadoop生態系統基本上都可以做到這一點；而LSM體系結構是用來保證單臺機器的高吞吐量寫入，LSM結構下資料寫入只需要寫入記憶體以及追加寫入日誌，這樣就不再需要隨機將資料寫入磁碟，HBase、Kudu以及Druid等對寫入效能有要求的系統目前都採用的這種結構。
4.2 資料分級儲存/TTL
這是針對時序資料冷熱性質定製的技術特性。資料分級儲存要求能夠將最近小時級別的資料放到記憶體中，將最近天級別的資料放到SSD，更久遠的資料放到更加廉價的HDD或者直接使用TTL過期淘汰掉。
4.3 高壓縮率
提供高壓縮率有兩個方面的考慮，一方面是節省成本，這很容易理解，將1T資料壓縮到100G就可以減少900G的硬碟開銷，這對業務來說是有很大的誘惑的。另一個方面是壓縮後的資料可以更容易保證儲存到記憶體中，比如最近3小時的資料是1T，我現在只有100G的記憶體，如果不壓縮，就會有900G的資料被迫放到硬碟上，這樣的話查詢開銷會非常之大，而使用壓縮會將這1T資料都放入記憶體，查詢效能會非常之好。
4.4 多維度查詢能力
時序資料通常會有多個維度的標籤來刻畫一條資料，就是上文中提到的維度列。如何根據隨機幾個維度進行高效查詢就是必須要解決的一個問題，這個問題通常需要考慮點陣圖索引或者倒排索引技術。
4.5 高效聚合能力
時序業務一個通用的需求是聚合統計報表查詢，比如哨兵系統中需要檢視最近一天某個介面出現異常的總次數，或者某個介面執行的最大耗時時間。這樣的聚合實際上就是簡單的count以及max，問題是如何能高效的在那麼大的資料量的基礎上將滿足條件的原始資料查詢出來並聚合，要知道統計的原始值可能因為時間比較久遠而不在記憶體中哈，因此這可能是一個非常耗時的操作。目前業界比較成熟的方案是使用預聚合，就是在資料寫進來的時候就完成基本的聚合操作。
未來技術點：異常實時檢測、未來預測等等。
5.傳統關係型資料庫儲存時序資料的問題
很多人可能認為在傳統關係型資料庫上加上時間戳一列就能作為時序資料庫。資料量少的時候確實也沒問題。但時序資料往往是由百萬級甚至千萬級終端裝置產生的，寫入併發量比較高，屬於海量資料場景。
5.1 MySQL在海量的時序資料場景下存在如下問題：
儲存成本大：對於時序資料壓縮不佳，需佔用大量機器資源；
維護成本高：單機系統，需要在上層人工的分庫分表，維護成本高；
寫入吞吐低：單機寫入吞吐低，很難滿足時序資料千萬級的寫入壓力；
查詢效能差：適用於交易處理，海量資料的聚合分析效能差。
5.2 使用Hadoop生態(Hadoop、Spark等)儲存時序資料會有以下問題：
資料延遲高：離線批處理系統，資料從產生到可分析，耗時數小時、甚至天級；
查詢效能差：不能很好的利用索引，依賴MapReduce任務，查詢耗時一般在分鐘級。
5.3 時序資料庫需要解決以下幾個問題：
時序資料的寫入：如何支援每秒鐘上千萬上億資料點的寫入。
時序資料的讀取：如何支援在秒級對上億資料的分組聚合運算。
成本敏感：由海量資料儲存帶來的是成本問題。如何更低成本的儲存這些資料，將成為時序資料庫需要解決的重中之重。