Wie behandelt man große Datenmengen mit JPA (oder zumindest mit Hibernate)?

Question

Ich muss meine Web-App mit wirklich riesigen Datensätzen arbeiten lassen. Im Moment bekomme ich entweder OutOfMemoryException oder Ausgabe, die 1-2 Minuten generiert wird.

Sagen wir es einfach und nehmen wir an, dass wir 2 Tabellen in DB haben: Worker und WorkLog mit ungefähr 1000 Reihen in der ersten und 10 000 000 Reihen in der zweiten. Letztere Tabelle hat mehrere Felder einschließlich "workerId" und "Stunden Worked" Felder unter anderem. Was wir brauchen, ist:

1. zählen insgesamt Stunden von jedem Benutzer gearbeitet;

2. Liste der Arbeitsperioden für jeden Benutzer.

Der einfachste Ansatz (IMO) für jede Aufgabe im Klar SQL ist:

1)

select Worker.name, sum(hoursWorked) from Worker, WorkLog 
    where Worker.id = WorkLog.workerId 
    group by Worker.name; 

//results of this query should be transformed to Multimap<Worker, Long> 

2)

select Worker.name, WorkLog.start, WorkLog.hoursWorked from Worker, WorkLog 
    where Worker.id = WorkLog.workerId; 

//results of this query should be transformed to Multimap<Worker, Period> 
//if it was JDBC then it would be vitally 
//to set resultSet.setFetchSize (someSmallNumber), ~100 

So habe ich zwei Fragen :

1. wie ich jeden meiner Ansätze mit JPA (oder zumindest mit Hibernate) umsetze;
2. Wie würden Sie mit diesem Problem umgehen (mit JPA oder Hibernate natürlich)?

Answer 1

nehme an, dass wir zwei Tabellen in DB: Arbeiter und WorkLog mit etwa 1000 Zeilen in der ersten und 10 000 000 Zeilen in der zweiten

Für hohe Mengen wie diese, meine Empfehlung wäre The StatelessSession interface aus dem Ruhezustand zu verwenden:

Alternativ Ruhezustand einen Befehlsorientierte API, die verwendet werden kann, um Daten an und von Streaming die Datenbank in Form von freistehenden Objekte. A StatelessSession hat keinen Persistenzkontext, der damit verbunden ist und bietet nicht viele der höheren Lebenszyklus-Semantik . In insbesondere, eine statusfreie Sitzung implementiert nicht einen Cache der ersten Ebene noch interagieren mit jedem Abfrage-Cache der zweiten Ebene oder . Es implementiert Transaktions-Write-Behind oder automatische Dirty-Überprüfung. Operationen durchgeführt mit einer statusfreien Sitzung nie zu assoziierten Instanzen kaskadieren. Sammlungen werden von einer zustandslosen Sitzung ignoriert. Operationen, die über eine statusfreie Sitzung ausgeführt werden, umgehen das Ereignismodell und die Interzeptoren von Hibernate. Aufgrund von das Fehlen eines Cache der ersten Ebene, Stateless-Sitzungen sind anfällig für Daten Aliasing-Effekte . Eine statusfreie Sitzung ist eine untergeordnete Abstraktion , die viel näher an der zugrunde liegenden JDBC ist.

StatelessSession session = sessionFactory.openStatelessSession(); 
Transaction tx = session.beginTransaction(); 

ScrollableResults customers = session.getNamedQuery("GetCustomers") 
    .scroll(ScrollMode.FORWARD_ONLY); 
while (customers.next()) { 
    Customer customer = (Customer) customers.get(0); 
    customer.updateStuff(...); 
    session.update(customer); 
} 

tx.commit(); 
session.close(); 

In diesem Codebeispiel die Customer Instanzen von der Abfrage zurückgegeben werden sofort abgelöst. Sie sind nie mit jeder Persistenz verbunden Kontext.

Die insert(), update() und delete() Operationen durch die StatelessSession Schnittstelle definiert sind als direkte Datenbank Zeilenebene Operationen sein. Sie ergeben die sofortige Ausführung eines SQL INSERT, UPDATE oder DELETE jeweils. Sie haben unterschiedliche Semantiken zu den und delete() Operationen definiert durch die Schnittstelle.

Answer 2

