InfluxDB索引

　　InfluxDb分為兩種索引，一種是TSM檔案内置的Series索引，另一種就是反向索引，

　　Series索引：在InfluxDB的内置索引中Series + field就是主鍵，定位到某項名額的一個索引塊，索引塊由N個索引實體組成，每個索引實體提供了最小時間和最大時間，以及這個時間範圍對應到TSM檔案Series資料塊的偏移量，TSM檔案有多個Series資料塊組成，每個Series資料塊就包含了時間清單(Timestamps)，索引實體的最小時間和最大時間就對應了這個時間清單。是以Series索引塊就可以通過Key排序，并通過時間範圍進行二分查找，先快速定位某個時間範圍上的時序資料，然後再做掃描比對。

　　反向索引：InfluxDB除了TSM結構之外，還有TSI結構，TSI主要是進行時序資料的反向索引，例如：通過動環檢測-高新區機房為條件查詢高新區機房各個區域的各項名額，或者也可以通過動環檢測-資料區域為條件查詢所有機房的資料區域的各項名額。

　　TSI的資料結構為：Map集合<标簽名,Map集合<标簽值,List清單>>，第一層就是标簽名集合，第二層就是某個标簽名下的所有标簽集合，例如：标簽名為區域，就包含了資料區、計算區等标簽值，第三層就是具體某個标簽對應的資料源了，例如：包含資料區标簽的資料源有動環檢測-高新區-資料中心，動環檢測-西鹹新區-資料中心等數。

　　通過這種索引方式就能實作通過标簽快速索引包含此标簽的所有資料源。通過資料源的Series，再從TSM檔案中按其他條件查找。

　　TSI資料模型使用了與TSM一樣的套路，本質上都是基于LSM資料結構，伴随資料寫入，反向索引先寫WAL，在寫記憶體In-Memory Index，當達到記憶體閥值後Flush倒TSI檔案，而TSI檔案就是基于磁盤的Disk-Based

Index的反向索引檔案，裡面包含了Series塊和标簽塊，可以通過标簽塊中的标簽值在Series塊中找到對應的所有Series。

　　時序庫在這種按資料源标簽(Tag)分類的分析查詢上會表現得非常高效，這也是InfluxDB充分應對了時序資料業務的需要。

　　分布式

　　InfluxDB在叢集方面閉源了，這的确是件非常可惜的事情。不過可以了解，任何技術創業公司都要謀求生存和發展，商業輸血是必須的，希望有一天InfluxDB的母公司能被巨頭收購，然後再次完全開源。

　　我在以前專門講過一期HBase和Cassandra的對比，有興趣的朋友可以看看：HBase 與 Cassandra 架構對比分析的經驗分享

　　InfluxDB更傾向于去中心化的分布式，裡面有我對兩者分布式的對比，而InfluxDB更接近于Cassandra，Cassandra是一套去中心化的分布式架構，而InfluxDB包括了Meta節點和Data節點，但是Meta節點看似是主節點，但作用很薄弱，主要存儲一些公共資訊和連續查詢排程，資料讀寫問題主要還是集中在Data節點，而Data節點之間的讀寫，更貼近于去中心化的方式。

　　InfluxDB是CAP定理中的AP分布式系統，非常側重于高可用，而不是一緻性。其次InfluxDB的主要是兩級分片，第一級為ShardGroup，次一級是Shard。

　　ShardGroup是個邏輯概念，代表一個時間段内的多個Shard，在建立InfluxDb資料庫(DataBase)和保留政策(RETENTION POLICY)後就确定了ShardGroup的連續時間段，這就相當于對時序資料首先進行了按照時間段範圍的分區，例如1個小時作為一個ShardGroup。

　　但是這1個小時内的資料并不是存儲在一個資料節點上，這點就大大不同于HBase的Region了，Region首先會朝一個資料節點使勁地寫，寫飽了才進行Region拆分，然後實作Region遷移分布。

　　而InfluxDB應該是參考了Cassandra那一套辦法，使用了基于Series作為Key的Hash分布，将一個ShardGroup的多個Shard分布在叢集中不同的資料節點上。

　　下面定位shard的代碼中key就是Series，也就是唯一指定的資料源(表measurement +标簽集合 tagset)。

　　shard := shardGroup.shards[fnv.New64a(key) % len(shardGroup.Shards)]

　　上面代碼中shardGroup.Shards就是ShardGroup的Shard數量，該數量為N/X，N是叢集中的資料節點數量，X就是副本因子。

　　例如：叢集有4個節點，2個副本，4/2就得到了需要将1個小時的ShardGroup範圍資料拆成2個Shard，并各複制2份，分布在四個資料節點，就是通過這種Hash分布方式，更均勻的分布了時序資料，也充分利用叢集每一個資料節點的讀寫優勢。

　　InfluxDB是最終一緻性，在寫入一緻性上實作了各種調節政策Any、One、Quorum、All，和Cassandra如出一轍，并且加強了協調節點的Hinted handoff的臨時隊列持久化作用，這就是完全為了高可用性。

　　即便真正的副本節點故障了，就先在協同節點的Hinted handoff隊列中持久化儲存，等到副本節點故障恢複後，再從Hinted handoff隊列中複制恢複。就是為了達到最終一緻性。

　　另外InfluxDB和Cassandra3.x及以前版本一樣，具有背景碎片修複的反熵功能(anti-Entrory)，不過有意思的地方是Cassandra在新的4.0版本已經不在保留背景讀修複的功能了，而且之前版本也不推薦啟用，因為具有了主動讀修複能力，背景讀修複作用不大，而且還影響性能。

　　當然InfluxDB是不是和Cassandra一樣，在讀取的過程中進行了主動讀修複，因為是閉源系統，這點上我還不太清楚。​​鄭州治療精神分裂症哪裡好​​​​http://www.juenpt.com/​​

　　InfluxDB在删除問題上會表現的非常薄弱，隻允許删除一個範圍集合或者Series下的一個次元集合，這也是這種時序結構的設計使然，對單個Point的删除會很麻煩，成本很大。

　　删除方法上應該也是參考了Cassandra的Tombstone機制：去中心化的問題就是怕大家都删除副本後，某個正好處于故障中的副本節點又恢複了，它不知道發生了什麼事情，但修複過程中它會認為被删除的副本大家弄丢了，而去讓大家恢複。

　　有了Tombstone标記的長期存在，那麼存在副本資料的故障節點，當恢複後根據其他副本節點Tombstone标記，也就知道自己故障期間曾經發生了删除的情況，馬上進行自身對應副本資料的删除。

　　總結