現有的開源時序數據庫influxdb只支持單機運行，在面臨大量數據寫入時，會出現查詢慢，機器負載高，單機容量的限制。

為了解決這一問題，360基礎架構團隊在單機influxdb的基礎上，開發了集群版——QTSDB。

一、QTSDB 簡述

QTSDB是一個分布式時間序列數據庫，用于處理海量數據寫入與查詢。實現上，是基于開源單機時序數據庫influxdb 1.7開發的分布式版本，除了具有influxdb本身的特性之外，還有容量擴展、副本容錯等集群功能。

主要特點如下：

• 為時間序列數據專門編寫的高性能數據存儲, 兼顧寫入性能和磁盤空間占用;
• 類sql查詢語句, 支持多種統計聚合函數;
• 自動清理過期數據;
• 內置連續查詢，自動完成用戶預設的聚合操作;
• Golang編寫，沒有其它的依賴, 部署運維簡單;
• 節點動態水平擴展，支持海量數據存儲;
• 副本冗余設計，自動故障轉移，支持高可用;
• 優化數據寫入，支持高吞吐量;

二、系統架構

1. 邏輯存儲層次結構

influxdb架構層次***是database，database下邊根據數據保留時長不同分成了不同的retension policy，形成了database下面的多個存儲容器，因為時序數據庫與時間維度關聯，所以將相同保留時長的內容存放到一起，便于到期刪除。除此之外，在retension policy之下，將retension policy的保留時長繼續細分，每個時間段的數據存儲在一個shard group中，這樣當某個分段的shard group到期之后，會將其整個刪掉，避免從存儲引擎內部摳出部分數據。例如，在database之下的數據，可能是30天保留時長，可能是7天保留時長，他們將存放在不同的retension policy之下。假設將7天的數據繼續按1天進行劃分，就將他們分別存放到7個shard group中，當第8天的數據生成時，會新建一個shard group寫入，并將第 1天的shard group整個刪除。

到此為止，同一個retension policy下，發來的當下時序數據只會落在當下的時間段，也就是只有***的shard group有數據寫入，為了提高并發量，一個shard group又分成了多個shard，這些shard全局唯一，分布于所有物理節點上，每個shard對應一個tsm存儲引擎，負責存儲數據。

在請求訪問數據時，通過請求的信息可以鎖定某個database和retension policy，然后根據請求中的時間段信息，鎖定某個(些)shard group。對于寫入的情況，每條寫入的數據都對應一個serieskey(這個概念后面會介紹)，通過對serieskey進行哈希取模就能鎖定一個shard，進行寫入。而shard是有副本的，在寫入的時候會采用無主多寫的策略同時寫入到每個副本中。查詢時，由于查詢請求中沒有serieskey的信息，所以只能將shard group內的shard都查詢一遍，針對一個shard，會在其副本中選擇一個可用的物理節點進行訪問。

那么一個shard group要有多少shard呢，為了達到***并發量，又不過分干擾數據整體的有序性，在物理節點數和副本數確定后，一個shard group內的shard數量是機器數除以副本數，保障了當下的數據可以均勻寫入到所有的物理節點之上，也不至于因為shard過多影響查詢效率。例如，圖上data集群有6個物理節點，用戶指定雙副本，那么就有3個shard。

2. 集群結構

整個系統分成三個部分：proxy、meta集群、data集群。proxy負責接收請求，無狀態，其前可接lvs支持水平擴展。meta集群保存上面提到的邏輯存儲層次及其與物理節點的對應關系，通過raft協議保障元數據的強一致，這里meta信息保存在內存中，日志和快照會持久化到磁盤。data集群是真正的數據存儲節點，數據以shard為單位存儲于其上，每個shard都對應一個tsm存儲引擎。

請求到來的時候，經過lvs鎖定一臺proxy，proxy先根據database、retension policy和時間段到meta集群查找meta信息，最終得到一個shard到物理節點的映射，然后將這個映射關系轉換為物理節點到shard的映射返回給proxy，***根據這個映射關系，到data集群指定的物理節點中訪問具體的shard，至于shard之下的數據訪問后邊會介紹。

