OpenTSDB 是一種基於 HBase 編寫的分散式、可擴展的時間序列資料庫。 它適用什麼場景呢？
所謂時序列，當然肯定有一列是時間，一般都是時間戳，有精確到秒的，也有精確到nano秒的。一聽到時序列資料庫，如果只是稍有耳聞的人，可能立刻會聯想到運維和監控系統。
沒錯，確實是很多運維、監控系統都採用了TSDB作為資料庫系統來存儲海量的、嚴格按時間遞增的、在一定程度來說結構非常簡單的各種指標（英文可能為metric、measurement或者類似的其他單詞）數據。
這是維基百科上的解釋：
A time series database (TSDB) is a software system that is optimized for handling time series data, arrays of numbers indexed by time (a datetime or a datetime range).
翻譯過來就是「時序列資料庫用來存儲時序列（time-series）數據並以時間（點或區間）建立索引的軟體。」
其中，時序列數據可以定義如下：
可以唯一標識的序列名/ID（比如cpu.load.1）及meta-data；
一組數據點{timestamp, value}。timestamp是一個Unix時間戳，一般精度會比較高，比如influxdb裡面是nano秒。一般來說這個精度都會在秒以上。
一般時序列數據都具備如下兩個特點：
數據結構簡單
數據量大
所謂的結構簡單，可以理解為某一度量指標在某一時間點只會有一個值，沒有複雜的結構（嵌套、層次等）和關係（關聯、主外鍵等）。
數據量大則是另一個重要特點，這是由於時序列數據由所監控的大量數據源來產生、收集和發送，比如主機、IoT設備、終端或App等。
此外，現在很多OLAP系統也都開始使用TSDB，比如Druid等。
如果你對TSDB感興趣，可以關注這個公號，回復TSDB即可查看相關文章。
這是其中幾篇：
時序列資料庫武鬥大會之什麼是TSDB
時序列資料庫武鬥大會之TSDB名錄上半場
時序列資料庫武鬥大會之TSDB名錄下半場
時序列資料庫武鬥大會之OpenTSDB篇
一些數據量大的實時監控系統，比如像網頁的訪問量之類的
各種監控統計，活躍度、熱門排行、請求處理延遲等等以個人使用經驗來看 OpenTSDB 並不算優秀，推薦關注 GitHub - influxdata/influxdb: Scalable datastore for metrics, events, and real-time analytics時序資料庫通用場景是監控，潛力領域是IoT。時序資料庫有很多種，各有優劣，設計上各有取捨。
就OpenTSDB而言，它適合海量數據存儲、高並發高吞吐寫，但是複雜查詢的效率很差，因為沒有索引。
最近寫了幾篇文章，還沒完全寫完，可以看看：
時間序列數據的存儲和計算 - 概述
時間序列數據的存儲和計算 - 開源時序資料庫解析（一）待續。。
著作權歸作者所有。
商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
作者：bonelee
鏈接：OpenTSDB介紹--基於Hbase的分散式的，可伸縮的時間序列資料庫，而Hbase本質是列存儲 - bonelee - 博客園
來源：博客園
OpenTSDB介紹
1.1、OpenTSDB是什麼？主要用途是什麼？
官方文檔這樣描述：OpenTSDB is a distributed, scalable Time Series Database (TSDB) written on top of HBase；翻譯過來就是，基於Hbase的分散式的，可伸縮的時間序列資料庫。主要用途，就是做監控系統；譬如收集大規模集群（包括網路設備、操作系統、應用程序）的監控數據並進行存儲，查詢。1.2、介紹continue存儲到OpenTSDB的數據，是以metric為單位的，metric就是1個監控項，譬如伺服器的話，會有CPU使用率、內存使用率這些metric；OpenTSDB使用HBase作為存儲，由於有良好的設計，因此對metric的數據存儲支持到秒級別；OpenTSDB支持數據永久存儲，即保存的數據不會主動刪除；並且原始數據會一直保存（有些監控系統會將較久之前的數據聚合之後保存）OpenTSDB存儲相關的概念介紹這些概念的時候，我們先看一個實際的場景。譬如假設我們採集1個伺服器（hostname=qatest）的CPU使用率，發現該伺服器在21:00的時候，CPU使用率達到99%
下面結合例子看看OpenTSDB存儲的一些核心概念1）Metric：即平時我們所說的監控項。譬如上面的CPU使用率2）Tags：就是一些標籤，在OpenTSDB裡面，Tags由tagk和tagv組成，即tagk=takv。標籤是用來描述Metric的，譬如上面為了標記是伺服器A的CpuUsage，tags可為hostname=qatest3）Value：一個Value表示一個metric的實際數值，譬如上面的99%4）Timestamp：即時間戳，用來描述Value是什麼時候的；譬如上面的21:005）Data Point：即某個Metric在某個時間點的數值。Data Point包括以下部分：Metric、Tags、Value、Timestamp上面描述的伺服器在21:00時候的cpu使用率，就是1個DataPoint保存到OpenTSDB的，就是無數個DataPoint。Servers：就是伺服器了，上面的C就是指Collector，可以理解為OpenTSDB的agent，通過Collector收集數據，推送數據；
TSD：TSD是對外通信的無狀態的伺服器，Collector可以通過TSD簡單的RPC協議推送監控數據；另外TSD還提供了一個web UI頁面供數據查詢；另外也可以通過腳本查詢監控數據，對監控數據做報警HBase：TSD收到監控數據後，是通過AsyncHbase這個庫來將數據寫入到HBase；AsyncHbase是完全非同步、非阻塞、線程安全的Hbase客戶端，使用更少的線程、鎖以及內存，可以提供更高的吞吐量，特別對於大量的寫操作。
做監控系統 和 按時間序列的統計分析， 這是opentsdb最常見的，我認為也是唯一大規模用於生產環境的應用。
時序資料庫特別適用於監控系統和IoT。目前潛在的客戶還都在用MySQL或者MongoDB、HBase等引擎撐著，數據量爆發後很快會找新的出路了。
可以搭配監控報警系統，如Bosun，對不同層級的對象進行實時監控，我也是最近正在學，在我的博客里做了一些記錄~主要用於以時間戳timestamp為key的數據，如網站實時數據統計，ETL中的數據統計，做簡單的counter。一般配合visualization，將timestamp數據按照時間順序顯示在圖表中用於監視。還可以通過不同的attribute對現有數據做SQL-like的query。
類似的工具有：
- InfluxDB（The Platform for Time-Series Data）
- Prometheus（Prometheus - Monitoring system time series database）
- Graphite（Graphite Documentation）
- StatsD（GitHub - etsy/statsd: Daemon for easy but powerful stats aggregation）
流行的組合可以用StatsD（收集系統信息） ＋ InfluxDB（TSDB）＋Grafana（可視化工具）。
主要適合監控數據存儲，不過由於其依賴hbase,略有點重，可以參考下最近比較火的influxdb
歷史分時行情或許適合
如果覺得資料少，可以參考一下informix，它也支持timeseries的
存儲海量時序數據，例如監控數據。
推薦閱讀：
※日後想在資料庫方面發展，需要有哪些必備的技能？
※可否對比一下 TiDB 與 AWS Aurora ？
※資料庫出生日期用什麼類型比較好？datetime 或 varchar ？
※大家如何看待類似於達夢資料庫這樣的號稱具有自主知識產權的國產軟體？
※MySQL插入「 」字時報錯，請問是什麼原因？