时序数据库 Apache-IoTDB 源码解析之文件格式简介（三）

上一章聊到在车联网或物联网中对数据库的需求，以及 IoTDB 的整体架构，详情请见：

打一波广告，欢迎大家访问IoTDB 仓库，求一波 Star 。欢迎关注头条号：列炮缓开局，欢迎关注 OSCHINA博客

这一章主要想聊一聊：

行式存储、列式存储的区别
TsFile 的格式

行式与列式存储的区别

假如我们的逻辑上的数据表格式及数据为：

时间戳	人名	体温
1580950800	张三	36.5
1580950800	李四	36.9
1580950800	王五	36.7

那么他出现在硬盘格式就是：

行式数据

在我理解上，行式数据是把逻辑相关的数据在硬盘上放到一起，比如上面的例子，我们可以称之为体温表，所以在逻辑上：时间、人、体温，就成为了逻辑上紧密相关的数据。

所以把相关的数据的硬盘上的组织方式也变成连续的，假如我需要取 张三 的数据，那么当你读出 R1 文件块的时候，就是读出了所有 张三 相关的数据。

列式数据

列式数据在我理解是将物理相关的数据放到一起，比如时间是一类(long 类型)、名字是一类(string 类型)、体温是一类(float 类型)。当然这种硬盘的组织方式，相比起行式数据库，在取拼回体温表的结构的时候，速度就慢了很多，因为你要分别取 C1、C2、C3 文件块，然后还要写个容器往里 Set()。那么列式数据存储方式相比于行式存储优势在哪里呢？

1.1 取数据方式

有一种叫法是只读投影列，避免查询无关列的读取。列式存储的优势在于查询的列数远小于总属性数量，就能少读很多数据。可能读起来非常绕口，举个例子：比如我需要查体温大于 36 度的体温值，sql : select 体温 FROM table WHERE 体温 > 36 。这时候如果是列式存储只需要读出 C3 数据块就可以一次性查到所有数据。而行式数据库中，则需要读出 R1、 R2、 R3。在第二章中介绍到物联网中的时序数据的特点：存量数据非常大，如果遍历几百亿数据，时间差距明显就拉开了。

1.2 数据编码和压缩

因为物理相关的数据他们类型相同，可以使用多种多样的编码方式，比如 IoTDB 中就提供了 8 种编码方式，这个不具体聊，等后面章节再说。

我们继续拿时间列举例子，我们可以把时间列改造为差值存储：比如 C1 文件块中先存储基础值 1580950800 那么他后面的数据值只需要存储 0 就可以，存储的数字小了，那么占用的存储空间肯定也就小了，当数字特别大且差值比较小的时候，这用编码方式就非常有意义。当然还有很多好玩儿的编码方式，欢迎持续关注。

TsFile 文件格式

为什么叫 TsFile ？我听意思应该是作为 TimeSeriresFile 的缩写，也就是时序数据文件的意思。

这是一个数据被刷入磁盘后的缩减版 TsFile 格式，我们还拿上面的数据举例，用来直观的解释 TsFile 中出现的一些名词，假如我的数据为：

时间戳	人名	体温	心率
1580950800	张三	36.5	70
1580950800	李四	36.9	80
1580950800	王五	36.7	100
1580950911	王五	36.6	90

上面的数据刷新到磁盘上后会对应关系如下：

看到这里应该能理解每个英文名词的意思：

ChunkGroup 代表了设备(逻辑概念上的一个集合)，在 IoTDB 中称为 Device。
Chunk 代表了测点数据(逻辑概念上的某一类数据的集合,如体温数据)，在 IoTDB 中称为 Measurement。
Page 中存储的是具体数据，包含一个时间序列、一个值序列。
PageStatistics 是保存的是Page当中数据的预聚合信息。
ChunkStatistics 是保存的是Chunk当中数据的预聚合信息。

ChunkGroup 中包含多个 Chunk，Chunk 中包含多个 Page ，Page 中包含多个时间点和数据项

回想上面提到的 SQL : select 体温 FROM 王五 WHERE 体温 > 36 , 在 TsFile 中，只要在文件中找到 王五 的 ChunkGroup ，并在 ChunkGroup 中找到 体温 的 Chunk，然后从第一个 Page 开始遍历就完成了。

介绍完了 Chunk 和 ChunkGroup 的概念，那么如果 Chunk 和 ChunkGroup 非常多的时候，TsFile 怎么来设计才能快速的定位并找到合适的 ChunkGroup 的呢？TsFile 怎样才能做到损坏时的检测或者保证传递过程的完整性呢？欢迎持续关注。。。

有兴趣的朋友可以查看：官方 Github 中的 TsFile 文档，了解更多详细信息。