三、數據訪問

1. 語法格式

influxdb的查詢提供類似于關系數據庫的查詢方式，展示出來類似一個關系表：measurement，時序數據庫的時間作為一個永恒的列，除此之外的列分成兩類：

• field：一類是field，他們是時序數據最關鍵的數據部分，其值會隨著時間的流動源源不斷的追加，例如兩臺機器之間在每個時間點上的延遲。
• tag：另一類是tag，他們是一個field值的一些標記，所以都是字符串類型，并且取值范圍很有限。例如某個時間點的延遲field值是2ms，對應有兩個標記屬性，從哪臺機器到哪臺機器的延遲，因此可以設計兩個tag：from、to。

measurement展示出來***行是key，剩下的可以看成value，這樣tag有tagkey，tagvalue，field有fieldkey和fieldvalue。

2. 數據讀寫

當收到一行寫入數據時，會轉化為如下的格式：

measurement+tagkey1+tagvalue1+tagkey2+tagvalue2+fieldkey+fieldvalue+time 

如果一行中存在多個field就會劃分成多條這樣的數據存儲。influxdb的存儲引擎可以理解為一個map，從measurement到fieldkey作為存儲key，后邊的fieldvalue和time是存儲value，這些值會源源不斷追加的，在存儲引擎中，這些值會作為一列存儲到一起，因為是隨時間漸變的數據，將他們保存到一起可以提升壓縮的效果。另外將存儲key去掉fieldkey之后剩余部分就是上邊提到的serieskey。

上邊提到，訪問請求在集群中如何鎖定shard，這里介紹在一個shard內的訪問。

influxdb的查詢類似于sql語法，但是跟sql語句的零散信息無法直接查詢存儲引擎，所以需要一些策略將sql語句轉換成存儲key。influxdb通過構建倒排索引來將where后的tag信息轉換為所有相關的serieskey的集合，然后將每個serieskey拼接上select后邊的fieldkey就組成了存儲key，這樣就可以按列取出對應的數據了。

通過對tsm存儲引擎中存儲key內serieskey的分析，能夠構建出倒排索引，新版本influxdb將倒排索引持久化到每個shard中，與存儲數據的tsm存儲引擎對應，叫做tsi存儲引擎。倒排索引相當于一個三層的map，map的key是measurment，值是一個二層的map，這個二層的map的key是tagkey，對應的值是一個一層的map，這個一層map的key是tagval，對應的值是一個serieskey的集合，這個集合中的每個serieskey字串都包含了map索引路徑上的measurement、tagkey和tagval。

這樣可以分析查詢sql，用from后的measurement查詢倒排索引三級map獲得一個二級map，然后再分析where之后多個過濾邏輯單元，以tagkey1=tagval1為例，將這兩個信息作為二層map的key，查到最終的值：serieskey的集合，這個集合的每個serieskey字串都包含了measurment、tagkey1和tagval1，他們是滿足當下過濾邏輯單元的serieskey。根據這些邏輯單元的與或邏輯，將其對應的serieskey的集合進行交并運算，最終根據sql的語義過濾出所有的符合其邏輯的serieskey的集合，然后將這些serieskey與select后邊的fieldkey拼接起來，得到最終的存儲·key，就可以讀取數據了。

不帶聚合函數的查詢：如圖，對于一個serieskey，需要拼接眾多的fieldkey，進而取出多個列的數據，他們出來后面臨的問題是怎么組合為一行的數據，influxdb行列約束比較松散，不能單純按照列內偏移確定行。Influxdb把serieskey和time作為判斷列數據為一行的依據，每一個serieskey對應的多列就匯集為一個以多行為粒度的數據流，多個serieskey對應的數據流按照一定順序匯集為一個數據流，作為最終的結果集返回到客戶端。

