似乎在 MongoDB 中，当您从文档中请求单个键值对时，the entire document needs to be loaded into the memory。
我想知道 ArangoDB 是否也是这种情况。
这似乎是 MongoDB 的一个基本限制，因为文档的底层格式是 BSON，它是为遍历而设计的，而不是随机访问。另一方面，ArangoDB 似乎使用具有小索引表的 VPack 来执行随机访问。因此，除非查询的文档嵌套得非常荒谬或小于操作系统页面大小，否则我希望只有包含给定键值对的页面才会加载到内存中。我说的对吗？
我问的原因是因为我正在设计一个数据库来存储大量数字实验的结果。一项实验可以（很少）产生高达 1GB 的数据。我想为每个实验保留一份文件。但是，如果我有 100 个这样的实验，并且我只想从每个实验中检索一个键值对，我的机器是否需要将 100GB 加载到内存中？
【问题讨论】：
标签： arangodb
使用 MMFiles 存储引擎，当集合加载时，所有文档都会加载到内存中。索引每次都需要重建，因为它们没有持久化。文档数据同步到磁盘。总的来说，它是一种主要使用内存的方法。
使用 RocksDB 存储引擎，文档和索引可以持久化，无需将集合全部或部分加载到内存中。相反，有一个常用文档的热集。里面没有的可以从磁盘加载。与 MMFiles 引擎不同，整个文档数据可以比主内存大几倍。
通常，查询中涉及的文档会通过 RocksDB 引擎作为一个整体加载到内存中。但是，如果您只要求 FOR doc IN coll RETURN doc.title 之类的内容，则可以优化提取单个属性：
Optimization rules applied:
Id RuleName
1 reduce-extraction-to-projection
这将soon be extended 最多添加到 v3.3 及更高版本中的 5 个属性。
另一个优化将允许仅在请求的属性被索引时才从索引中回答查询，这消除了将文档从磁盘加载到内存中的必要性。
其中一些可能有助于您的用例的性能。但是，您不应该存储 1 GB 的大文档，还有一个原因：两个引擎都是仅附加的。任何修改都将导致新的文档修订。复制 1 GB 的文档数据来更新单个属性不会是高效的。如果您不打算更改它们，那么这可能不是问题。
【讨论】：