本次实验使用的人工数据集不具有代表性：其时间戳从1开始以步长1递增，值在[0,100)随机取整数，导致时间戳的编码压缩效率过高、值列的编码压缩效率过低。甚至对于值列来说，和其它编码方式相比，采用PLAIN编码的空间大小是最小的。
在中车ZT11529数据集上的实验结果来看：
- 真实数据集的压缩率高、磁盘数据量相对小，此时【从磁盘加载Chunk数据的耗时】小于【解压缩和解码Page数据的耗时】，即整体耗时瓶颈不是磁盘IO。
- D-1步骤内部的耗时瓶颈就是子步骤7_2_data_decompress_PageDataByteArray。注意：人工数据实验里发现另一个子步骤7_1_data_ByteBuffer_to_ByteArray(us)的占比也高，分析是因为人工数据压缩率很低，子步骤7_2_data_decompress_PageDataByteArray(us)耗时相对少，从而7_1_data_ByteBuffer_to_ByteArray(us)耗时占比相对偏高。
- D-2类操作内部没有某一个子步骤是突出的耗时瓶颈。
- 相对其它压缩方法，GZIP的压缩率最高，但磁盘加载IO代价和解压缩代价之间有tradeoff，GZIP压缩下的整体读耗时并不是最小的。
后续
1. 可以增大真实数据集的数据量之后再实验看看，目前使用的中车数据量级是一千万点。
2. D-1解压缩和D-2解码的空间压缩关系和耗时关系还有待探索
3. 写数据的耗时可以也测量一下
4. 注意RLE编码对于浮点数是有损的

实验设置

IoTDB版本

...