H2 & Ignite 查询性能

Question

我正在尝试将 H2 数据库和 Ignite 上的应用程序查询性能与 Oracle 基线进行比较。

我创建了一个测试，包括：

• 一组表和索引。
• 随机生成数据的数据集，每个表有 50k 条记录。
• 具有 1 个 INNER 和 10 个 LEFT OUTER 联接的查询（查询返回大约 188k 条记录）。

我注意到性能方​​面存在显着差异。

在我的机器上运行查询（i5 双核，16Gb RAM）：

• Oracle 设法在大约 350 毫秒内运行此查询。
• H2 需要 4.5 秒（无论模式如何 - 服务器和内存）。
• 点燃需要 9 秒。

遍历 JDBC 结果集：

• H2 内存模式少于 50 毫秒
• H2 服务器模式大约需要 2 秒
• Oracle 大约 5 秒
• Ignite 大约 1 秒

几个问题：

• 这些数字有意义吗？我是不是错过了 H2 查询优化的基础知识？
• 看H2解释计划，scanCount的确切含义是什么？对于给定的查询和数据集或性能指标，这是不变的吗？
• 有没有办法通过调整索引或提示查询来提高 H2 性能？
• 如何解释 Ignite 和 H2 之间的区别？
• 连接的顺序重要吗？询问是因为在 Oracle 上，拥有最新的统计信息，CBO 会更改连接的顺序。我没有注意到 H2 的这种行为。

我用于此测试的查询和数据在 Github 上的 here 可用。

谢谢， L.

Answer 1

让我分享一些与 Ignite 与 RDBMS 性能基准测试相关的基本事实。从本月发布的新 GridGain 文档中复制粘贴此内容。只需将出现的 GridGain 替换为 Ignite。请仔细检查是否遵循这些原则。如果您没有发现差异，请告诉我。

GridGain 和 Ignite 的 SQL 功能经常与关系数据库进行比较，他们期望为 RDBMS 创建的现有 SQL 查询将开箱即用，并且在 GridGain 中执行得更快，无需任何更改。通常，这种错误假设是基于 GridGain 在内存中存储和处理数据的事实。然而，仅仅将数据放入 RAM 并期望性能提升一个数量级是不够的。 GridGain 作为一个分布式平台，为了提高性能需要进行额外的更改，您可以在下面看到一个标准的最佳实践清单，在您将 GridGain 与 RDBMS 进行基准测试或进行任何性能测试之前：

• Ignite/GridGain 针对 RAM 作为多节点部署进行了优化 一个主存储。不要试图比较单节点 GridGain 集群到针对此类优化的关系数据库 单节点配置。您应该部署一个多节点 GridGain 使用 RAM 中的整个数据副本进行集群。

• 准备好调整您的数据模型和现有的 SQL 查询（如果有）。 在数据建模阶段使用亲和搭配概念 为适当的数据分布。请记住，仅仅放置是不够的 RAM 中的数据。如果您的数据配置正确，您可以运行 SQL 大规模 JOIN 查询并期望显着 性能优势。

• 定义二级索引并使用其他标准，以及 GridGain 特定的调优技术如下所述。

• 请记住，关系数据库利用本地缓存 技术，并且根据总数据大小，RDBMS 可以 即使在多节点中，也可以比 GridGain 更快地完成一些查询 配置。如果您的数据集大约 10-100GB 并且 RDBMS 有 例如，足够的 RAM 用于在本地缓存数据 优于多节点 GridGain 集群，因为后者将 利用网络。在 GridGain 中存储更多数据以查看 区别。