帶聚合函數的查詢：這種方式與上邊的查詢正好相反，這里是針對聚合函數參數field，拼接上眾多的serieskey，當然最終目的都是一樣，得到存儲key，多個存儲key可以讀取多個數據流，這些數據流面臨兩種處理，先將他們按照一定的順序匯集為一個數據流，然后按照一定的策略圈定這個數據流內相鄰的一些數據進行聚合計算，進而得到最終聚合后的值。這里的順序和策略來自于sql語句中group by后的聚合方式。

多數據流的合并聚合方式，也同樣適用于shard之上的查詢結果。

對于寫入就比較簡單了，直接更新數據存儲引擎和倒排索引就可以了。

3. 整個流程

對于訪問的整個流程上邊都已經提到了，這里整體梳理一下：分成兩個階段，在shard之上的查詢，在shard之下的查詢。

首先訪問請求通過lvs鎖定到某個proxy，proxy到meta集群中查找meta信息，根據請求信息，鎖定database，retension policy和shard group，進而得到眾多的shard。

對于寫入操作，根據寫入時的serieskey，鎖定一個shard進行寫入，由于shard存在多副本，需要同時將數據寫入到多個副本。對于查詢，無法通過請求信息得到serieskey，因此需要查詢所有的shard，針對每個shard選擇一個可用的副本，進行訪問。

經過上邊的處理就獲得shard到物理節點的映射，然后將其反轉為物理節點到shard的映射，返回給proxy，proxy就可以在data集群的某個節點訪問對應的shard了。

在shard之下的寫入訪問，需要拆解insert語句，組合為存儲鍵值對存入tsm存儲引擎，然后根據組合的serieskey更新倒排索引。

在shard之下的查詢訪問，分析sql語句，查詢倒排索引，獲取其相關的serieskey集合，將其拼接field，形成最終的存儲key，進行數據訪問。然后將眾多數據在data節點上進行shard之上的合并聚合，在proxy上進行data之上的合并聚合。

最終proxy將訪問結果返回給客戶端。

四、故障處理

1. 策略

上邊提到influxdb針對shard提供副本容錯，當寫入數據發送到proxy，proxy將數據以無主多寫的形式發送到所有的shard副本。meta集群以心跳的形式監控data節點是否在線，在讀取的時候，針對同一shard會在在線的data節點中隨機選擇一個讀取節點進行讀取。

在寫入時如果一個data節點不可用，則會寫入到proxy的一個臨時文件中，等網絡恢復正常會將這些暫存的數據發送到指定節點。

2. 處理

(1) data集群擴容

當有全新節點加入data集群，目前還不支持自動將現有數據進行遷移，不過也做了些努力，為了使當下寫入數據盡快應用到新的節點，在新加入節點的時候，會將當下時間作為當下shard group的結尾時間，然后按照全新的data節點數量新建一個shard group，這樣當下數據量馬上就能均分到各個data節點，而每個shard group相關的meta信息都存儲在meta集群里，因此不會對之前數據的讀取造成干擾。

(2) data節點短暫不可用

如果data節點處于短期不可用狀態，包括短暫的網絡故障后自恢復，或者硬件故障后運維人員干預，最終data節點還存有掉線前的數據，那么就可以以原來的身份加入到data集群。對于寫入來說，不可用期間proxy會臨時存放此data節點的數據，在data加入集群時會將這部分數據再次發送到data節點，保障數據最終一致。

(3) data節點長期不可用

如果data節點由于一些原因，不能或者不需要以原來的身份加入到集群，需要運維人員手動將原來不可用的data節點下線，那么這臺機器可用時，可以以全新的data身份加入到集群中，這等同于集群的擴容。

五、總結

QTSDB集群實現為：寫入時根據serieskey將數據寫到指定shard，而讀取時無法預知serieskey，因此需要查詢每個shard。將整個讀取過程切分為兩個階段：在data節點上進行存儲引擎的讀取以及節點內部多shard的合并聚合，在proxy節點將多個data節點的數據匯總，進行后期的合并聚合，形成最終的結果集返回到客戶端。

QTSDB現有的集群功能還有不完善的地方，會在之后的使用中不斷完善。

【本文是51CTO專欄機構360技術的原創文章，微信公眾號“360技術（ id: qihoo_tech）”】

戳這里，看該作者更多好文