JPA: jaki jest właściwy wzorzec do iteracji po dużych zestawach wyników?

Powiedzmy, że mam tabelę z milionami wierszy. Używając JPA, jaki jest właściwy sposób iteracji zapytania względem tej tabeli, tak że nie mam całej listy w pamięci z milionami obiektów?

Na przykład podejrzewam, że następujące elementy wybuchną, jeśli stół jest duży:

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

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

Czy paginacja (zapętlanie i ręczna aktualizacja setFirstResult()/ setMaxResult()) to naprawdę najlepsze rozwiązanie?

Edycja : główny przypadek użycia, na który kieruję, to rodzaj pracy wsadowej. W porządku, jeśli bieganie zajmuje dużo czasu. Nie jest zaangażowany żaden klient sieciowy; Muszę tylko „zrobić coś” dla każdego wiersza, po jednym (lub kilku małych N) na raz. Po prostu staram się nie mieć ich wszystkich w pamięci w tym samym czasie.

Strona 537 Java Persistence with Hibernate daje rozwiązanie przy użyciu ScrollableResults, ale niestety jest to tylko dla Hibernate.

Wydaje się więc, że użycie setFirstResult/ setMaxResultsi ręczna iteracja są naprawdę konieczne. Oto moje rozwiązanie wykorzystujące JPA:

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

następnie użyj tego w ten sposób:

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

Wypróbowałem odpowiedzi tutaj przedstawione, ale JBoss 5.1 + MySQL Connector / J 5.1.15 + Hibernate 3.3.2 nie działały z nimi. Właśnie przeprowadziliśmy migrację z JBoss 4.x do JBoss 5.1, więc na razie się z nim utknęliśmy, a zatem najnowsza wersja Hibernate, której możemy użyć, to 3.3.2.

Dodanie kilku dodatkowych parametrów wykonało zadanie, a kod taki jak ten działa bez 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();

Kluczowe wiersze to parametry zapytania między createQuery i scroll. Bez nich wywołanie "scroll" próbuje załadować wszystko do pamięci i albo nigdy nie kończy się, albo działa do OutOfMemoryError.

Tak naprawdę nie można tego zrobić w prostym JPA, jednak Hibernate obsługuje sesje bezstanowe i przewijalne zestawy wyników.

Z jego pomocą rutynowo przetwarzamy miliardy wierszy.

Oto link do dokumentacji: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/batch.html#batch-statelesssession

Szczerze mówiąc, sugerowałbym opuszczenie JPA i pozostanie przy JDBC (ale z pewnością przy użyciu JdbcTemplateklasy wsparcia itp.). JPA (i inni dostawcy / specyfikacje ORM) nie są przeznaczone do działania na wielu obiektach w ramach jednej transakcji, ponieważ zakładają, że wszystko, co załadowane, powinno pozostać w pamięci podręcznej pierwszego poziomu (stąd potrzeba clear()w JPA).

Polecam również bardziej niskopoziomowe rozwiązanie, ponieważ narzut ORM (odbicie jest tylko wierzchołkiem góry lodowej) może być tak znaczący, że iteracja po gładkiej powierzchni ResultSet, nawet przy użyciu lekkiej podpory, jak wspomniano, JdbcTemplatebędzie znacznie szybsza.

JPA po prostu nie jest przeznaczony do wykonywania operacji na dużej liczbie podmiotów. Możesz grać z flush()/, clear()aby uniknąć OutOfMemoryError, ale rozważ to jeszcze raz. Zyskujesz bardzo mało płacąc cenę ogromnego zużycia zasobów.

Jeśli używasz EclipseLink I ', użyj tej metody, aby uzyskać wynik jako iterowalny

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

zamknij Metoda

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

To zależy od rodzaju operacji, którą musisz wykonać. Dlaczego zapętlasz ponad milion wierszy? Aktualizujesz coś w trybie wsadowym? Czy zamierzasz wyświetlić wszystkie rekordy klientowi? Czy obliczasz jakieś statystyki dotyczące pobranych jednostek?

Jeśli zamierzasz wyświetlić klientowi milion rekordów, rozważ ponownie swój interfejs użytkownika. W takim przypadku odpowiednim rozwiązaniem jest podzielenie wyników na strony i użycie setFirstResult()i setMaxResult().

