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
