Hibernate：批量获取的意外获取顺序
我正在使用 hibernate 的批量获取来提高查询性能。在我的 persistence.xml 中，我添加了以下设置：
<property name="hibernate.default_batch_fetch_size" value="50"/>
我有一个实体 A，它与实体 B 具有 1:n 关系。该关系的数据是延迟获取的。现在我遇到了以下情况：
- 我从数据库加载 10000 个类型 A 的实体
- 我迭代这些实体并通过调用 a.getBs().size() 初始化惰性关系
- 当这样做时，hibernate 不仅初始化对的依赖关系当前实体，但另外还加载列表中 49 个其他实体的依赖关系。此行为是预期的。
生成的 SQL 看起来与此类似：
select
b0_.SOMETHING as SOMETHING1_1_,
...
from
XYZ.B b0_
where
b0_.A_ID in (
?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ...
)
我真正的问题是 hibernate 没有按预期顺序加载结果列表的实体。当我访问列表中的第一个条目时，它不会加载实体 2-50 的数据，但会加载列表中 49 个随机条目的数据。 （例如，它可以初始化实体3、7、100、2001、...的数据）。这种行为很奇怪，我想知道如何更改它以按预期顺序加载数据。
当前的问题，与所描述的行为相关。
- 内存使用情况。在迭代列表时，休眠会初始化大量数据，稍后将需要这些数据。除了上面的算法之外，我还添加了一些代码，这些代码从列表中删除已处理的记录并调用 session.evict(entity) ，以使实体符合垃圾回收的条件。这当然现在行不通了。
- 在迭代开始时查询速度非常慢，因为 Hibernate 正在查询数据库以获取几乎每个已处理的实体。当我将实体写入 Web 应用程序的流以便在处理时下载时，这会导致问题。因此，一开始下载速度非常慢，当更多实体加载到内存并且需要更少的数据库调用时，下载速度会加快。
非常感谢您的帮助和最诚挚的问候
托马斯
I'm using hibernate's batch fetching to improve query performance. In my persistence.xml I've added the following setting:
<property name="hibernate.default_batch_fetch_size" value="50"/>
I've got an entity A, which has a 1:n relation to an entity B. The data for this relation is fetched lazily. Now I've got the following situation:
- I load 10000 entities of type A from DB
- I iterate over those entities and initialize the lazy relation by calling a.getBs().size()
- When doing so hibernate does not only initialize the dependency for the current entity, but in addition loads the dependency for 49 additional entities from the list. This behaviour is expected.
The generated SQL looks similar to this:
select
b0_.SOMETHING as SOMETHING1_1_,
...
from
XYZ.B b0_
where
b0_.A_ID in (
?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ...
)
My real problem is that hibernate is not loading the entities of the result list in the expected order. When I access the first entry from the list, it doesn't load data for entities 2-50, but it loads data for 49 random entries from the list. (e.g. it may initialize the data of entities 3, 7, 100, 2001, ...). This behaviour is quite strange and I'm wondering how to change it to load data in the expected order.
Current problems, that are related to the described behaviour.
- Memory usage. While iterating over the list hibernate is initializing a lot of data, which will be required MUCH later. In addition to the algorithm from above I've added some code, which removes processed records from the list and calls session.evict(entity), to make the entity eligible for garbage collection. This is of course not working out now.
- Query speed is very slow at the beginning of the iteration as hibernate is querying the db for nearly every processed entity. This causes problems as I'm writing the entities to a web application's stream for downloading while processing. As a result the download speed is very slow in the beginning and speeds up when more entities have been loaded to memory and less db calls are required.
Thanks a lot for your help and best regards
Thomas
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当您说 Hibernate 没有按预期顺序加载实体时，您是否告诉过它预期的顺序是什么？也就是说，
B的映射是否包含order-by属性？如果不是，那么它们在 Hibernate 数据模型中没有顺序，可以按任何顺序加载（可能是数据库默认顺序）。否则，我的理解是 Hibernate 在查找要加载的 pkey 时应该应用 order-by 约束。因此，将其作为潜在错误放在邮件列表中可能是值得的。
When you say that Hibernate is not loading the entities in the expected order, have you told it what the expected order is? That is, does the mapping for the
Bs contain anorder-byattribute? If not, then they have no order in the Hibernate data model and can be loaded in any order (likely the database default).Otherwise, my understanding is that Hibernate should apply the order-by constraint when looking up the pkeys to load. Hence it might be worth taking this up on the mailing lists as a potential bug.