1

我们正在使用带有实体管理器实现的 Hibernate 4.1.4，并且对它非常满意。当加载单个实体或一小组实体（10-50 + 子实体）时，我们获得了出色的性能，并且我们所有的连接都工作得很好并且是双向的。编辑/保存/删除轻而易举！

加载 2500 个实体和相关数据以进行报告

当我们尝试加载数百或数千个实体以及子实体时，我们遇到了问题。在一个示例中，我们有大约 2500 个基本实体以及两个一对一连接和三个一对多连接。这导致 2500 x 5 +1 查询。使用我们的数据库 (DB2) 执行大约需要 30 秒。

我们使用动态查询和实体管理器创建查询方法：

http://docs.jboss.org/hibernate/orm/4.1/javadocs/

http://docs.oracle.com/javaee/6/api/javax/persistence/EntityManager.html

试图哄骗 Hibernate 使用 Joins

我们的观察结果是，无论我们尝试什么，我们似乎都无法让休眠状态来执行大量子实体作为主查询的连接。当使用 find 方法和主键加载单个实体时，hibernate 使用连接，但当加载多个基本实体时，它不会。

我们已经尝试了具有相同结果的标准 api。

在查询中检索多个实体的一些成功

例子：

select a,b from table1 a left join table2 b

我们在查询中手动连接并通过元组检索单个实体已经取得了部分成功，但这绕过了我们的注释实体模型并且不是首选方法（如果我们可以避免的话）。

http://docs.jboss.org/hibernate/orm/4.1/manual/en-US/html_single/#objectstate-querying-executing

我们遇到的元组问题是它们与主实体分离（这似乎合乎逻辑，因为它们不是通过带注释的关系加载的）并且似乎没有办法重新附加它们。在手动添加实体列表中的所有一对多记录后，当 hibernate 命中列表的 get 方法时，它仍然尝试急切/延迟加载列表（尽管列表已经设置）。

尝试的优化 - 数据集的预加载

我们尝试的另一种优化技术是提前预加载数据集。在加载所有核心实体后，我们构建了一个 pk 列表并触发了一个查询以加载所有一对多数据集。但是当hibernate再次点击列表数据的getter时，它再次尝试急切/延迟加载列表，忽略会话中已经预加载的内容（可能需要启用缓存？）。

建议？

我们正朝着许多不同的方向前进，但收效甚微，希望有人能够为我们指明正确的道路（或指出一条新的道路！）！

4

1 回答 1

1

看来我自己也想通了！两种策略解决了这个问题：

  1. 查询中的 Join fetch 处理一对多的连接！当然你只能做一个 join fetch 因为 Hibernate 会抛出cannot 同时 fetch multiple bag异常。

    例子：

    LEFT OUTER JOIN FETCH t.table3 t3

  2. 对于其他连接 @Fetch(FetchMode.SUBSELECT) 成功了！

有效地将总查询从数千减少到几个。在一个示例中，选择了 188 个核心实体，总共执行了 12 个查询。额外的查询大多是一对一的查找，对总执行时间没有显着影响（平均 1-2 秒）。无论选择 188 条还是 1888 条记录，查询的总数都没有明显增加。

如果有人想了解更多信息，请随时与我联系或发表评论！:)

于 2012-07-15T20:34:03.083 回答