ArangoDB 中何时使用 RocksDB、何时使用 MMFiles 存储引擎？

问题描述 投票：0回答：1

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

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

  • 28 个包含文档的集合（最大的集合包含 3500K 文档，平均集合通常有 100K 到 1000K）
  • 3 个带边的集合（335K 边、3500K 边和 15000K 边）
  • 3 个图（每个图都链接到一个边集合，最大的图有 23 个来自/到集合）

完全加载时，整个数据集大约需要 28 GB RAM（包括索引）。

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

  • 我在here
    • 描述了前所未有的内存消耗
  • 重启速度非常慢（数据库再次完全响应需要 1 小时 30 分钟）
  • 事实上，我们必须使用非常昂贵的具有 64 GB RAM 的虚拟机才能将所有数据放入 RAM 中

经过一些研究，我们开始研究新的 RocksDB 存储引擎。我读过：

从文档和关于我关于 RAM 消耗问题的问题的建议答案我可以看到 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 单元。以下是我们测试的简短摘要（数字显示以 HH:mm:ss 格式执行特定 AQL 遍历查询所花费的时间）：

注意，在这个特定的表中，我们没有像我在原来的问题中提到的那样出现 10 倍的性能下降。当我们在 ArangoDB 重新启动后立即运行 AQL 时，最大速度会慢 6 倍（我认为这是可以的）。但是，大多数查询比 MMFile 慢 2 倍，即使在所有数据必须已缓存在 RAM 中的情况下第二次运行它也是如此。 Windows 上的情况更糟（在 Windows 上，我的性能下降了 10 倍甚至更多）。稍后我将发布我的 Windows PC 的详细规格以及性能测试。

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

arangodb rocksdb
1个回答
2
投票

在 Arangodb 3.7 中，对 MMFiles 的支持已被删除，因此这个问题可以通过“使用rocksdb”来回答。

我们花了一段时间才使 ArangoDB 中基于 RocksDB 的存储引擎变得成熟，但我们现在有信心它完全可以处理所有负载。

我们在本文中演示了如何使用 rocksdb 存储系统的各个部分以及它们的作用。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.