何时使用RocksDB以及何时使用ArangoDB中的MMFiles存储引擎？

Question

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

我们存储在ArangoDB中的数据的快速概述：

• 28个包含文档的集合（最大的集合包含3500K文档，平均集合通常为100K至1000K）
• 3个具有边的集合（335K边，3500K边和15000K边）
• 3个图（每个图链接到一个边缘集合，最大的图有23个从/到集合）

完全加载（包括索引）后，整个数据集大约需要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秒，即使您多次运行相同的查询（即数据必须已经兑现）。

更新2/15/2019：

我们在具有 16个vCPU 和 64 GB RAM 的AWS上的 m4.4xlarge 实例上的docker容器中运行ArangoDB。我们为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。