Page History

...

传感器数	设备数	Hash 结构						B+ 树						时间差
传感器数	设备数	64	128	256	512	1024	最优配置耗时	64	128	256	512	1024	最优配置耗时	时间差
10	1	0.8	1.43	1.61	2.09	1.24	0.8	1.12	2.73	2.27	1.74	2	1.12	-40.00%
10	1000	13.01	12.4	14.41	13.81	13.1	12.4	6.15	7.41	7.78	7.05	7.85	6.15	50.40%
10	10000	36.18	37.32	37.71	32.97	33.8	32.97	15.81	19.44	14.97	15.4	17.16	14.97	54.60%
10	100000	44.8	34.1	42.8	37.6	36.5	34.1	43.6	46.7	43	40.4	44.3	40.4	-18.48%
10	1000000	131	108	139	117	116	108	173	153	176	206	162	153	-41.67%
500	1	4.01	3.92	4.31	4.44	4.69	3.92	3.38	3.77	3.19	2.72	2.93	2.72	30.61%
500	1000	37.2	28.8	31.4	36.5	33	28.8	26.3	25.7	24.7	20.3	19.4	19.4	32.64%
500	10000	93	78	82.5	77	70	70	98	88	112	89	87.5	87.5	-25.00%
500	20000	165	126	140	170	137	126	155	148	125	131	131	125	0.79%
100,000	1	35.76	35.09	38.2	33.65	33.44	33.44	13.17	13.01	14.93	10.61	14.31	10.61	68.27%
100,000	100	139	162	173	189	158	139	275	240	149	231	174	149	-7.19%

如图所示：

Image Modified

从查询速度来看，Hash结构的索引在时间序列条数较大的情况下表现较好（超过5000,000条）。这是因为Hash结构的索引在查询过程中，仅需要两次 I/O（第一次获得 buckets 的个数和大小，第二次反序列化对应的 buckets）；而 B+ 树索引在时间序列条数较小时，可能仅需要一次 I/O，即使需要两次 I/O，其反序列化大小可能也会小于 bucket 的大小。因此，B+ 树索引在大多数场景下，无论是原始数据查询速度还是聚合查询的速度，都会有优势。

Image Modified

从索引文件大小来看，Hash结构的索引区大小远大于B+树索引区文件大小和泽嵩树索引区文件大小。随着传感器数量的增多，此比例会越来越大，如在100000传感器的场景下，索引区文件大小比例可能达到 43:1。

以10传感器-1000设备场景为例，在配置项为1024的情况下：

Hash结构中，需要在索引区存储所有的时间序列名称。每一个 bucket 大小为29140，共有10个bucket（10 × 1000 ÷ 1024向上取整为10），总计约为284.57KB。算上BoomFilter后约为292.2KB。

B+树结构中，由于在叶子节点层就开始做稀疏索引，因此索引区所存储的时间序列并不是全部的时间序列。在这个场景中，由于每个设备有10传感器，因此存储的时间序列数是全部时间序列数的1/10。索引区大小总结约34.89KB。

Hash结构的索引区大小约为B+树结构索引区大小的8.38倍。不算BloomFilter，Hash结构的索引区大小约为B+树结构索引区大小的10.44倍（每一个entry多记录了一个VARINT类型的size）。

Space shortcuts

Page tree

Versions Compared

Old Version 12

New Version Current

Key