为什么磁盘上的orientdb索引大小如此之大

orientdb 2.0.5

我有一个数据库，在这个数据库中，我们在一个名为indexstat的类上的2个属性上创建非unque索引

构成索引的两个属性是字符串标识符加上长时间戳

数据每5分钟以数百条记录为一批创建。几个小时后，旧记录被删除

这是与该表相关的文件列表

问题: 为什么根据文档（与非唯一索引相关）显示的.irs文件在几个小时后变得如此巨大。比实际数据大298056704字节（.irs大小-.sbt大小-.cpm大小）

我认为该指数将小于实际数据

第二个问题： 这里的最佳实践是什么。我应该使用唯一索引而不是非唯一索引吗？我是否应该找到一种方法使索引中的数据更小（例如，使用long而不是字符串作为标识符）

下面是文件名和每个文件的大小

indexstat.cpm 727778304
indexstatidx.irs 1799095296 
indexstatidx.sbt 263168 
indexstat.pcl 773260288 

对于索引大小大于数据库数据的一些表，重复此操作。

此处显示了与索引文件相关的讨论，可能会对您有所帮助

---

对于第二个问题，应根据您的目的和数据选择索引（反之亦然）。数据类型（long，string）必须是最能代表字段的数据类型（这里已经有了，例如，如果您只需要一个整数，这就足够了，那么使用long是没有用的）。索引的相同选项，如果不需要重复，则该选项将是非唯一的。如果您需要一个允许选择范围sb树而不是散列等的索引…

以这样的方式组织的*.irs文件的内部，当您从索引中删除某个内容时，文件中会留下一个未使用的漏洞。在某种程度上，当大约一半的文件空间被浪费时，这些未使用的漏洞再次发挥作用，并可供重用和分配。这样做是出于性能原因，以降低索引数据碎片。在您的情况下，这意味着*.irs文件迟早会停止增长，并且它的最大大小应该比相应的*.pcl文件的最大观察大小大2-3倍左右，假设您的单个统计记录大小与id时间戳对大小相比不会大很多

关于第二个问题，从长远来看，使用最具体/严格的数据类型对数据进行建模和使用最具体/严格的索引类型对其进行索引几乎总是更好的