JPA: qual è il modello corretto per l'iterazione su set di risultati di grandi dimensioni?

Diciamo che ho una tabella con milioni di righe. Utilizzando JPA, qual è il modo corretto per iterare su una query su quella tabella, in modo tale da non avere tutto un elenco in memoria con milioni di oggetti?

Ad esempio, sospetto che il seguente esploderà se la tabella è grande:

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

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

L'impaginazione (loop e aggiornamento manuale setFirstResult()/ setMaxResult()) è davvero la soluzione migliore?

Modifica : il caso d'uso principale a cui mi rivolgo è una sorta di lavoro in batch. Va bene se ci vuole molto tempo per funzionare. Non è coinvolto alcun client web; Ho solo bisogno di "fare qualcosa" per ogni riga, una (o qualche piccola N) alla volta. Sto solo cercando di evitare di averli tutti in memoria allo stesso tempo.

La pagina 537 di Java Persistence with Hibernate fornisce una soluzione usando ScrollableResults, ma purtroppo è solo per Hibernate.

Quindi sembra che l'uso di setFirstResult/ setMaxResultse l'iterazione manuale sia davvero necessario. Ecco la mia soluzione utilizzando JPA:

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

quindi, usalo in questo modo:

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();
    }
}

Ho provato le risposte presentate qui, ma JBoss 5.1 + MySQL Connector / J 5.1.15 + Hibernate 3.3.2 non funzionavano con quelli. Abbiamo appena migrato da JBoss 4.x a JBoss 5.1, quindi per ora ci siamo fermati, e quindi l'ultimo Hibernate che possiamo usare è 3.3.2.

L'aggiunta di un paio di parametri extra ha fatto il lavoro e il codice come questo viene eseguito senza OOME:

        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();

Le righe cruciali sono i parametri di query tra createQuery e scroll. Senza di essi la chiamata "scroll" tenta di caricare tutto in memoria e non finisce mai o viene eseguita su OutOfMemoryError.

Non puoi farlo in JPA diretto, tuttavia Hibernate ha il supporto per sessioni senza stato e set di risultati scorrevoli.

Con il suo aiuto elaboriamo regolarmente miliardi di righe.

Ecco un collegamento alla documentazione: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/batch.html#batch-statelesssession

Ad essere onesto, suggerirei di lasciare JPA e restare con JDBC (ma certamente usando JdbcTemplateclassi di supporto o simili). JPA (e altri fornitori / specifiche ORM) non è progettato per operare su molti oggetti all'interno di una transazione poiché presumono che tutto ciò che viene caricato debba rimanere nella cache di primo livello (da qui la necessità di clear()JPA).

Inoltre sto raccomandando una soluzione di livello più basso perché il sovraccarico di ORM (il riflesso è solo la punta di un iceberg) potrebbe essere così significativo, che l'iterazione sulla pianura ResultSet, anche utilizzando un supporto leggero come menzionato, JdbcTemplatesarà molto più veloce.

JPA semplicemente non è progettato per eseguire operazioni su una grande quantità di entità. Potresti giocare con flush()/ clear()per evitare OutOfMemoryError, ma considera questo ancora una volta. Guadagni molto poco pagando il prezzo di un enorme consumo di risorse.

Se utilizzi EclipseLink, utilizza questo metodo per ottenere il risultato come Iterabile

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();  
}  

Chiudi Metodo

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

Dipende dal tipo di operazione che devi fare. Perché stai ripetendo più di un milione di righe? Stai aggiornando qualcosa in modalità batch? Visualizzerai tutti i record a un cliente? Stai elaborando alcune statistiche sulle entità recuperate?

Se hai intenzione di visualizzare un milione di record al client, riconsidera la tua interfaccia utente. In questo caso, la soluzione appropriata è impaginare i risultati e utilizzare setFirstResult()e setMaxResult().

Se hai avviato un aggiornamento di una grande quantità di record, farai meglio a mantenerlo semplice e utilizzabile Query.executeUpdate(). Facoltativamente, è possibile eseguire l'aggiornamento in modalità asincrona utilizzando un Message-Driven Bean o Work Manager.

Se stai elaborando alcune statistiche sulle entità recuperate, puoi trarre vantaggio dalle funzioni di raggruppamento definite dalla specifica JPA.

Per qualsiasi altro caso, sii più specifico :)

Non esiste un "corretto" cosa fare, questo non è ciò che JPA o JDO o qualsiasi altro ORM è inteso fare, JDBC diretto sarà la tua migliore alternativa, poiché puoi configurarlo per ripristinare un piccolo numero di righe in una volta e svuotali man mano che vengono utilizzati, ecco perché esistono cursori lato server.

Gli strumenti ORM non sono progettati per l'elaborazione in blocco, sono progettati per consentire di manipolare oggetti e tentare di rendere l'RDBMS in cui sono archiviati i dati essere il più trasparente possibile, la maggior parte fallisce nella parte trasparente almeno in una certa misura. A questa scala, non è possibile elaborare centinaia di migliaia di righe (oggetti), tanto meno milioni con qualsiasi ORM e farlo eseguire in un ragionevole lasso di tempo a causa dell'overhead di istanziazione dell'oggetto, chiaro e semplice.

Usa lo strumento appropriato. Il JDBC diretto e le procedure memorizzate hanno sicuramente un posto nel 2011, specialmente in ciò che sono migliori nel fare rispetto a questi framework ORM.

Tirare un milione di qualsiasi cosa, anche in un semplice List<Integer>non sarà molto efficiente indipendentemente da come lo fai. Il modo corretto per fare ciò che stai chiedendo è un semplice SELECT id FROM table, impostare su SERVER SIDE(dipendente dal fornitore) e il cursore su FORWARD_ONLY READ-ONLYe iterare su quello.

