Page History

估算下一个rootFile可以索引多少个TsFileResource。

假设：

1个storage group，每个设备100个测点，每个storage group 51200个设备， 也就是5.12e6个测点

内存128GB

Tsfile 512MB

IndexFile是1GB

每条ResourceIndex 100B，一个IndexFile是1GB，可以记录1GB/100B=10240000条记录，也就是200个TsFileResource。

每个rootFile在一个IndexFile关闭时会记录一下，也是51200*100B=5.12MB

也就是200个TsFileResource会产1GB的IndexFile和5.12MB的rootFile

100T的磁盘空间，有100T/512MB=100000个TsFile，需要100000/200 * 1GB = 500GB IndexFile，100000/200*5.12MB= 2.56GB内存

假设一个storage group A个设备，一个设备D个测点， 总共就是A * D个测点

假设每次TsFile刷写会造成所有设备的索引更新，就会产生A * 100B 的IndexFile记录

一个IndexFile假设是 C GB, 那一个IndexFile能支持 C * 1000,000,000 / A * 100 = C * 10,000,000/A 个TsFile的刷写

IndexFile关闭时，也会在RootFile里记录下A * 100B的rootFile记录

也就是C * 10,000,000/A 个TsFile的刷写，会有C GB的IndexFile产生， 还有A * 100B的rootFile记录

假设整个数据库有S个 Storage group，那么常驻内存的就是 S * (rootfile + C GB)

A 平均一个storage group 设备数

D 平均一个设备测点数

C IndexFile文件大小，单位是GB

512MB TsFile大小

rootFile = C * 10,000,000/A * 100B

IndexFile= C GB

磁盘空间= C * 10,000,000/A * 512MB

测点=A * D

该估算有个问题就是对于TsFileName长度可以进行优化，可以只消耗Tsfile个数的TsFilename长度内存占用，而不是device * [starttime, endTime] * tsFile个数来估算，因此其内存占用估算放大了很多倍。

这个优化的前提是java的string 常量池，可以保证多个string公用一个字符串常量。

因此，限制一个StorageGroup的设备数是可以做到只使用(2.56GB+1GB)/128GB~ 3%的内存索引100TB的磁盘空间。