我在缩放使用视图的基于H2的Java应用程序时遇到问题

Question

在此环境中：我们为基于嵌入式h2数据库的客户编写了一个应用程序，在进行测试之前已将其升级到最新版本。 该数据库包含29个表和26个视图。 在26个视图中，只有8个确实是在Java中“使用”的，映射视图休眠成pojos。 其他视图仅对其他视图进行背景计算，例如聚合一些值然后按某个列分组。 这些视图中进行了大量计算。 我们决定不使用Java计算，因为您可以使用自己喜欢的工具（例如h2控制台）轻松检查数据库表，以查看计算中是否有任何错误。 由于这个事实，在这些视图中有很多“ CASE WHEN ... END”语句，因为一旦该行中的单个列为NULL，hibernate便始终在所有列中返回整行并带有NULL值。 我们也从来没有能够解决这个问题。但是，由于我们在计算中也存在除法的事实，无论如何我们都需要检查NULL，0和0.0。 由于某些中间值有时在其他地方使用，因此视图被“堆叠”。 但是一个最终视图的下方总是有7个视图的“堆栈”，该最终视图也基于使用6个视图的“堆栈”的另一个视图。 有些观点是相同的，有些则不同。

现在，问题来了：当在“有趣的”表中向数据库中插入几条记录（例如20条记录）时，一个视图将以大约4倍的速度传送数据（4行聚合）。 400毫秒。 对我们来说没关系。 将数据放大到大约500-2000条记录，即特殊视图（传递大约25个聚合行）需要一个小时（1h）才能传递数据。 该计算机是具有8GBytes RAM（-Xmx2G和-Xms1G），CPU 2.66GHz（Intel（R）CoreTM 2 Quad CPU Q8400 @ 2.66GHz）的Linux或具有4GBytes RAM（-Xmx1G- Xms512m）CPU未知，但可能是2GHz的单/双核。

到目前为止，我的分析是：我跟踪了应用程序的内存使用情况，这似乎不是主要问题。 在长时间运行的查询中查看堆栈跟踪显示，我的堆栈深度有时低于（！）多达100层（！），这是进入休眠状态的入口getEntityManager（）。createQuery（getCriteriaQuery（））。getResultList（）。 明显的“时间消耗”是org.h2.table.TableFilter / Table / TableView.getBestPlanItem和org.h2.table.Plan.calculateCost以及org.h2.index.ViewIndex.getCost。 我检查了所有视图中的所有联接以查找缺少的索引，发现一个索引，添加该索引，但没有成功。

我的测试：我将所有数据和模式转移到同一台Linux机器上的PostgreSQL（8.1）中（未进行任何调整），并在那里进行了测试（在进行任何真空或重新索引之前！），结果令人不知所措：大约。 6秒 对于具有相同数据的相同视图，在h2上花费了大约1h。

现在我真的不想切换数据库，但这将是最终的选择，除非任何人都有一个好主意...

备注：关于我发现的事情如下：当检查h2的information_schema中的视图时，我可以看到他正在做很多工作来分析视图本身。 我的sql脚本中的所有视图都在20到120行之间（大约）。 信息架构中的“已编译”视图范围从2 KB到3 MB（即兆字节），从上方的视图接近40万……也许这也是问题的一部分……

好，那是所有人。 我很乐意提供任何帮助。 我愿意切换数据库，因为我们在各处都使用了hibernate和CriteriaQuery，因此唯一的工作就是切换jdbc连接器，更改视图中的某些代码（已经完成，但是在生产之前必须检查两次）并安装客户台式机（irk）上的PostgreSQL或MSDE可能会导致其他不必要的错误，这些错误可能由于MS Update可能导致MSDE损坏或由于任何原因而无法启动数据库而发生...

问候，霍尔格

Answer 1

也许查询/视图对于H2来说过于复杂以至于无法优化它们，但是如果不知道细节（重现问题的代码）就很难说。 PostgreSQL的优化器比H2优化器好。 可能您需要创建其他索引。 为了对此进行分析，建议阅读有关性能优化和索引的文档。