Jeśli uruchomiłeś aktualizację dużej liczby rekordów, lepiej zachowaj prostotę i obsługę aktualizacji Query.executeUpdate(). Opcjonalnie można przeprowadzić aktualizację w trybie asynchronicznym za pomocą komponentu Bean sterowanego komunikatami lub Work Manager.

Jeśli obliczasz statystyki pobranych jednostek, możesz skorzystać z funkcji grupowania zdefiniowanych w specyfikacji JPA.

W każdym innym przypadku podaj bardziej szczegółowe informacje :)

Nie ma „właściwego” tego, co należy zrobić, nie to jest przeznaczone do JPA, JDO lub innego ORM-u. Prosty JDBC będzie najlepszą alternatywą, ponieważ można go skonfigurować tak, aby przywrócić niewielką liczbę wierszy w czas i opróżnij je, gdy są używane, dlatego istnieją kursory po stronie serwera.

Narzędzia ORM nie są przeznaczone do przetwarzania zbiorczego, są zaprojektowane tak, aby umożliwić manipulowanie obiektami i próbować uczynić RDBMS, w którym przechowywane są dane, możliwie jak najbardziej przejrzystym, a większość z nich przynajmniej do pewnego stopnia zawodzi w części przezroczystej. W tej skali nie ma sposobu na przetworzenie setek tysięcy wierszy (obiektów), a tym bardziej milionów za pomocą dowolnego ORM i wykonanie go w rozsądnym czasie ze względu na obciążenie związane z tworzeniem obiektów, proste i proste.

Użyj odpowiedniego narzędzia. Prosty JDBC i procedury składowane zdecydowanie mają swoje miejsce w 2011 roku, zwłaszcza w tym, co robią lepiej niż te ramy ORM.

Wyciągnięcie miliona czegokolwiek, nawet do prostego, List<Integer>nie będzie zbyt wydajne, niezależnie od tego, jak to zrobisz. Prawidłowy sposób na zrobienie tego, o co prosisz, to proste SELECT id FROM tableustawienie SERVER SIDE(zależne od dostawcy) i kursor naFORWARD_ONLY READ-ONLY i iteracja po tym.

Jeśli naprawdę pobierasz miliony identyfikatorów do przetworzenia, wywołując z każdym serwerem WWW, będziesz musiał również wykonać równoległe przetwarzanie, aby to działało w rozsądnym czasie. Przeciąganie za pomocą kursora JDBC i umieszczanie kilku z nich naraz w ConcurrentLinkedQueue oraz posiadanie małej puli wątków (liczba procesorów / rdzeni + 1) ściąganie i przetwarzanie ich to jedyny sposób na wykonanie zadania na maszynie z dowolnym " normalna ilość pamięci RAM, biorąc pod uwagę, że już zaczyna brakować pamięci.

Zobacz również tę odpowiedź .

Możesz użyć innej „sztuczki”. Załaduj tylko zbiór identyfikatorów podmiotów, którymi jesteś zainteresowany. Powiedz, że identyfikator jest typu long = 8 bajtów, a następnie 10 ^ 6 lista takich identyfikatorów to około 8 MB. Jeśli jest to proces wsadowy (jedna instancja na raz), to można to znieść. Następnie po prostu wykonaj iterację i wykonaj zadanie.

Jeszcze jedna uwaga - i tak powinieneś to robić fragmentami - zwłaszcza jeśli modyfikujesz rekordy, w przeciwnym razie segment wycofywania w bazie danych będzie rósł.

Jeśli chodzi o ustawienie strategii firstResult / maxRows - będzie to BARDZO BARDZO powolne dla wyników daleko od góry.

Weź również pod uwagę, że baza danych prawdopodobnie działa w izolacji zatwierdzonej do odczytu , więc aby uniknąć odczytów fantomowych, odczytuje identyfikatory ładowania, a następnie ładuje jednostki jeden po drugim (lub 10 na 10 lub cokolwiek).

