JPA：对大型结果集进行迭代的正确模式是什么？

假设我有一个包含数百万行的表。使用JPA，迭代对该表的查询的正确方法是什么，这样我就不会拥有一个包含数百万个对象的内存列表？

例如，如果表很大，我怀疑以下内容会爆炸：

List<Model> models = entityManager().createQuery("from Model m", Model.class).getResultList();

for (Model model : models)
{
     System.out.println(model.getId());
}

分页（循环和手动更新setFirstResult()/ setMaxResult()）真的是最好的解决方案吗？

编辑：我针对的主要用例是一种批处理作业。如果需要很长时间才能运行就可以了。没有涉及Web客户端。我只需要为每一行“做某事”，一次一行（或一些小N）。我只是想避免将它们全部同时存储在内存中。

Java Persistence with Hibernate的第537页提供了一个使用的解决方案ScrollableResults，但可惜它仅适用于Hibernate。

因此，似乎确实需要使用setFirstResult/ setMaxResults和手动迭代。这是我使用JPA的解决方案：

private List<Model> getAllModelsIterable(int offset, int max)
{
    return entityManager.createQuery("from Model m", Model.class).setFirstResult(offset).setMaxResults(max).getResultList();
}

然后，像这样使用它：

private void iterateAll()
{
    int offset = 0;

    List<Model> models;
    while ((models = Model.getAllModelsIterable(offset, 100)).size() > 0)
    {
        entityManager.getTransaction().begin();
        for (Model model : models)
        {
            log.info("do something with model: " + model.getId());
        }

        entityManager.flush();
        entityManager.clear();
        em.getTransaction().commit();
        offset += models.size();
    }
}

我尝试了这里给出的答案，但是JBoss 5.1 + MySQL Connector / J 5.1.15 + Hibernate 3.3.2不适用于这些。我们刚刚从JBoss 4.x迁移到JBoss 5.1，因此我们暂时坚持使用它，因此我们可以使用的最新Hibernate是3.3.2。

添加几个额外的参数可以完成这项工作，并且这样的代码可以在没有OOMEs的情况下运行：

        StatelessSession session = ((Session) entityManager.getDelegate()).getSessionFactory().openStatelessSession();

        Query query = session
                .createQuery("SELECT a FROM Address a WHERE .... ORDER BY a.id");
        query.setFetchSize(Integer.valueOf(1000));
        query.setReadOnly(true);
        query.setLockMode("a", LockMode.NONE);
        ScrollableResults results = query.scroll(ScrollMode.FORWARD_ONLY);
        while (results.next()) {
            Address addr = (Address) results.get(0);
            // Do stuff
        }
        results.close();
        session.close();

关键行是createQuery和scroll之间的查询参数。没有它们，“ scroll”调用将尝试将所有内容加载到内存中，并且永远不会完成或运行到OutOfMemoryError。

您实际上不能在直接JPA中执行此操作，但是Hibernate支持无状态会话和可滚动结果集。

在它的帮助下，我们通常会处理数十亿行。

这是文档的链接：http : //docs.jboss.org/hibernate/core/3.3/reference/en/html/batch.html#batch-statelesssession

老实说，我建议您离开JPA并坚持使用JDBC（但一定要使用JdbcTemplate支持类或类似的东西）。JPA（以及其他ORM提供程序/规范）并非旨在对一个事务中的许多对象进行操作，因为它们假定加载的所有内容都应保留在一级缓存中（因此需要clear()JPA）。

我也建议使用更底层的解决方案，因为ORM的开销（反射只是冰山的一角）可能会非常大，以至于遍历纯文本ResultSet，甚至使用上述的轻量级支持JdbcTemplate也会更快。

JPA根本不旨在对大量实体执行操作。您可能会使用flush()/ clear()来回避OutOfMemoryError，但请再次考虑。您付出巨额资源消耗的代价却很少。

如果您使用EclipseLink，则使用此方法将结果作为Iterable

private static <T> Iterable<T> getResult(TypedQuery<T> query)
{
  //eclipseLink
  if(query instanceof JpaQuery) {
    JpaQuery<T> jQuery = (JpaQuery<T>) query;
    jQuery.setHint(QueryHints.RESULT_SET_TYPE, ResultSetType.ForwardOnly)
       .setHint(QueryHints.SCROLLABLE_CURSOR, true);

    final Cursor cursor = jQuery.getResultCursor();
    return new Iterable<T>()
    {     
      @SuppressWarnings("unchecked")
      @Override
      public Iterator<T> iterator()
      {
        return cursor;
      }
    }; 
   }
  return query.getResultList();  
}  

