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是怎樣被寫入到持久化設備中的，詳情見：
https://my.oschina.net/u/3374539/blog/5031456
這一章主要總結一下所有的代碼思路，希望能夠更直觀的還原IOx的執行，以及執行過程中的各種數據格式。
我們知道寫入是由客戶端發起的(在第六章中有客戶端寫入數據的示例)，服務器使用一個Grpc的協議接收客戶端數據。 這是第一次入口點，數據格式是LP,類似這樣:
myMeasurement,tag1=value1,tag2=value2 fieldKey="123" 1556813561098000000
數據接收到之後就會轉換爲一個ParsedLine結構，根據輸入的數據庫名、表名、時間及數據，預先對數據進行shard及partition的分配，使用一個多級的BtreeMap結構進行存儲。如圖： 
之後會再根據這個數據結構進行遍歷，生成爲flatbuffers的數據結構(轉換爲這個格式是爲了傳輸效率及收到方的高效使用)，並行對各個shard進行數據寫入。
根據shardId可以獲取到配置的機器組中各個節點的Ip地址，然後根據配置的寫入節點數，進行順序的一個節點一個節點的寫入。
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