Se stai davvero tirando milioni di ID da elaborare chiamando un server Web con ciascuno di essi, dovrai eseguire anche un'elaborazione simultanea affinché funzioni in un ragionevole lasso di tempo. Tirare con un cursore JDBC e posizionarne alcuni alla volta in un ConcurrentLinkedQueue e avere un piccolo pool di thread (# CPU / Core + 1) estrarli ed elaborarli è l'unico modo per completare l'attività su una macchina con qualsiasi " normale "quantità di RAM, dato che stai già esaurendo la memoria.

Vedi anche questa risposta .

Puoi usare un altro "trucco". Carica solo la raccolta di identificatori delle entità a cui sei interessato. Supponiamo che l'identificatore sia di tipo long = 8bytes, quindi 10 ^ 6 un elenco di tali identificatori fa circa 8Mb. Se si tratta di un processo batch (un'istanza alla volta), è sopportabile. Quindi iterare e fare il lavoro.

Un'altra osservazione: dovresti comunque farlo in blocchi, specialmente se modifichi i record, altrimenti il segmento di rollback nel database crescerà.

Quando si tratta di impostare la strategia firstResult / maxRows, sarà MOLTO MOLTO lento per risultati lontani dalla cima.

Tieni anche in considerazione che il database sta probabilmente operando in isolamento read commited , in modo da evitare letture fantasma caricare gli identificatori e quindi caricare le entità una per una (o 10 per 10 o altro).

Sono stato sorpreso di vedere che l'uso di stored procedure non era più prominente nelle risposte qui. In passato, quando dovevo fare qualcosa di simile, creo una procedura memorizzata che elabora i dati in piccoli blocchi, quindi si ferma per un po ', quindi continua. Il motivo della sospensione è non sovraccaricare il database che presumibilmente viene utilizzato anche per tipi di query più in tempo reale, come la connessione a un sito web. Se non c'è nessun altro che utilizza il database, puoi lasciare fuori il sonno. Se è necessario assicurarsi di elaborare ogni record una sola volta, sarà necessario creare una tabella (o un campo) aggiuntivo per archiviare i record elaborati in modo da essere resilienti durante i riavvii.

I risparmi in termini di prestazioni qui sono significativi, forse ordini di grandezza più veloci di qualsiasi cosa tu possa fare in JPA / Hibernate / AppServer land, e molto probabilmente il tuo server di database avrà il suo tipo di cursore lato server per elaborare in modo efficiente set di risultati di grandi dimensioni. I risparmi sulle prestazioni derivano dal non dover inviare i dati dal server del database al server delle applicazioni, dove si elaborano i dati, per poi rispedirli.

Ci sono alcuni svantaggi significativi nell'utilizzo di stored procedure che potrebbero escluderlo completamente, ma se hai quell'abilità nella tua cassetta degli attrezzi personale e puoi usarla in questo tipo di situazione, puoi eliminare questo tipo di cose abbastanza rapidamente .

Per espandere la risposta di @Tomasz Nurkiewicz. Hai accesso a ciò DataSourceche a sua volta può fornirti una connessione

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

Nel tuo codice hai

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

Ciò ti consentirà di bypassare JPA per alcune operazioni batch di grandi dimensioni specifiche come l'importazione / esportazione, tuttavia hai ancora accesso al gestore entità per altre operazioni JPA se ne hai bisogno.

Usa PaginationConcept per recuperare il risultato

Me lo sono chiesto io stesso. Sembra importare:

• quanto è grande il tuo set di dati (righe)
• quale implementazione JPA stai utilizzando
• che tipo di elaborazione stai eseguendo per ogni riga.

Ho scritto un Iterator per semplificare lo scambio di entrambi gli approcci (findAll vs findEntries).

Ti consiglio di provare entrambi.

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();
    }

}

Ho finito per non usare il mio iteratore di blocchi (quindi potrebbe non essere testato). A proposito, avrai bisogno delle raccolte di Google se vuoi usarlo.

Con Hibernate ci sono 4 modi diversi per ottenere ciò che desideri. Ognuno ha compromessi, limitazioni e conseguenze di progettazione. Suggerisco di esplorarli tutti e di decidere quale è giusto per la tua situazione.

1. Usa una sessione senza stato con scroll ()
2. Usa session.clear () dopo ogni iterazione. Quando è necessario collegare altre entità, caricarle in una sessione separata. effettivamente la prima sessione emula la sessione senza stato, ma conserva tutte le caratteristiche di una sessione con stato, finché gli oggetti non vengono scollegati.
3. Usa iterate () o list () ma ottieni solo gli id ​​nella prima query, quindi in una sessione separata in ogni iterazione, esegui session.load e chiudi la sessione alla fine dell'iterazione.
4. Usa Query.iterate () con EntityManager.detach () aka Session.evict ();

Ecco un semplice e diretto esempio JPA (in Kotlin) che mostra come è possibile impaginare su un set di risultati arbitrariamente grande, leggendo blocchi di 100 elementi alla volta, senza utilizzare un cursore (ogni cursore consuma risorse sul database). Usa l'impaginazione del keyset.

Vedere https://use-the-index-luke.com/no-offset per il concetto di paginazione keyset e https://www.citusdata.com/blog/2016/03/30/five-ways-to- impagina / per un confronto tra diversi modi di impaginare insieme ai loro svantaggi.

/*
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)
}

Un esempio con JPA e NativeQuery che recupera ogni volta la dimensione degli elementi utilizzando gli offset

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;
    }