Raw SQL sollte nicht als letzter Ausweg betrachtet werden. Es sollte immer noch als Option in Betracht gezogen werden, wenn Sie auf der JPA-Ebene "Standard" beibehalten möchten, nicht jedoch auf der Datenbankebene. JPA unterstützt auch systemeigene Abfragen, bei denen die Zuordnung zu Standard-Entitäten weiterhin für Sie erfolgt.

Wenn Sie jedoch eine große Ergebnismenge haben, die nicht in der Datenbank verarbeitet werden kann, sollten Sie einfach nur JDBC verwenden, da JPA (Standard) das Streaming großer Datenmengen nicht unterstützt.

Es ist schwieriger, Ihre Anwendung auf verschiedene Anwendungsserver zu portieren, wenn Sie JPA-implementierungsspezifische Konstrukte verwenden, da die JPA-Engine in den Anwendungsserver eingebettet ist und Sie möglicherweise kein Steuerelement für den verwendeten JPA-Anbieter haben.

Answer 3

Ich benutze so etwas und es funktioniert sehr schnell. Ich hasse es auch, natives SQL zu verwenden, da unsere Anwendung in jeder Datenbank funktionieren sollte.

Folowing results in eine sehr optimierte sql und returns Liste der Datensätze, die Karten sind.

String hql = "select distinct " + 
      "t.uuid as uuid, t.title as title, t.code as code, t.date as date, t.dueDate as dueDate, " + 
      "t.startDate as startDate, t.endDate as endDate, t.constraintDate as constraintDate, t.closureDate as closureDate, t.creationDate as creationDate, " + 
      "sc.category as category, sp.priority as priority, sd.difficulty as difficulty, t.progress as progress, st.type as type, " + 
      "ss.status as status, ss.color as rowColor, (p.rKey || ' ' || p.name) as project, ps.status as projectstatus, (r.code || ' ' || r.title) as requirement, " + 
      "t.estimate as estimate, w.title as workgroup, o.name || ' ' || o.surname as owner, " + 
      "ROUND(sum(COALESCE(a.duration, 0)) * 100/case when ((COALESCE(t.estimate, 0) * COALESCE(t.progress, 0)) = 0) then 1 else (COALESCE(t.estimate, 0) * COALESCE(t.progress, 0)) end, 2) as factor " + 
      "from " + Task.class.getName() + " t " + 
      "left join t.category sc " + 
      "left join t.priority sp " + 
      "left join t.difficulty sd " + 
      "left join t.taskType st " + 
      "left join t.status ss " + 
      "left join t.project p " + 
      "left join t.owner o " + 
      "left join t.workgroup w " + 
      "left join p.status ps " + 
      "left join t.requirement r " + 
      "left join p.status sps " + 
      "left join t.iterationTasks it " + 
      "left join t.taskActivities a " + 
      "left join it.iteration i " + 
      "where sps.active = true and " + 
      "ss.done = false and " + 
      "(i.uuid <> :iterationUuid or it.uuid is null) " + filterHql + 
      "group by t.uuid, t.title, t.code, t.date, t.dueDate, " + 
      "t.startDate, t.endDate, t.constraintDate, t.closureDate, t.creationDate, " + 
      "sc.category, sp.priority, sd.difficulty, t.progress, st.type, " + 
      "ss.status, ss.color, p.rKey, p.name, ps.status, r.code, r.title, " + 
      "t.estimate, w.title, o.name, o.surname " + sortHql; 

    if (logger.isDebugEnabled()) { 
     logger.debug("Executing hql: " + hql); 
    } 

    Query query = hibernateTemplate.getSessionFactory().getCurrentSession().getSession(EntityMode.MAP).createQuery(hql); 
    for(String key: filterValues.keySet()) { 
     Object valueSet = filterValues.get(key); 

     if (logger.isDebugEnabled()) { 
      logger.debug("Setting query parameter for " + key); 
     } 

     if (valueSet instanceof java.util.Collection<?>) { 
      query.setParameterList(key, (Collection)filterValues.get(key)); 
     } else { 
      query.setParameter(key, filterValues.get(key)); 
     } 
    }  
    query.setString("iterationUuid", iteration.getUuid()); 
    query.setResultTransformer(Transformers.ALIAS_TO_ENTITY_MAP); 

    if (logger.isDebugEnabled()) { 
     logger.debug("Query building complete."); 
     logger.debug("SQL: " + query.getQueryString()); 
    } 

    return query.list(); 

Answer 4