Zaskoczyło mnie, że użycie procedur składowanych nie było bardziej widoczne w odpowiedziach tutaj. W przeszłości, gdy musiałem coś takiego zrobić, tworzę procedurę składowaną, która przetwarza dane w małych kawałkach, potem przez chwilę usypia, a potem kontynuuje. Powodem uśpienia jest to, aby nie przeciążać bazy danych, która prawdopodobnie jest również wykorzystywana do wykonywania zapytań w czasie rzeczywistym, takich jak połączenie z witryną internetową. Jeśli nikt inny nie korzysta z bazy danych, możesz pominąć sen. Jeśli chcesz mieć pewność, że każdy rekord jest przetwarzany raz i tylko raz, musisz utworzyć dodatkową tabelę (lub pole) do przechowywania przetworzonych rekordów, aby zapewnić odporność na ponowne uruchomienie.

Oszczędności wydajności są tutaj znaczące, prawdopodobnie o rząd wielkości szybciej niż cokolwiek, co można zrobić w środowisku JPA / Hibernate / AppServer, a serwer bazy danych najprawdopodobniej będzie miał własny mechanizm typu kursora po stronie serwera do wydajnego przetwarzania dużych zestawów wyników. Oszczędność wydajności wynika z braku konieczności wysyłania danych z serwera bazy danych do serwera aplikacji, gdzie przetwarzane są dane, a następnie wysyłane z powrotem.

Istnieją poważne wady korzystania z procedur składowanych, które mogą całkowicie wykluczyć to dla Ciebie, ale jeśli masz tę umiejętność w swoim osobistym zestawie narzędzi i możesz jej użyć w takiej sytuacji, możesz dość szybko wyeliminować tego typu rzeczy .

Aby rozwinąć odpowiedź @Tomasz Nurkiewicz. Masz dostęp do tego, DataSourcektóry z kolei może zapewnić ci połączenie

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

W swoim kodzie masz

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

Umożliwi to ominięcie JPA w przypadku niektórych określonych dużych operacji wsadowych, takich jak import / eksport, jednak nadal masz dostęp do menedżera encji dla innych operacji JPA, jeśli go potrzebujesz.

Użyj PaginationConcept do pobierania wyników

Sam się nad tym zastanawiałem. Wydaje się to mieć znaczenie:

• jak duży jest Twój zbiór danych (wiersze)
• jakiej implementacji JPA używasz
• jakiego rodzaju przetwarzanie jest wykonywane dla każdego wiersza.

Napisałem Iterator, aby ułatwić zamianę obu podejść (findAll vs findEntries).

Polecam spróbować obu.

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

}

Skończyło się na tym, że nie korzystałem z mojego iteratora fragmentów (więc może to nie być tak przetestowane). Nawiasem mówiąc, będziesz potrzebować kolekcji Google, jeśli chcesz z niej korzystać.

Dzięki hibernacji istnieją 4 różne sposoby osiągnięcia tego, co chcesz. Każdy ma projektowe kompromisy, ograniczenia i konsekwencje. Proponuję zbadać każdy z nich i zdecydować, który jest odpowiedni dla Twojej sytuacji.

1. Użyj sesji bezstanowej z scroll ()
2. Użyj session.clear () po każdej iteracji. Gdy trzeba dołączyć inne jednostki, załaduj je w osobnej sesji. w rzeczywistości pierwsza sesja emuluje sesję bezstanową, ale zachowuje wszystkie funkcje sesji stanowej, dopóki obiekty nie zostaną odłączone.
3. Użyj iterate () lub list (), ale uzyskaj tylko identyfikatory w pierwszym zapytaniu, a następnie w oddzielnej sesji w każdej iteracji wykonaj session.load i zamknij sesję na koniec iteracji.
4. Użyj Query.iterate () z EntityManager.detach () aka Session.evict ();

Oto prosty, prosty przykład JPA (w Kotlinie), który pokazuje, jak można podzielić na strony dowolnie duży zestaw wyników, odczytując fragmenty po 100 pozycji na raz, bez użycia kursora (każdy kursor zużywa zasoby w bazie danych). Używa paginacji zestawu kluczy.

Zobacz https://use-the-index-luke.com/no-offset, aby zapoznać się z koncepcją paginacji zestawu kluczy i https://www.citusdata.com/blog/2016/03/30/five-ways-to- paginate / w celu porównania różnych sposobów podziału na strony wraz z ich wadami.

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

Przykład z JPA i NativeQuery pobierającym za każdym razem rozmiar elementów przy użyciu przesunięć

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