从我之前的问题：Data structure for storing huge number of indices, each pointing to a set，我得到了关于反转索引实现的合适数据结构的答案。但问题是，我们可能很快就会在我们的Linux服务器上达到我们的128 GB RAM限制，所以我想为它做好准备，以防我们再次耗尽内存。
目前，我们在转换索引中的索引总数高达39亿，占用了大约50 GB的RAM。请注意，虽然有些人可能建议使用数据库系统等，但这是用于实验研究，我们希望管理自己的数据，我们不会使用任何类型的数据库系统。
我也被指向When should I use mmap for file access?虽然看起来很有希望，但我用Google搜索，看到我需要首先为mmap分配一个固定的空间，然后开始放入数据。但是，我的第一个问题（1）因为我们有更大的数据，我知道我的反转索引会更大，但在构建它之前我不知道确切的数字。 （在将这些数据推入反转索引之前，需要首先处理一些数据）我可以为它分配大量的内存，但是，嘿，我们已经只有当前的反向索引得到50 GB的RAM。这导致第二个问题（2），我们的服务器有很多人使用，并且有50 GB或更多的空间，我们的数据将在硬盘中四处碎片化。
或者，如果我使用文件I / O来管理它并使B-Tree像分层目录一样怎么办？事情可能变得丑陋......
所以这一次，我想问一些建议，就像我上面的上一个问题一样，但这一次，我需要在RAM和硬盘之间交换一些数据，我们的128 GB RAM可能不会这样。
答案 0 :(得分：1)
如果可能，我会向系统添加更多交换空间并让内核负责交换。
如果不可能，我会考虑按索引键将数据聚集在块中，而不是在访问时压缩/解压缩内存中的块，或者将它们交换到磁盘。