好的，所以到目前为止我一直在主内存中开发一个系统，它有许多不同的对象，每个对象都存储系统中其他对象的列表。现在我想把它转移到持久存储。我不是在寻找使用DBMS的明显答案，因为关键是我正在为我的系统编写自定义数据库。
现在我为每个对象分配一个ID。可以在表中查找id以查找该对象的数据位置的块和偏移量。现在，每个对象都有指向系统中其他对象的列表/集。所以很明显在存储中它们将是8字节的列表（使用id的长数）id，可用于查找其他对象。现在我的问题是，我知道这些名单会随着时间的推移而增长，因此他们需要增长的空间。到目前为止，我最好的想法是存储列表以便我不需要在对象生长时移动它们，就是让每个列表都像对象一样分配一个id，这样它们就可以像对象一样在表中查找在磁盘上找到它们。
现在每个列表部分将有一个用于存储10个对象的集合分配空间，如果它包含更多对象，则最后将是下一个列表部分的id。这似乎是一种体面的方式来处理不断增长的对象，但我想知道是否有更好的方法。我将索引存储在内存中（空间允许），因此给定一个对象id，查找在内存中然后需要1个I / O才能从磁盘中找到它的数据和列表ID。然后，对于要遍历的每个列表，如果块被缓存，则对列表中的每10个对象进行另一次查找和I / O操作。
I / O的数量并不可怕，我会尝试保留列表部分的位置以消除不必要的I / O，但是有更好的方法吗？我是否正确尝试将列表与对象分开存储，或者我应该考虑使用对象的数据存储它们的方法。我担心这样做是因为随着一个列表的增长，它将进入另一个列表，然后需要进行分段，这会变得更加复杂。任何建议都表示赞赏，并提前感谢。
答案 0 :(得分：1)
您对这些可扩展列表的想法很好。我认为你的解释缺少一些细节（即：有序列表与否，你试图将列表与对象分开是什么意思，这些列表的图表可能有帮助。）
我会在内存中保留一个排序索引以便快速访问。索引将具有列表ID和磁盘上的位置。如果您对范围查询感兴趣，请使用B树方法，否则您可以使用哈希值来存储这些权限。
如果您正在对列表进行搜索，那么进一步的改进是将它们排序......或者至少进行半排序，以便您可以在同一块中对相似的列表进行分组。如果你经常缓存到内存中的每个块的边界（具有值为b / w 1-9,10-25等的节点），这将加速在列表中的搜索。合并排序可能是列表的最佳排序。或者更好的是，当您在列表中插入节点时，插入正确的位置，以便始终对列表进行排序。然后查找二进制搜索。如果数据未正确编入索引且未进行排序，则您将多次查询磁盘以进行查询，在这种情况下，由于磁盘时间的原因，您使用的任何搜索都将为您提供线性时间。
您还可以缓存10％最多查找节点/列表的数据节点。
根据这些列表的大小（以及它们有多少块），您可以使用一些RAID，这样您就可以获得一些并行读/写。