时序数据库 Apache-IoTDB 源码解析之元数据索引块（六）

时间:2021-01-28 Liutaohua 人气:0

上一章聊到 TsFile 索引块的详细介绍，以及一个查询所经过的步骤。详情请见：

时序数据库 Apache-IoTDB 源码解析之文件索引块（五）

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

阿里云、东方国信等各家公司正在招聘IoTDB数据库开发工程师，欢迎加我微信内推：liutaohua001

这一章主要想聊聊：

原有索引中的不足
新版本中索引的设计

原有索引中的不足

现在来张图回顾一下原有的数据存储方式，在文件尾部使用DeviceMetaDataIndexMap和MeasurementSchemaMap中记录所有设备数据偏移量、传感器的相关信息等。因为使用的是Map结构访问都是O(1)的，但是需要关注的一个问题就是它是在内存中O(1)的，在磁盘上并不能找到什么好的查询方式，唯一能做的就是全部读取出来然后放到内存中。

通常情况下这不会有什么问题，但是使用在工业场景中，传感器+设备很有可能数以百万计，这会引发无论你读取的是一个传感器或者是一个设备的数据，在DeviceMetaDataIndexMap这一段数据都需要完整的从磁盘上读取回来，这好吗？这不好，还拿之前的数据举例：

时间戳	人名	体温	...	年龄
1580950800	张一	36.5	...	30
1580950800	张二	36.9	...	30
1580950800	张三	36.7	...	30
1580950800	张..	36.7	...	30
1580950800	张两百万	36.7	...	30

当执行一个查询select 体温 from 张三 where time = 1580950800 时，张一、张二、张三...张两百万这两百万个名字都需要从硬盘中读取并反序列化出来(通常 IoTDB 中的路径是root.T000100010002.A_JB01.JB01.JTJBGMCA6K2052561)，也就是1999999个都是多余的读取。

此外，在TsDeviceMetaDataList中，也是按照chunkGroup存储，意味着，如果我仅查询一列，同样会把其它的列信息读取出来。

新版本中索引的设计

为了尽可能贴近只读投影列的思想，新版本中对于TsDeviceMetaDataList部分不再按照设备级别存储，改为按照传感器级别存储，TsFileMetaData部分不再使用map存储所有设备，改为使用多叉树并有序排列。

改动1: 使用将一个传感器的所有ChunkMetaData的存储在一起，并使用TimeseriesMetadata结构进行维护（保存某个传感器的开始的offset及数据长度），如图：

改动2: 在完成改动1之后，我们得到了TimeSeriesMetadata-年龄,TimeSeriesMetadata-体温, ..., TimeSeriesMetadata-x，在刷盘之前将所有TimeSeriesMetadata按照传感器名字排序，那么在这里就可以进行二分查找了，如图：

改动3: 在一个复杂的设备上传感器很有可能多达数千个，例如：新能源汽车当中，每台车量可以多达4000多个信号项。假如我们需要管理10万辆车，那么依然会有10万 * 4000 = 4亿个TimeSeriesMetadata。还是太多了，假如我们进行多个传感器的值查询时，每次都进行二分，这无疑是浪费的。

所以进行一个树状的提取，假设每1024个提取一次，那么4亿个可以节省为390,625个，假如再抽取一次，那就可以减少到382个了，这样我们从硬盘上一次读取1024个，最多读取3次硬盘就可以完成查找。大意如图：

改动4: 除了传感器之外，还要考虑的是设备级别，因为设备也是数以万计，但同上面的逻辑是一样的。再此就不进行赘述，如图：

在代码中使用MetadataIndexNode类进行存储图中的数据，代表了当前节点属于管理设备的节点还是管理传感器的节点，是中间节点还是叶子节点。使用MetadataIndexEntry用来存储具体的信息，也就是TimeSeriesMetadata结构在硬盘上的偏移量或者子节点MetadataIndexNode在硬盘上的偏移量.

附上一个文件展示：


            POSITION|	CONTENT
            -------- 	-------
                   0|	[magic head] TsFile
                   6|	[version number] 000002
|||||||||||||||||||||	[Chunk Group] of root.sg1.d1, num of Chunks:10000
                  12|	[Chunk] of s8289, numOfPoints:500, time range:[0,499], tsDataType:INT64, 
                     	startTime: 0 endTime: 499 count: 500 [minValue:1,maxValue:1,firstValue:1,lastValue:1,sumValue:500.0]
                    |		1 pages
                    		 ...
              350026|	[Chunk] of s0, numOfPoints:500, time range:[0,499], tsDataType:INT64, 
                     	startTime: 0 endTime: 499 count: 500 [minValue:1,maxValue:1,firstValue:1,lastValue:1,sumValue:500.0]
                    |		1 pages
                    		 ...
             1418902|	[Chunk Group Footer]
                    |		[marker] 0
                    |		[deviceID] root.sg1.d1
                    |		[dataSize] 1418890
                    |		[num of chunks] 10000
|||||||||||||||||||||	[Chunk Group] of root.sg1.d1 ends
             1418947|	[marker] 2
             1418948|	[ChunkMetadataList] of root.sg1.d1.s0, tsDataType:INT64
                    |		 [ChunkMetaData] of s0, offset:350026
                    		 ...
             2247838|	[TimeseriesMetadata] name:s0, offset:1418948, chunkMetaDataListDataSize:80
             3116728|	[MetadataIndexNode] nodeType:LEAF_MEASUREMENT, childSize:10
                    |		[MetadataIndexEntry] name:s0, offset:2247838, endOffset:2336808
                    |		[MetadataIndexEntry] name:s192, offset:2336808, endOffset:2425782
                    |		[MetadataIndexEntry] name:s2841, offset:2425782, endOffset:2514757
                    |		[MetadataIndexEntry] name:s3763, offset:2514757, endOffset:2603732
                    |		[MetadataIndexEntry] name:s4685, offset:2603732, endOffset:2692705
                    |		[MetadataIndexEntry] name:s5606, offset:2692705, endOffset:2781680
                    |		[MetadataIndexEntry] name:s6528, offset:2781680, endOffset:2870655
                    |		[MetadataIndexEntry] name:s745, offset:2870655, endOffset:2959629
                    |		[MetadataIndexEntry] name:s8371, offset:2959629, endOffset:3048604
                    |		[MetadataIndexEntry] name:s9293, offset:3048604, endOffset:3116728
             3116906|	[TsFileMetadata] deviceNums:1,chunkNums:10000,invalidChunkNums:0
                    |		[MetadataIndexNode] nodeType:INTERNAL_MEASUREMENT,childSize:1
                    |			[MetadataIndexEntry] name:root.sg1.d1,offset:3116728,endOffset:3116906
                    |		[bloom filter bit vector byte array length] 7794
                    |		[bloom filter bit vector byte array] 
                    |		[bloom filter number of bits] 62353
                    |		[bloom filter number of hash functions] 5
             3124764|	[TsFileMetadataSize] 7858
             3124768|	[magic tail] TsFile
             3124774|	END of TsFile

---------------------------------- TsFile Sketch End ----------------------------------

到此已经介绍完了文件的整体结构，以及索引的改进过程。

那么一个sql是如何执行的呢，是怎样进行的查询？又是怎样高速的写入数据？

欢迎持续关注。。。。

加载全部内容