【发布时间】：2019-02-10 23:10:36
【问题描述】：
我们使用 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 秒，即使您多次运行相同的查询（即数据必须已经兑现）。
2019 年 2 月 15 日更新：
我们在 AWS 上的 m4.4xlarge 实例上的 docker 容器内运行 ArangoDB，具有 16 个 vCPU 和 64 GB 的 RAM。我们为 ArangoDB 容器分配了 32 GB 的 RAM 和 6144 个 CPU 单元。以下是我们测试的简短摘要（数字显示执行特定 AQL 遍历查询所需的时间，格式为 HH:mm:ss）：
注意，在这个特定的表格中，我们没有像我在原始问题中提到的那样，性能下降 10 倍。当我们在 ArangoDB 重新启动后立即运行 AQL 时，最大值会慢 6 倍（我猜这没问题）。但是，与 MMFiles 相比，大多数查询的速度要慢 2 倍，即使在所有数据必须已经缓存在 RAM 中的情况下再次运行它也是如此。 Windows 上的情况更糟（在那里我的性能下降了 10 倍甚至更多）。稍后我将发布我的 Windows PC 的详细规格以及性能测试。
我的问题是： RocksDB 引擎的 AQL 遍历速度会慢得多，这是一种预期行为吗？关于何时使用 MMFiles 引擎以及何时使用 RocksDB 引擎以及在哪些情况下不可以选择 RocksDB，是否有任何一般性建议？
【问题讨论】：
-
你在什么硬件上测试了 RocksDB？它与您当前使用的 MMFiles 引擎相同吗？和同样的工作量？如果不是，请添加有关规格的详细信息以及您的 arangod 配置（如果不是默认配置）。
-
请参阅我的 2019 年 2 月 15 日更新。稍后，我还将发布一些基于开发 Windows 的 PC 的其他性能测量结果。
-
我无法为您解答，但与使用 MMFiles 相比，使用 RocksDB 时我们看到了类似的性能下降。我真的很想切换到 RocksDB，但性能似乎令人望而却步。对我们来说，最大的问题似乎是使批量加载成为问题的写入放大。我没有对查询性能进行详细测量，但有趣的是，它在 RocksDB 上似乎更慢。