h2 - Ignite Query / SqlQuery / SqlFieldsQuery：“惰性”和“页面大小”实际上在做什么？

Question

一些背景知识：我们正在 Ignite 集群之外建立一个机器学习农场。部分用例是生成训练数据集，这些数据集是巨大的矩阵（理论上多达数十亿行 x 数千列），Ignite 缓存中每个数据条目一行。

我们SqlQuery用于在每个节点上本地获取与谓词匹配的记录，然后遍历记录，生成向量，将它们写入外部存储以供进一步使用。每个节点独立导出数据，因此对于 32 个节点，我们最终会导出 32 个数据集。

问题：小数据集生成工作正常，但更大的数据集生成（查询预计每个节点返回 10M+ 行）基本上杀死了整个集群，由于 OOME 和 GC 地狱而炸毁了节点。我们查看了 Ignite 文档 ( https://apacheignite-sql.readme.io/docs/performance-and-debugging#result-set-lazy-load ) 的“性能和调试”部分，尝试了惰性结果集和页面大小设置. 没有。

调查（分析、内存转储、调试器等）表明，在我们的代码读取第一行之前，查询的结果集已完全加载到内存中，即使我们正在使用QueryCursor和迭代。Query#pageSize和似乎对此SqlFieldsQuery#setLazy没有任何影响。深入挖掘，事实证明 H2（Ignite 索引正在使用）根本不支持结果集中的服务器端游标，并且只能配置为将记录缓冲到磁盘上（即使使用 SSD，这也是一种性能非起动机）。通读 Ignite 源代码建议Query#pageSize仅SqlFieldsQuery#setLazy在分布式查询/扫描查询中使用，并且 Ignite 仍然将节点上的结果集完全读取到内存中。

叹。这些是我们想到的补救措施：

• 从字面上看，运行数千个具有大量未使用内存的微型 Ignite 节点，而不是几十个大节点。看起来真的不划算。
• 使用h2.maxMemoryRows设置为一些小的值。似乎是一个愚蠢的解决方案（通过磁盘上的缓冲区在同一个 JVM 中的内存到内存？真的吗？）。
• 放弃SQLQuery/ SQLFieldsQuery，绕过 H2，使用ScanQuery. 这是大量的工作（必须解析谓词并将它们编译成IgniteBiPredicate，再加上这些是全表扫描，因此没有索引/优化，这种排序使整个考验变得毫无意义）。
• 说服Thomas Mueller以某种方式在 H2 中执行服务器端游标（请参阅 如何将 h2 设置为流式传输结果集？）？
• 在每个 ignite 节点上分配巨大的 ram 驱动器来缓冲 H2 记录集（好吧，这很奇怪，我可能会停下来）。

问题：我们的评估是否正确，查询结果流不是本地查询的事情？还有更明智的解决方法吗？

如果他们读到这篇文章，将感谢 Ignite 同志的一些见解。提前致谢！

更新：如果重要的话，集群是 8 个节点，如下所示：

Architecture: x86_64 CPU(s): 32 Model name: Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz CPU MHz: 2345.904 BogoMIPS: 4600.05 Hypervisor vendor: Xen Virtualization type: full RAM: 240Gb

这些被指定为具有用于 Ignite/data挂载的临时卷的 EC2-s。

标签： h2ignite

Answer 1

lazy确实可以做任何事情：对于SELECT * FROM cache查询，这是集群故障和正常运行之间的区别。page size应该与lazy.

你能显示你的查询吗？另外，我不确定它是否真的适用于本地查询。