Ich stimme zu, dass die Berechnung auf dem Datenbankserver die beste Option in dem von Ihnen erwähnten Fall ist. HQL und JPAQL können diese beiden Anfragen bearbeiten:

1)

select w, sum(wl.hoursWorked) 
from Worker w, WorkLog wl 
where w.id = wl.workerId 
group by w 

oder, wenn der Verein zugeordnet ist:

select w, sum(wl.hoursWorked) 
from Worker w join w.workLogs wl 
group by w 

beide oder die Rückkehr Sie Liste, in der Object [] s sind Arbeiter und Lang. Oder man könnte auch „dynamische Instanziierung“ Abfragen verwenden, um das einpacken, zum Beispiel:

select new WorkerTotal(select w, sum(wl.hoursWorked)) 
from Worker w join w.workLogs wl 
group by w 

oder (je nach Bedarf) wahrscheinlich sogar nur:

select new WorkerTotal(select w.id, w.name, sum(wl.hoursWorked)) 
from Worker w join w.workLogs wl 
group by w.id, w.name 

WorkerTotal ist nur eine normale Klasse. Es muss passende Konstruktoren haben.

2)

select w, new Period(wl.start, wl.hoursWorked) 
from Worker w join w.workLogs wl 

dies kehren Sie ein Ergebnis für jede Zeile in der Tabelle WorkLog ... Das new Period(...) Bit wird „dynamische Instanziierung“ genannt und wird verwendet, Tupel aus dem Ergebnis in Objekte umwickeln (leichterer Konsum).

Für Manipulation und allgemeine Verwendung empfehle ich StatelessSession als Pascal weist darauf hin.

Answer 5

Es gibt verschiedene Techniken, die miteinander in Verbindung verwendet werden können, müssen, um erstellen und Abfragen für große Datenmengen zu manipulieren, wo Speicher eine Begrenzung ist:

1. Verwenden setFetchSize (etwas Wert, vielleicht 100+) als Standard (über JDBC) ist 10. Dies ist mehr über die Leistung und ist der größte zusammenhängende Faktor davon. Kann in JPA mit QueryHint von Provider (Hibernate, etc) durchgeführt werden. Es gibt (aus welchen Gründen auch immer) keine JPA Query.setFetchSize(int) Methode.
2. Versuchen Sie nicht, das gesamte Ergebnis für 10K + Datensätze zu marshall. Es gibt mehrere Strategien: Verwenden Sie für GUIs Paging oder ein Framework, das Paging durchführt. Betrachten Sie Lucene oder kommerzielle Suchmaschinen/Suchmaschinen (Endeca, wenn das Unternehmen das Geld hat). Um Daten irgendwo zu senden, streamen Sie sie und leeren Sie den Puffer alle N Datensätze, um zu begrenzen, wie viel Speicher verwendet wird. Der Stream kann in eine Datei, ein Netzwerk usw. geleert werden. Denken Sie daran, dass JPA JDBC verwendet und JDBC die Ergebnismenge auf dem Server speichert, wobei nur N-Zeilen in einer Satzgruppe gleichzeitig abgerufen werden. Diese Aufschlüsselung kann manipuliert werden, um das Ausspülen von Daten in Gruppen zu erleichtern.
3. Überlegen Sie, was der Anwendungsfall ist. In der Regel versucht eine Anwendung, Fragen zu beantworten. Wenn die Antwort darin besteht, bis zu 10K + Zeilen zu entfernen, sollte das Design überprüft werden. mit Indizierung Suchmaschinen wie Lucene wieder, zu prüfen, um die Abfragen verfeinern, betrachten BloomFilters als enthält Kontroll Caches mit Nadeln in Heuhaufen zu finden, ohne auf die Datenbank zu gehen usw.

Answer 6

Es scheint, dass Sie auch diese mit Eclipse tun können . diese Check: http://wiki.eclipse.org/EclipseLink/Examples/JPA/Pagination:

Query query = em.createQuery... 
query.setHint(QueryHints.CURSOR, true) 
    .setHint(QueryHints.SCROLLABLE_CURSOR, true) 
ScrollableCursor scrl = (ScrollableCursor)q.getSingleResult(); 
Object o = null; 
while ((o = scrl.next()) != null) { ... } 

Answer 7

Diese blog post kann auch helfen. Es faßt den Ansatz mit zustandsloser Sitzung zusammen und fügt einige zusätzliche Hinweise hinzu, z. wie man Ergebnisse mit JAX-RS streamen kann.