InfluxDB是一個由InfluxData開發的開源時序數據庫，專一於海量時序數據的高性能讀、寫、高效存儲與實時分析等，在DB-Engines Ranking時序型數據庫排行榜上常年排名第一。數據庫
InfluxDB能夠說是當之無愧的佼佼者，但 InfluxDB CTO Paul 在 2020/12/10 號在博客中發表一篇名爲：Announcing InfluxDB IOx – The Future Core of InfluxDB Built with Rust and Arrow的文章，介紹了一個新項目 InfluxDB IOx，InfluxDB 的下一代時序引擎。服務器
接下來，我將連載對於InfluxDB IOx的源碼解析過程，歡迎各位批評指正，聯繫方式見文章末尾。微信
上一章介紹了Chunk是怎樣被寫入到持久化設備中的，詳情見：數據結構
http://www.javashuo.com/article/p-fhaiemtn-vo.html異步
這一章主要總結一下全部的代碼思路，但願可以更直觀的還原IOx的執行，以及執行過程當中的各類數據格式。性能
咱們知道寫入是由客戶端發起的(在第六章中有客戶端寫入數據的示例)，服務器使用一個Grpc的協議接收客戶端數據。 這是第一次入口點，數據格式是LP,相似這樣:ui
myMeasurement,tag1=value1,tag2=value2 fieldKey="123" 1556813561098000000
數據接收到以後就會轉換爲一個ParsedLine結構，根據輸入的數據庫名、表名、時間及數據，預先對數據進行shard及partition的分配，使用一個多級的BtreeMap結構進行存儲。如圖： 
.net
以後會再根據這個數據結構進行遍歷，生成爲flatbuffers的數據結構(轉換爲這個格式是爲了傳輸效率及收到方的高效使用)，並行對各個shard進行數據寫入。3d
根據shardId能夠獲取到配置的機器組中各個節點的Ip地址，而後根據配置的寫入節點數，進行順序的一個節點一個節點的寫入。code
PS：這裏比較拗口，就是shard和shard之間是並行寫的，可是shard中的每一個節點是串行寫入的。
這時候遠程服務器，就會收到這個flatbuffers結構的數據，收到以後的第一任務就是寫入Write Buffer（這裏的Write Buffer至關於其餘數據庫的WAL，可是不一樣的是功能要更多一些，能夠作一些排序等額外的工做，就至關於一個寫緩衝）。
在排序和寫入WAL以後，就開始寫入到MutBuffer中了，總體的存儲結構如圖所示。
到了MbChunk以後，作了一次字典壓縮，把field、tag等等的字符串都轉爲了id，而後使用列式存儲，一列一列的存儲下來。如圖：
以後數據會被移動到readbuffer當中，變爲不可寫的數據。在readbuffer中數據結構是arrow格式的：
這裏出現了兩個metadata，第一個是表級別的，第二個是小塊級別的，由於在寫入過程當中，有可能第一個chunk和第二個chunk的列不同多，這樣就在表級別存了一個最全的metadata。
到這裏基本上這章就能夠結束了，最後附一張pauldix的關於寫入及異步模型圖：
祝各位玩兒的開心。
歡迎關注微信公衆號：
或添加微信好友： liutaohua001