关闭方法

static void closeCursor(Iterable<?> list)
{
  if (list.iterator() instanceof Cursor)
    {
      ((Cursor) list.iterator()).close();
    }
}

这取决于您必须执行的操作。为什么要遍历一百万行？您是否以批处理模式更新某些内容？您要向客户显示所有记录吗？您是否正在对检索到的实体计算一些统计信息？

如果要向客户端显示一百万条记录，请重新考虑您的用户界面。在这种情况下，适当的解决方案是对结果进行分页并使用setFirstResult()和setMaxResult()。

如果您启动了大量记录的更新，则最好使更新保持简单并易于使用Query.executeUpdate()。（可选）您可以使用消息驱动的Bean oa Work Manager以异步模式执行更新。

如果要对检索到的实体计算一些统计信息，则可以利用JPA规范定义的分组功能。

对于其他情况，请更具体:)

没有“适当的”方法可以执行此操作，这不是JPA或JDO或任何其他ORM所要执行的操作，直接的JDBC将是您的最佳选择，因为您可以对其进行配置，以在以下位置返回少量行时间并在使用时刷新它们，这就是为什么存在服务器端游标的原因。

ORM工具不是为批量处理而设计的，它们旨在让您操作对象并尝试使存储数据的RDBMS尽可能透明，大多数至少在某种程度上会失败。在这种规模下，由于对象实例化的开销（简单而又简单），无法处理成千上万的行（对象），使用任何ORM处理更少的行，并使其在任何合理的时间内执行。

使用适当的工具。简单的JDBC和存储过程肯定在2011年占有一席之地，尤其是与这些ORM框架相比，它们在处理方面更胜一筹。

List<Integer>无论您如何做，将一百万个东西甚至连成一个简单的东西都不会很有效。正确地执行您要问的方法是一个简单的SELECT id FROM table，将其设置为SERVER SIDE（取决于供应商），然后将光标移到该对象上FORWARD_ONLY READ-ONLY并对其进行迭代。

如果您真的要通过调用每个Web服务器来拉动数以百万计的ID来处理，则您还必须进行一些并发处理，以使其在任何合理的时间内运行。使用JDBC游标进行拉取并一次将其中几个放置在ConcurrentLinkedQueue中，并且线程池很小（＃CPU / Cores + 1），拉取并处理它们是在带有任何“正常”的RAM量，因为您已经用完了内存。

也请参阅此答案。

您可以使用另一个“技巧”。仅加载您感兴趣的实体的标识符集合。假设标识符的类型为long = 8bytes，那么10 ^ 6的此类标识符列表大约8Mb。如果它是一个批处理过程（一次一个实例），那么它是可以接受的。然后进行迭代并完成工作。

另一句话-无论如何，您都应该分块执行此操作-特别是在修改记录时，否则数据库中的回滚段会增加。

设置firstResult / maxRows策略时- 对于远离顶部的结果，它会非常缓慢。

还应考虑到数据库可能正在以读提交隔离的方式运行，因此要避免幻像读取加载标识符，然后一个一个地（或10个到十个，或其他）来加载实体。

令我惊讶的是，在这里的答案中，存储过程的使用并不突出。过去，当我不得不做这样的事情时，我创建了一个存储过程，该过程以小块数据进行处理，然后休眠一会儿，然后继续。休眠的原因是不会使数据库不知所措，该数据库也可能用于更实时的查询类型，例如连接到网站。如果没有其他人使用该数据库，则可以省去睡眠。如果您需要确保一次处理一次所有记录，那么您将需要创建一个额外的表（或字段）来存储您已处理的记录，以便在重启后保持弹性。

这里的性能节省非常可观，可能比您在JPA / Hibernate / AppServer领域中所做的任何事情都快几个数量级，并且数据库服务器很可能具有自己的服务器端游标类型的机制，可以有效地处理大型结果集。节省性能的原因是不必将数据从数据库服务器传送到应用程序服务器，在该服务器上您可以处理数据，然后再将其传送回。

使用存储过程可能会给您带来完全的不利影响，但是如果您在个人工具箱中拥有这种技能并且可以在这种情况下使用它，则可以相当快地淘汰掉这些东西。 。

扩展@Tomasz Nurkiewicz的答案。您可以访问DataSource，从而可以为您提供连接

