arangodb - 什么时候用 RocksDB，什么时候用 ArangoDB 中的 MMFiles 存储引擎？

Question

我们使用 ArangoDB 来存储电信数据。我们应用程序的主要目标是让用户非常快速地构建某种类型的报告。报告主要基于我们遍历不同图形时从 ArangoDB 获得的数据。报告的业务逻辑并不简单，这导致具有多个嵌套遍历(子查询)的非常复杂的 AQL 查询。

我们存储在 ArangoDB 中的数据的快速概览:

28 个带文档的集合 (最大的集合包含 3500K 个文档，平均集合通常从 100K 到 1000K)

3 个带边缘的集合 (335K 边、3500K 边和 15000K 边)

3图 (每个图都链接到一个边集合，最大的图有 23 个 from/to 集合)

整个数据集在完全加载(包括索引)时需要大约 28 GB 的 RAM。

我们已经使用 MMFiles 将近两年了，对结果非常满意，除了一些问题:

我描述的前所未有的内存消耗 here

非常缓慢的重启(在数据库再次完全响应之前需要 1 小时 30 分钟)

事实上，我们必须使用具有 64 GB RAM 的非常昂贵的 VM 才能将所有数据放入 RAM

经过一番研究，我们开始研究新的 RocksDB 存储引擎。我读过了:

https://www.arangodb.com/why-arangodb/rocksdb-storage-engine/

https://docs.arangodb.com/3.4/Manual/Architecture/StorageEngines.html

来自文档和来自 proposed answers on my question about the problem with RAM consumption我可以看到 RocksDB 对我们来说应该是一条路。所有的文件都说它是 ArangoDB 的新默认引擎，如果你想存储比 RAM 多的数据，应该使用它。

我安装了新的 ArangoDB 3.4.1 并将我们的数据库从 MMFiles 转换为 RocksDB(通过 arangodumpa 和 arangorestore)。然后我运行了一些性能测试，发现与我们使用 MMFiles 引擎相比，所有遍历都慢了 2-6 倍。一些使用 MMFiles 引擎需要 20 秒的查询现在使用 RocksDB 需要 40 秒，即使您多次运行相同的查询(即数据必须已经兑现)。

2019 年 2 月 15 日更新:

我们在 上的 docker 容器内运行 ArangoDB m4.4xlarge AWS 上的实例，使用 16 个 vCPU 和 64 GB 内存 .我们为 ArangoDB 容器分配了 32 GB 的 RAM 和 6144 个 CPU 单元。以下是我们测试的简短摘要(数字显示以 HH:mm:ss 格式执行特定 AQL 遍历查询所需的时间):



备注 ，在这个特定的表中，我们没有像我在最初的问题中提到的那样性能下降 10 倍。当我们在 ArangoDB 重新启动后立即运行 AQL 时，最大值会慢 6 倍(我猜这没问题)。但是，即使在所有数据必须已经缓存在 RAM 中的情况下第二次运行它时，大多数查询也比 MMFiles 慢 2 倍。 Windows 上的情况更糟(在那里我的性能下降了 10 倍甚至更多)。稍后我将发布带有性能测试的 Windows PC 的详细规范。

我的问题是: RocksDB 引擎的 AQL 遍历速度慢得多是预期的行为吗？关于何时使用 MMFiles 引擎以及何时使用 RocksDB 引擎以及在哪些情况下不可以选择 RocksDB，是否有任何一般建议？

Answer 1

随着 Arangodb 3.7 对 MMFiles 的支持已被删除，因此这个问题可以用“使用rocksdb”来回答。
我们花了一段时间才使 ArangoDB 中基于 RocksDB 的存储引擎成熟，但现在我们有信心它完全可以处理所有负载。
我们演示了如何使用 parts of the rocksdb storage system and which effects they have in this article .