慶祝新的一年時，通常習慣照鏡子。 專門的DB-Engines網站在今年早些時候進行了培訓，並選舉PostgreSQL為2017年RDBMS。當之無愧的Postgre！
DB-Engines會嘗試對每個數據庫（無論其用例或模型）進行排名，因此關係數據庫在排名中居於首位也就不足為奇了。 有許多數據庫可以解決不同的用例：
· 關係數據庫（PostgreSQL，MariaDB）
· 文檔存儲（MongoDB，CouchDB）
· 鍵/值存儲（Redis，RocksDB）
· 列存儲（HBase，Cassandra）
· 搜索引擎（Solr，Elasticsearch）
· 圖DBMS（Neo4J，JanusGraph）
· 時間序列DBMS（Prometheus，Influxdb）
· 和別的…
在上一篇DB-Engines帖子中，還有趣的是，時間序列DBMS連續第二年獲得了最強勁的增長，排名第二。
時間序列數據庫的分數提高了約70％
在所有類型的數據庫中，時間序列是增長最快的類別。 自2015年中以來，這一類別已被確定為一種趨勢，並且自2016年初以來就開始炫耀。
時間序列雖然是最流行的趨勢，但對時間序列的興趣還很年輕，但採用率卻沒有與關係數據庫或其他數據庫相同，但這只是每個開發人員堆棧都包含指標解決方案的時間。 無論如何，"時間序列數據庫"領域目前正在蓬勃發展，其中包括新的解決方案，項目，貢獻和工具。 在OVH，我們通過參與Noderig，Beamium，Warp10，Grafana插件等項目來參與這項工作。
但是，為什麼要關心時間序列？
衡量就是做出更好的決定
時間序列用於跟蹤隨時間的變化。 它還提供了一種通過測量事物來表達感覺的事實方法。
"如果有數據，我們來看一下數據。 如果我們只有意見，那就和我一起去吧。"
Netscape前首席執行官Jim Barksdale
我認為這句話清楚地表達了採用時間序列的思想：衡量。
要合成Coda Hale演示文稿，請進行以下測量：
· 無需在開發人員代碼中添加任何內容
· 幫助您瞭解代碼在生產中的運行方式，以及您的業務
· 改善您關於業務的思維模式
· 優化您的思維方式
· 幫助做出更好的決定
修復代碼是業務驅動的決策。 服務器運行良好是業務驅動的決定。 開發功能是業務驅動的決策。 測量應用程序代碼和基礎架構，可以幫助您瞭解您的業務，並基於可衡量的KPI來打開數據驅動的業務，最後，KPI可以為您的業務做出更好的決策。
自2010年代初以來發生了什麼變化，因此形勢發生了重大變化？
越來越受歡迎！
如DB-Engines列出的，許多數據實際上是時間序列數據。 快速概述，例如：
· 傳感器測量（水冷卻，存在等）
· 監視數據（CPU，內存，磁盤等）
· 股票交易所（歐元，美元，比特幣）
· 資源消耗（燃料，…）
· 事件，統計信息，信號（花費的時間，...）
· 物聯網數據（停車人數，能源網格等）
· 健康（心率，...）
· 和許多其他數據，基本上任何可以可視化為圖表的數據
在所有這些領域中，收集數據在資源優化，跟蹤，預測，商業智能等方面都帶來許多好處。
自2010年代初以來，發生了很多事情。 First Graphite自2008年成立以來就已經成熟。到那時，許多時間序列用例都在傳統數據庫（如MySQL或PostgresSQL）中實現，但隨著數據量的快速增長，這些數據庫無法處理此類工作量。 OpenTSDB已於2010年發佈，對Graphite及其平面數據模型進行了重大改進。 OpenTSDB是基於HBase的，它推了許多限制。 從那裡開始，開始實施新的用例，主要用於監視目的，但其他項目也已推入適當的時間序列模型。 然後，其他項目進入了遊戲，例如KairosDB，InfluxDB，Prometheus和Riak TS等。 如今，現代時間序列平臺結合了更多功能，而不僅僅是繪製圖表，其中一些功能已成為真正的分析平臺，例如Warp10。
時間序列DBMS流行趨勢
市場上有許多解決方案可以滿足不同的標準，選擇正確的解決方案可能會具有挑戰性：
· 發行：開源，開放核心，專有
· 源語言：Java，Golang，Python，Erlang等
· 多功能性：分佈式，獨立，嵌入式
· 數據模型：現代，平面，公制/標籤，文本
· 數據存儲：全分辨率與固定數據庫
· 支持的數據類型：整數，浮點數，布爾值，字符串
· 查詢模型：交互式，作業，MapReduce
· 分析：服務器端功能，SDK，自定義
趨勢很重要，但不是唯一標準，衡量生態系統也很有趣。 生態系統包括諸如圖書館合規性，貢獻，被其他項目採用，協議兼容性和可用性，項目路線圖等方面。
在OVH Metrics中，我們已經對許多時間序列數據庫進行了廣泛的測試並與之合作，在這些帖子中，我們希望對您對其中的一些感覺提供快速反饋：
InfluxDB
根據DB-Engines的報告，InfluxDB是"時間序列數據庫"領域的當前領導者。 這個領先地位很容易解釋：自2014年底以來，InfluxDB就在這裡，其Open Core模型，單一二進制分發版本和周到的社區方法極大地幫助了他們，尤其是在小型項目中。
多年來，InfluxDB一直在不斷改進，不斷地重建其存儲層以解決許多早期問題。 兩個主要問題仍然限制了它對大型項目的實用性：Kapacitor的性能不佳，用於運行連續查詢的組件（我們將其稱為OVH Metrics的Loops）以及使用身份驗證時的緩慢性。
最初，InfluxDB提出了一種類似SQL的查詢語法，在處理時間序列模型時，我們認為這不是最好的語法。 最近，Influx發佈了一種有趣的語言，它可以將簡單的查詢和數據流結合在一起：IFQL。 對於在大型項目中使用IFQL及其相關挑戰，我們還沒有任何反饋。
Graphite
作為"時間序列"數據庫領域中的老大，由於較年輕的工具以更新穎的方式提出了更多功能，因此Graphite失去了一定的知名度。 Graphite提供了相當完整的功能集來操作數據集，即使其原始數據模型相當侷限，也使用扁平的點分隔度量標準命名。 這種命名策略使構建複雜的查詢變得更加困難，因為要使用正則表達式來匹配所需的選擇，但當時還不錯，並且為小批量提供了許多功能。
幾年來，該項目緩慢下降，沒有任何重大進展。 但是在過去的幾個月中，Graphite受到了新的關注，其新功能包括使用標籤存儲數據以及加入其他現代數據模型。
OpenTSDB
受Borgmon（Google內部監控工具）的啟發，OpenTSDB是第一個提出現代數據模型的開源時間序列數據庫：每個時間序列均由度量標準名稱和標籤列表定義。
可伸縮性是OpenTSDB的主要租戶之一，它使用HBase作為存儲引擎。 這意味著要使用它，您需要使用HBase安裝和管理Hadoop集群，因此部署起來並不容易。 在切換到OVH指標之前，OpenTSDB在OVH中得到了廣泛使用。
Prometheus
Prometheus是Borgmon的模仿者，也是InfluxDB的主要挑戰者之一。 如果他們的當前趨勢繼續下去，普羅米修斯格式可以在可預見的將來發展成為事實上的監控標準。 從純粹的內存時間序列數據庫演變而來，Prometheus添加了一個存儲層，可以用作持久性存儲。 它仍然無法作為分佈式解決方案使用，因此既無法擴展以適應高工作負載，也無法提供高可用性。
與以前的解決方案相比，Prometheus更加面向分析，它使用一種查詢語言PromQL。 儘管PromQL比OpenTSDB更完整，但它仍然缺少用作分析時間序列平臺的許多功能。 在Google內部，由於Borgmon的語言語法以及它不是服務的事實，許多人不喜歡Borgmon，每個團隊都需要部署和管理自己的Borgmon。 不幸的是，作為Borgmon克隆的Prometheus也存在相同的缺陷。 值得一提的是，自那時以來，Google已切換到Monarch，這是@OvhMetrics之類的指標服務。
在OVH，我們通過提供自定義導出器與Prometheus生態系統集成，並開發了Beamium刮板，該刮板提出了指標推送（而不是拉取）和細粒度身份驗證的功能，並在出現網絡問題時提供了DFO（磁盤故障轉移）。
Warp 10
Warp 10像OpenTSDB一樣起源於Borgmon，但除了其API外，它還提供了一個稱為WarpScript的豐富數據處理框架，其中包含數百個功能。 從這個角度來看，它是Graphite及其大型圖書館的唯一挑戰者。
Warp 10支持多個存儲引擎，其中一個獨立版本存儲在LevelDB上，而一個分佈式版本則依賴於OpenBase等HBase。 它的數據模型比OpenTSDB更為靈活，Warp 10解決了我們在OpenTSDB中觀察到的非常大的數據集的可伸縮性問題。
Warp10擁有一個新興的社區，即使在用戶體驗方面仍然落後一些，我們今天仍將其視為用於大規模操作時間序列的最成熟的開源技術。 作為我們選擇的技術之一，我們正在為項目提供工具（遊覽，鍛造）以增強用戶體驗。
OVH指標
在Metrics，我們認為每種解決方案都具有不同的價值，因此決定最適合您的不是我們的職責。 對於給定的需求，您可能對OpenTSDB或PromQL查詢的簡單性感興趣，而對於另一個需求，對於高級分析用例，可能需要WarpScript。 這就是為什麼我們認為我們的平臺在Query層上是不可知的，並且我們已經實施了其中的一些以滿足客戶的需求。 目前，我們支持：
· InfluxDB
· Graphite
· OpenTSDB
· PromQL /Prometheus
· WarpScript / Warp10
不可知論，您可以使用協議推送指標，並通過另一協議查詢相同指標。 或使用兩種不同的協議兩次查詢相同的指標。 這樣，就沒有供應商鎖定。
在時間序列數據庫上工作非常艱鉅，充滿挑戰：
· 寫與讀模式
· 處理大量基數問題
· 處理短暫時間序列
· 存儲數據模型設計與通用查詢模式
· 結合實時和分析工作負載
我們還將發佈其他帖子，介紹我們如何應對這些挑戰。
如何從時間序列開始？
如果您確信需要使用時間序列解決方案，那麼以下是快速入門的第一步：
· 識別您的時間序列數據或業務KPI
· 檢測您的應用程序以暴露這些KPI
· 選擇諸如OVH Metrics之類的託管服務，或者從自營的開源解決方案開始
· （可選）使用Noderig或收集器（node-exporter，telegraf，scollector等）獲取基礎結構指標
· （可選）設置Beamium，以抓取您的應用和/或基礎架構指標
· 設置儀表板以根據收集的指標可視化您的KPI
· 您現在可以關聯應用程序和基礎架構
現在，您應該對業務問題有了更好的瞭解。
在Twitter上關注我們：@OvhMetrics。 您想與我們一起應對此類挑戰嗎？ 在推特上給我們發信:)
(本文翻譯自Steven Le Roux的文章《Time Series DB are getting momentum!》，參考：https://medium.com/ovh-metrics/time-series-db-are-getting-momentum-d0fdda9a47c4)
閱讀更多 聞數起舞 的文章