@Resource(name = "myDataSource",
    lookup = "java:comp/DefaultDataSource")
private DataSource myDataSource;

在您的代码中

try (Connection connection = myDataSource.getConnection()) {
    // raw jdbc operations
}

这将允许您绕过某些特定的大型批处理操作（例如导入/导出）的JPA，但是如果需要，您仍然可以访问实体管理器进行其他JPA操作。

使用Pagination概念检索结果

我自己对此感到纳闷。似乎很重要：

• 您的数据集有多大（行）
• 您正在使用什么JPA实现
• 您对每一行进行什么样的处理。

我编写了一个Iterator，可以轻松地交换两种方法（findAll与findEntries）。

我建议您同时尝试。

Long count = entityManager().createQuery("select count(o) from Model o", Long.class).getSingleResult();
ChunkIterator<Model> it1 = new ChunkIterator<Model>(count, 2) {

    @Override
    public Iterator<Model> getChunk(long index, long chunkSize) {
        //Do your setFirst and setMax here and return an iterator.
    }

};

Iterator<Model> it2 = List<Model> models = entityManager().createQuery("from Model m", Model.class).getResultList().iterator();


public static abstract class ChunkIterator<T> 
    extends AbstractIterator<T> implements Iterable<T>{
    private Iterator<T> chunk;
    private Long count;
    private long index = 0;
    private long chunkSize = 100;

    public ChunkIterator(Long count, long chunkSize) {
        super();
        this.count = count;
        this.chunkSize = chunkSize;
    }

    public abstract Iterator<T> getChunk(long index, long chunkSize);

    @Override
    public Iterator<T> iterator() {
        return this;
    }

    @Override
    protected T computeNext() {
        if (count == 0) return endOfData();
        if (chunk != null && chunk.hasNext() == false && index >= count) 
            return endOfData();
        if (chunk == null || chunk.hasNext() == false) {
            chunk = getChunk(index, chunkSize);
            index += chunkSize;
        }
        if (chunk == null || chunk.hasNext() == false) 
            return endOfData();
        return chunk.next();
    }

}

我最终没有使用我的块迭代器（因此可能没有经过测试）。顺便说一句，如果您想使用它，您将需要Google收藏。

使用休眠模式，可以通过4种不同的方式来实现所需的功能。每个设计都有权衡，局限和后果。我建议您仔细研究每种情况，并确定哪种方法适合您的情况。

1. 使用无状态会话与scroll（）
2. 每次迭代后使用session.clear（）。当需要附加其他实体时，请在单独的会话中加载它们。实际上，第一个会话模拟了无状态会话，但是保留了有状态会话的所有功能，直到对象分离为止。
3. 使用iterate（）或list（），但在第一个查询中仅获取ID，然后在每个迭代中的单独会话中执行session.load，并在迭代结束时关闭会话。
4. 将Query.iterate（）与EntityManager.detach（）结合使用，也称为Session.evict（）;

这是一个简单的，简单的JPA示例（在Kotlin中），展示了如何对任意大的结果集进行分页，一次不读取游标就可以读取100个项目的块（每个游标都消耗数据库上的资源）。它使用键集分页。

有关键集分页的概念，请参见https://use-the-index-luke.com/no-offset；以及https://www.citusdata.com/blog/2016/03/30/five-ways-to- paginate /用于比较不同的分页方式及其缺点。

/*
create table my_table(
  id int primary key, -- index will be created
  my_column varchar
)
*/

fun keysetPaginationExample() {
    var lastId = Integer.MIN_VALUE
    do {

        val someItems =
        myRepository.findTop100ByMyTableIdAfterOrderByMyTableId(lastId)

        if (someItems.isEmpty()) break

        lastId = someItems.last().myTableId

        for (item in someItems) {
          process(item)
        }

    } while (true)
}

JPA和NativeQuery的示例每次使用偏移量获取size元素时

public List<X> getXByFetching(int fetchSize) {
        int totalX = getTotalRows(Entity);
        List<X> result = new ArrayList<>();
        for (int offset = 0; offset < totalX; offset = offset + fetchSize) {
            EntityManager entityManager = getEntityManager();
            String sql = getSqlSelect(Entity) + " OFFSET " + offset + " ROWS";
            Query query = entityManager.createNativeQuery(sql, X.class);
            query.setMaxResults(fetchSize);
            result.addAll(query.getResultList());
            entityManager.flush();
            entityManager.clear();
        return result;
    }