H2O.ai db-benchmark 更新！

Author Avatar
Tom Ebergen
2023-11-03 · 6 分钟

TL;DR: H2O.ai db-benchmark 已更新并包含了新的结果。此外，用于基准测试的 AWS EC2 实例已更改为 c6id.metal，以提高跨库的可重复性和公平性。在几乎所有数据大小下，DuckDB 都是连接（join）和分组（group by）查询速度最快的库。

直接跳到结果

基准测试已更新！

今年 4 月，DuckDB Labs 发布了一篇博客文章，报告了更新后的 H2O.ai db-benchmark 结果。自那时以来，结果一直没有更新。最初的计划是每次 DuckDB 发布时都更新结果。DuckDB 0.9.1 最近发布，DuckDB Labs 也更新了基准测试。然而，在更新基准测试时，我们注意到我们最初的设置不利于对所有解决方案都公平。使用的机器具有网络存储，并且可能会受到嘈杂邻居的影响。为了避免这些问题，整个基准测试在 c6id.metal 机器上重新运行。

新的基准测试环境：c6id.metal 实例

最初，将结果更新到基准测试显示出奇怪的结果。即使使用与之前更新相同的库版本，一些解决方案也会退步，而另一些则会改进。我们认为这种差异来自我们选择的 AWS EC2 实例类型：m4.10xlarge。m4.10xlarge 具有 40 个虚拟 CPU 和 EBS 存储。EBS 存储是 EC2 实例的高可用性网络块存储。在运行计算密集型基准测试时，像 m4.10xlarge 这样的机器可能会遇到以下问题

  • 网络存储 对于频繁与存储交互的基准测试解决方案来说是一个问题。对于 500 MB 和 5 GB 的工作负载，网络存储在 m4.10xlarge 上不是问题，因为所有解决方案都可以在内存中执行查询。然而，对于 50 GB 的工作负载，网络存储对于无法在内存中执行查询的解决方案来说是一个问题。虽然 m4.10xlarge 具有专用的 EBS 带宽，但从存储进行任何读/写仍然是通过网络发生的，这通常比物理安装的存储慢。对于 50 GB 查询频繁读写存储的解决方案最终会通过网络执行此操作。此网络时间成为查询执行时间的一部分。如果网络具有可变的性能，那么查询性能也会变化。

  • 嘈杂邻居 是在虚拟 CPU 上进行基准测试时的一个常见问题。之前的机器很可能与其他（相邻的）AWS EC2 实例共享其计算硬件。如果这些邻居也在运行计算密集型工作负载，则邻近实例和基准测试实例会重复使 CPU 缓存失效/刷新。当 CPU 缓存在两个实例上的两个工作负载之间共享时，两个工作负载都需要从内存中额外读取数据，而这些数据在非虚拟机上已经存在于 CPU 缓存中。

为了对所有解决方案都公平，我们决定将实例类型更改为具有本地存储的 metal 实例。Metal 实例类型消除了任何嘈杂邻居问题，因为硬件是物理的，并且不与其他任何 AWS 用户/实例共享。网络存储问题也得到了解决，因为解决方案可以读写数据到本地实例存储，该存储以物理方式安装在硬件上。

c6id.metal 盒子的另一个好处是它强调了并行性能。c6id.metal 上有 128 个内核。可以有效利用每个内核的解决方案和无法有效利用每个内核的解决方案之间的性能差异显而易见。

请参阅更新后的设置部分，了解在新机器上运行时，每个解决方案的设置是如何更改的。

更新基准测试

展望未来，当提供包含新性能数据的 PR 时，我们将更新基准测试。PR 应包含对解决方案脚本的更改或版本更新的描述，以及 time.csv 和 logs.csv 文件中的新条目。这些条目将使用不同的 c6id.metal 实例进行验证，如果差异有限，则 PR 将被合并，结果将被更新！

更新后的设置

  1. ClickHouse
    • 存储：任何溢出到磁盘的数据也需要位于 NVMe 驱动器上。这已在新的 format_and_mount.sh 脚本和 clickhouse/clickhouse-mount-config.xml 文件中进行了更改。
  2. Julia (juliadf & juliads)
    • 线程：线程已为 juliadf/juliads 硬编码为 20/40 个线程。现在使用了最大线程数。没有提供溢出到磁盘的选项，因此未更改/研究此项。
  3. DuckDB
    • 存储：DuckDB 数据库文件已指定在 NVMe 挂载点上运行。
  4. Spark
    • 存储：有一个溢出到磁盘的选项。我不确定如何修改存储位置，使其位于 NVMe 驱动器上。欢迎提供包含存储位置更改和改进结果的 PR！

许多解决方案不会溢出到磁盘，因此它们不需要任何修改即可使用实例存储。其他解决方案使用 parallel::ncores() 或默认为最大数量的内核以实现并行化。解决方案脚本以当前形式在 github.com/duckdblabs/db-benchmark 上运行。请阅读更新基准测试部分，了解如何重新运行您的解决方案。

结果

您看到的第一个结果是 50 GB 的 group by 结果。基准测试对每个解决方案运行两次查询，并报告两次运行时。“第一次”可以被认为是冷运行，“第二次”可以被认为是热运行。DuckDB 和 DuckDB-latest 在所有数据集大小和变体中都表现出色。

DuckDB Labs 的团队一直在努力改进核外哈希聚合和连接的性能。最显著的改进是高级 group by 查询中查询 5 的性能。冷运行几乎比其他所有解决方案好一个数量级！DuckDB 也是仅有的两个完成 50 GB 连接查询的解决方案之一。一些解决方案在 50 GB 数据集上遇到超时。运行 50 GB group by 查询的解决方案在运行 180 分钟后会被终止，这意味着所有 10 个 group by 查询需要在 180 分钟内完成。运行 50 GB 连接查询的解决方案在运行 360 分钟后会被终止。

链接到结果页面

本文中