一、基本介紹
1，時序數據介紹
（1）時間序列數據（Time Series Data，TSD，以下簡稱時序）從定義上來說，就是一串按時間維度索引的數據。
（2）簡單的說，就是這類數據描述了某個被測量的主體在一個時間范圍內的每個時間點上的測量值。它普遍存在於 IT 基礎設施、運維監控系統和物聯網中。
2，時序數據庫介紹
（1）時序數據庫產品的發明都是為了解決傳統關系型數據庫在時序數據存儲和分析上的不足和缺陷，這類產品被統一歸類為時序數據庫（TSDB）
（1）在傳統關系型數據庫上加上時間戳一列並不能真正作為時序數據庫。因為時序數據往往是由百萬級甚至千萬級終端設備產生的，寫入並發量比較高，屬於海量數據場景。此時傳統關系型數據庫就會出現問題。
（2）MySQL 在海量的時序數據場景下存在如下問題：
- 存儲成本大：對於時序數據壓縮不佳，需占用大量機器資源；
- 維護成本高：單機系統，需要在上層人工的分庫分表，維護成本高；
- 寫入吞吐低：單機寫入吞吐低，很難滿足時序數據千萬級的寫入壓力；
- 查詢性能差：適用於交易處理，海量數據的聚合分析性能差。
（3）另外，使用 Hadoop 生態（Hadoop、Spark 等）存儲時序數據會有以下問題：
- 數據延遲高：離線批處理系統，數據從產生到可分析，耗時數小時、甚至天級；
- 查詢性能差：不能很好的利用索引，依賴 MapReduce 任務，查詢耗時一般在分鍾級。
（2）時序數據庫時序數據的特點對寫入、存儲、查詢等流程進行了優化，具體特點如下：
- 數據壓縮存儲：利用時間遞增、維度重復、指標平滑變化的特性，合理選擇編碼壓縮算法，提高數據壓縮比；通過預降精度，對歷史數據做聚合，節省存儲空間。
- 高並發寫入：批量寫入數據，降低網絡開銷；數據先寫入內存，再周期性的 dump 為不可變的文件存儲。
- 低查詢延時，高查詢並發：優化常見的查詢模式，通過索引等技術降低查詢延時；通過緩存、routing 等技術提高查詢並發。
（3）目前行業內比較流行的開源時序數據庫產品有 InfluxDB、OpenTSDB、Prometheus、Graphite 等，其產品特性對比如下圖所示：
3，InfluxDB 介紹
（1）InfluxDB 是一個開源分布式時序、時間和指標數據庫，使用 Go 語言編寫，無需外部依賴。其設計目標是實現分布式和水平伸縮擴展，是 InfluxData 的核心產品。
注意：InfluxDB 不是一個完整的 CRUD 數據庫，它更像是一個 CR-ud 數據庫。它優先考慮的是增加和讀取數據而不是更新和刪除數據的性能，而且它阻止了某些更新和刪除行為使得創建和讀取數據更加高效。
（2）InfluxDB 自帶的各種特殊函數如求標准差，隨機取樣數據，統計數據變化比等，使數據統計和實時分析變得十分方便。 此外它還有如下特性：
- 內置 HTTP 接口，使用方便
- 數據可以打標記，這樣查詢可以很靈活
- 類 SQL 的查詢語句
- 安裝管理很簡單，並且讀寫數據很高效
- 能夠實時查詢，數據在寫入時被索引后就能夠被立即查出
（3）InfluxDB 常用於性能監控，應用程序指標，物聯網傳感器數據和實時分析等的后端存儲。
4，InfluxDB 基本概念
（1）
database
- database 類似傳統數據庫中的數據庫概念。
- 一個數據庫可以有多個 measurement，retention policy，continuous queries 以及 user。
（2）
measurement
- measurement 類似傳統數據庫中的表概念。
- measurement 是 fields，tags 以及 time 列的容器，measurement 的名字用於描述存儲在其中的字段數據，類似 mysql 的表名。
（3）
point
- point 類似傳統數據庫中表中的一行數據
- point 的數據結構由時間戳（time）、標簽（tags）、數據（fields）三部分組成
（4）
timestamp
- 既然是時間序列數據庫，influxdb 的數據都有一列名為 time 的列，里面存儲 UTC 時間戳。
（5）
field key、
field value、
field set
- field 為字段，在 influxdb 中，字段必須存在（即數量必須 >=1）。注意，字段是沒有索引的。如果使用字段作為查詢條件，會掃描符合查詢條件的所有字段值，性能不及 tag。
- 其中 field key 為字段名，field value 為字段值，field value 可以為 string，float，integer 或 boolean 類型
- field key 和 field value 對組成的集合稱之為 field set
（6）
tag key、
tag value、
tag set
- tag 為標簽，在 InfluxDB 中可以沒有 tag（即數量 >=0）。不同於 field，tag 是有索引的。
- 其中 tag key 為標簽名，tag value 為標簽值，tag value 只能是 string 類型
- tag key 和 tag value 對組成的集合稱之為 tag set
（7）
retention policy
- retention policy 指數據保留策略（更詳細介紹可以看本文下方附錄部分）。
- measurement 默認會有一個 autogen 的保留策略，autogen 中的數據永不刪除且備份數 replication 為 1（只有一份數據，在集群中起作用）。
（8）
series
- series 相當於是 InfluxDB 中一些數據的集合，在同一個 database 中，retention policy、measurement、tag sets 完全相同的數據同屬於一個 series
- 同一個 series 的數據在物理上會按照時間順序排列存儲在一起。
附：InfluxDB 保留策略（retention policy）
（1）每個數據庫剛開始會自動創建一個默認的存儲策略 autogen，數據保留時間為永久，在集群中的副本個數為 1。
（2）插入和查詢數據時如果不指定存儲策略，則使用默認存儲策略，且默認存儲策略可以修改。
（3）用戶可以自己設置保留策略（查看、新建、修改、刪除），例如保留最近 2 小時的數據。InfluxDB 會定期清除過期的數據。
（4）建議在數據庫建立的時候設置存儲策略，不建議設置過多且隨意切換
create database testdb2 with duration 30d
（5）每個數據庫可以有多個過期策略，使用如下語句查看：
show retention policies on "db_name"
（6）Shard 在 influxdb 中是一個比較重要的概念，它和 retention policy 相關聯：
- 每一個存儲策略下會存在許多 shard，每一個 shard 存儲一個指定時間段內的數據，並且不重復，例如 7 點 - 8 點 的數據落入 shard0 中，8 點 - 9 點的數據則落入 shard1 中。
- 每一個 shard 都對應一個底層的 tsm 存儲引擎，有獨立的 cache、wal、tsm file。
- 這樣做的目的就是為了可以通過時間來快速定位到要查詢數據的相關資源，加速查詢的過程，並且也讓之后的批量刪除數據的操作變得非常簡單且高效。