Embedded Database und große Datenmengen

[Plopp]

Hallo zusammen,

Ich bin neu in diesem Forum und habe vor einiger Zeit angefangen mich intensiv mit Java zu beschäftigen.

ich habe nun folgendes Problem...

ich muss eine große Datenmenge (ca. 80mb und ca. 400000 Zeilen mit 30 Feldern) aus einer CSV-Datei Analysieren. Dabei ist es wichtig die Daten vorher zu sortieren.

Um das zu realisieren wollte ich die Daten in einer eingebetteten Datenbank (HSQLDB Standalone Modus) übertragen.
Bei etwa 30% (ca. 150000 Zeilen und 30mb) wird das Programm extrem langsam und hangelt sich von einem Prozent zum anderen im Minutentakt.
(auch ein schließen und erneutes öffnen der Datenbank nach allen 10% half mir da nicht weiter...)

Wenn ich das Programm abbreche sind die Daten noch in der Datenbank gespeichert.
Versuche ich nun die Daten weiter drauf zuspielen (die nächsten 30% meinetwegen) , geht es von anfang an genauso langsam weiter.


Von daher denke ich, dass es an der Größe der Datenbank liegt, da er die Datei hsqldb.script in den speicher lädt und dieser nun schon voll ist.
(verbessert mich bitte falls ich da falsch liege)
Gibt es vielleicht eine Möglichkeit den Speicher zu leeren ohne die Datei schließen zu müssen und die Dateien einfach hinten ranzuhängen?
Und würde es dann auch mit dem sortieren noch funktionieren?

Oder kennt jemand eine elegantere Lösung für mein Problem!
Vielleicht ein anderes Embedded System?
Eine Möglichkeit dachte ich mir wäre noch XML mit Stax oder Sax aber würde da das Auswerten der Datengruppen (die ich bilden muss) nicht zu Zeitintensiv bei den Datenmengen?


Als letzten Ausweg könnte ich mir höchstens ein externes Datenbanksystem a la MySQL vorstellen, würde aber eigentlich lieber ein im Programm integriertes System haben wollen...


Ich bin wirklich für jede Hilfe dankbar....

Viele Grüße
Plopp

 

[hansmueller]

Hallo,

zuerst mal herzlich willkommen.

Mit HSQLDB kenne ich mich leider (noch) nicht aus.
Vielleicht mußt du etwas mit den Einstellungen herumspielen (mehr Speicher zuweisen etc.). Jede Datenbank hat da ihre eigenen Möglichkeiten.

Vielleicht solltest du es mal mit H2 probieren. Ist sozusagen so eine Art Nachfolger der HSQLDB. Da gibt es auch einen CSV-Import -> Tutorial.

MfG
hansmueller

 

[parabool]

Hast Du vllt. contraints angegeben (z.B. Unique - war bei mir mal Ursache für ähnliches Problem)

Soweit ich gelesen habe steht bei HSQLDB auch der Tabellentyp "gecachte Tabellen" zur verfügung.
Wikipedia:

Auf dem Datenträger gespeicherte Tabellen, die beim Start nicht komplett in den Speicher gelesen werden müssen. Die Größenbeschränkung einer Tabelle und eines Feldes liegt derzeit bei 8 GB. Das Arbeiten auf solchen Tabellen geht sehr schnell vonstatten.

 

[Plopp]

Vielen Dank für die Antworten.... dass geht ja super schnell hier :toll:

...ich werde die beiden Sachen gleich mal ausprobieren, obwohl ich noch nicht genau weiß was mit contraints oder Unique gemeint ist.... :bahnhof:

...ich denke es liegt zum anderen auch an der Größe der Datenbankdatei. Ich habe mal den speicher auf 1024 (-Xms1024m -Xmx1024m) und den Befehl -verbose:gc dazugesetzt. Durch die Speichererweiterung konnte ich die Daten relativ bequem einlesen.

Allerdings, gab es auch nach ca. 35% das erste mal einen FULL GC - der Speicher wurde gelehrt und wurde kurze zeit später wieder voll... dann gelehrt usw.
Es hat trotzdem nicht allzu lange gedauert (gefühlte < 2min).

Will ich bei einem erneuten Aufruf des Programms jetzt jedoch auch nur 10-20 Zeilen hinzugeben schlägt der GC alle 3-4 Zeilen zu da er sofort voll ist (ich denke mal wegen der DBgröße ca. 110 mb).

1.Frage: Warum ist dann sofort 1gb voll anstatt 110mb ansonsten ist noch nicht viel an dem Programm dran... :shock:

2. Frage hat das Auswirkungen oder Nachteile wenn ich so viel Speicher durch den Befehl Xms1024m -Xmx1024m zur Verfügung stelle? (das Programm soll unter verschiedenen PC´s ausgeführt werden)

3.Frage @hansmueller: weist du ob H2 bei einem Aufruf gleich alles in den Speicher geladen wird? Ich muss ja die gesamten Daten noch sortieren und auswerten.

Das mit dem CSV-Import hört sich ja schon mal super an.
Ich werde mich auch nochmal über gecachte Tabellen informieren... :rtfm:

 

[vanny]

Wenn ich dich richtig verstehe, dann musst du die Daten nicht zwingend in eine Datenbank schreiben oder !?

Hier geht es doch vorrangig um das Sortieren und Analysieren deiner CSV Datei.

1. Frage: Wonach sortierst du denn?
2, Frage: Wie musst du die sortierten Werte analysieren(einen nach dem anderen oder auch wieder alle Untereinander, sprich 1-n oder n-n)?

Vielleicht gibt es ja noch andere performantere Lösungsansätze.

Gruß Vanny

 

[Plopp]

richtig, das muss ich nicht. Bin für jede Lösung offen...

Am liebsten denke ich wäre mir sogar so etwas wie XML mit JDOM, weil ich dann die Zeilen direkt in die jeweiligen Knotenpunkte einsortieren könnte, und zur Auswertung den Knoten mit den eingetragenen Daten (die Anzahl variiert) sortiert nach Datum abrufen kann.
Das Problem ist dabei die Datenmenge... ich kann nicht die ganze XML datei in den Speicher laden.
mit SAX kann ich wenn ich das richtig verstanden habe nicht schreiben, und Stax kann ich in der vorhandenen XML Datei nicht einfach Zeilen dazwischenhauen ... also auch nicht geeignet zum sortieren. (Bitte korrigieren wenn ich hier mit Stax falsch liege oder es eine gute alternative dafür gibt, das wäre mir nämlich bisher am liebsten wenn das gehen würde)

...Es handelt sich um Bauteile, mit einer bestimmten ID, die verändert wurden.
...ein Aufruf(eine Aktion) kann mehrere eingetragene Zeilen enthalten und sind nach Datum sortiert.

Das bedeutet das das in etwa so aussehen könnte....

Aufruf ID ___________Bauteil ID___________Aktion________Ergebnis
1___________________ 200_____________ändern___________ok
2 _____________________ 311____________testen____________ok
3______________________ 412____________bearbeiten_______fehler
4___________________ 200__________Änderung i.O._____ok
usw.
(tschuldigung für die misslungene Tabelle )
jetzt erst nach Bauteil ID dann nach Aufruf ID (bzw. Datum) sortieren und den jeweils gesamten Aufruf Auswerten...

wenn das nicht mit den "gecachte Tabellen" funktioniert(muss ich noch Testen, kennt da jemand eine gute Anleitung?) wäre jetzt ansonsten meine Lösung eine externe DB zu verwenden, die die Datenmasse gut bewältigen kann. Denn für eine intigriert Datenbank ist wohl für diese Masse an Daten nicht geeignet...

Mein Ansatz wäre der...

- Daten in DB laden.
- Bauteile ID im Array Speichern (nur einmal pro ID,) ->

 "SELECT "Bauteil ID" FROM table"

- foreach-Schleife des Arrays

"SELECT *  From table WHERE "Bauteil ID" = Array[i] ORDER BY "Aufruf ID"

- direkt auswerten
- Ergebnisse in Array oder ner Klasse speichern und an view übergeben.

Da es sich nur um temporär gespeicherte Daten handelt könnte ich sogar gleich die Zeilen mit der ausgewerteten Bauteil ID löschen. Ich weiß nur nicht ob das Sinn macht und nicht die Performance darunter leidet, denn das bedeutet ja... nochmal in die Datenbank. Allerdings würde die für spätere Datenaufrufe auch gleich kleiner werden....

oder kennt jemand einen besseren Ansatz wäre für jeden Vorschlag oder Ansatz dankbar.

Würde mich auch auf einen performanteren Lösungsansatz sehr freuen.

@vanny: ...vielleicht schon eine Idee im Hinterkopf?

 

[vanny]

Ich bin mir immer noch nicht ganz sicher, was du da genau anlysieren willst, sprich:
in deiner Tabelle ist die Bauteil ID 2 mal 200 und hat 2 Aktionen die beide OK sind.

Da erscheint mir das Sortieren nach Datum irgendwie sinnfrei^^.

Grundsätzlich ist meine Hinterkopfidee, eine sinnvolle Sortierung für die Analyse zu finden, diese dann irgendwie persistent zu speichern um dann bestimmte Abschnitte zu analysieren und das Ergebnis wiederum Stapelweise abzulegen.

Dann hast du eine sortierte und analysierte Datenmenge, die dann nur noch ausgegeben werden muss.

Ohne aber genau zu wissen worauf da wirklich Wert gelegt wird ist das sehr schwierig.

Gruß Vanny

 

[Plopp]

Die genau Analyse dabei zu beschreiben ist sehr umfangreich, wie gesagt es handelt sich um bis zu 30 Feldern die alle mehr oder weniger berücksichtigt werden müssen. Bei der Tabelle handelt es sich nur um ein stark vereinfachtes Beispiel.


Worum es mir bei meiner Frage geht ist, wie ich am besten eine Sortierung der Daten hinbekomme.

Erst nach Bauteil ID, dann nach Datum mit Uhrzeit bzw. Aufruf ID(Aufruf ID und Datum hat die gleiche Reihenfolge ).
Und das von einer CSV-Datei, die derart groß ist, dass ich die nur zeilenweise einlesen kann.

Bei dem Beispiel handelt es sich auch bei Bauteil ID = 200 um das Gleich Bauteil, dazwischen werden nur andere Bauteile bearbeitet. Für die Analyse muss ich aber jedes Bauteil separat betrachten. Deswegen diese Sortierung....

Den Algorithmus für die Analyse hab ich bereits erstellt und sollte auch kein Problem darstellen (zumindest zurzeit nicht ).

 

[vanny]

Nun ja,
ich hoffe du verstehst, dass man ohne den genauen Inhalt der Quelldatei zu kennen auch nur raten kann, was alles sortiert beachtet werden muss.

Ich entnehme aber deinem letzten Post, dass die BauteileID schon mal ein Sortierkriterium ist und anscheinend erst danach die zeitliche Sortierung eine Rolle spielt.

Wenn dem so ist, dann würde ich auch genau so verfahren. Erst die Bauteile raussammeln und dann sortiert nach Datum analysieren und ablegen.

Mal davon ausgehend, dass nur 200 BauteileIDs gleichmäßig in deiner CSV vorkommen sind das bei 400000 Datensätzen nur noch 2000 Datensätze, die du im Speicher verwalten müsstest.
Ich glaube aber es sind mehr Bauteile und wahrscheinlich nur 1-10 Datenätze pro BauteileID und somit solltest du dein Programm locker rödeln lassen können.

Hoffe du verstehst, worauf ich hinaus will.
Gruß Vanny

//EDIT: Wenn du große Datenmengen verarbeiten willst und an den Punkt kommst, das nach einem Teil alles nur noch im Schneckentempo läuft, weil du dir den Speicher vollpumpst, dann arbeite am besten Schrittweise und gib dem GC genug zu tun, anstatt (falls man Datenbanken so bezeichnen könnte) an der Peripherie zu schrauben

 

[turtle]

Ich werfe mal in den Ring, dass man auch mit SQL-Befehlen auf CSV-Dateien zugreifen kann.

Dabei musst Du "nur" einen ODBC-Verbindung (Text Driver) zur CSV-Datei einrichten und kannst dann "normal" mit JDBC zugreifen, also ein "select ... order by <Kriterieren>" absetzen und auf der sortierten Menge operieren.

 

[hansmueller]

Hallo,

weist du ob H2 bei einem Aufruf gleich alles in den Speicher geladen wird? Ich muss ja die gesamten Daten noch sortieren und auswerten.

Keine Ahnung. Es gibt eine Möglichkeit die Datenbank beim Start komplett in den Speicher zu laden. Nennt sich in-Memory-Mode -> Features
Aber ich glaube, darauf willst du gar nicht hinaus.

Wirf vielleicht mal einen Blick auf diese Links:
Advanced
und
Features

MfG
hansmueller

 

[homer65]

Diese ganzen embedded Datenbanken sind eben nur Spielzeug. Nimm besser eine richtige Datenbank. Für die stellen 80MB keinerlei Problem dar. Selbst MySQL wäre schon ausreichend.
Und wenn du den gesamten Bestand sortieren willst, dann verzichte am besten auf Indizes.
Falls du doch Indizes brauchst, ist es besser die nach dem Laden der Daten anzulegen.

 

[robertpic71]

Diese ganzen embedded Datenbanken sind eben nur Spielzeug.

Das würde ich so nicht unterschreiben. Speziell für Analyse wird gerne eine "Memory-lastige-DB" vorgelegt z.B. für OLAP-Systeme (z.B. Mondrian). Die Schwächen der embedded DB's zeigen sich mMn eher im Mulituser und Multitierbereich.

@Plopp
Zu deinen Performanceproblemen. Wie sieht es den mit Commit aus? Eine mögliche Ursache ist, dass alles in eine Transaktion gepackt wird - große Transaktionen bringen viele Datenbanken (auch nicht embedded) zum Schwitzen.

Auch Autocommit macht die Sache langsamer, da auf jedes INSERTein COMMIT erfolgt.

Wenn mit SQL:
prepared Statement
Zähler alle 1000 INSERT's + am Ende

bzw. H2 hat auch CSVIMPORT Tool.

Bei H2 wird eine Tabelle per Default nicht in den Memory gelegt. Man kann die Tabellen aber in verschiedenen Stufen (nur Index, alles) als Memory-Tabelle erzeugen. Alternativ kann die Datenbank gleich als Memory-DB gestartet werden.

Was hier für dich passt, hängt wohl davon ab, ob du dir die Daten in der DB dauerhaft speichern willst - oder ob du sowieso bei jedem Start die CSV neu importieren willst.

Ob eine Datenbank für deine Anforderung die optimale Lösung ist, kann ich aufgrund der Angaben nicht 100% sagen. Aber mit H2 (als Memory bzw. auch als embedded DB) habe ich sehr gute Erfahrungen gemacht. Durch den entfallenen TCP-Stack und die "Singleuser-Optimierung" ist die H2-Datenbank bei solchen Anwendungen in der Regel viel schneller wie herkömmliche DB's.

Im Normalfall sollten auch für alle sortierbaren Felder ein Index angelegt werden.

 

[Guybrush Threepwood]

Diese ganzen embedded Datenbanken sind eben nur Spielzeug. Nimm besser eine richtige Datenbank. Für die stellen 80MB keinerlei Problem dar. Selbst MySQL wäre schon ausreichend.

Kannst Du diese persönliche Meinungsäußerung auch irgendwie belegen? Wenn Du eine "richtige" Datenbank willst, dann brauchst Du eben auch die passende Hardware. Bei den eingebetteten Datenbanken ist das wohl nicht anders. Und mal ganz davon abgesehen lässt sich H2 sowohl eingebettet, als auch im Server-Modus betreiben.
Hier mal ein Vergleich zwischen H2 und MySQL, beide im Servermodus: Hibernate & H2 vs Hibernate & MySQL - Performance Comparison (Zellen mit gelblichem Hintergrund markieren bessere Performance)

Und hier H2 embedded und MySQL als Server: Hibernate & H2 embedded vs Hibernate & MySQL - Performance Comparison

Fazit:

A large performance gap has been detected when using graphs of objects with small transaction/retrieval size. Comparing the normalized speed of Hibernate with MySQL database server (1.1) to the normalized speed of Hibernate with H2 embedded database (5.4) reveals that in that case, Hibernate with H2 embedded is 4.9 times faster than Hibernate with MySQL server.

 

[homer65]

Kannst Du diese persönliche Meinungsäußerung auch irgendwie belegen?

Kann ich leider nicht. Es sind tatsächlich nur persönliche Erfahrungswerte.

 

[nrg]

habe jetzt nicht alles gelesen aber ich würde h2 empfehlen. Habe das mal mit einer CSV-Datei von 1mio Datensätzen (ca. 40 Spalten) getestet und es dauerte gerade mal 17s (auf einem damals nicht sehr gutem Laptop)

 

[fastjack]

Wieviel hat Hibernate bei den Performance-Vergleichen gefressen? Solche Vergleiche sind meistens sehr einäugig. Wie schauts z.B. mit mehreren gleichzeitigen Benutzerzugriffen aus? Das eine Embedded womöglich einen Tick schneller ist als MySql oder MsSql hat da wenig zu sagen, vielleicht verreckt sie dafür an 10 gleichzeitigen Nutzern, womit die anderen wieder kein poblem haben Die passende Hardware braucht man natürlich auch, da hat Guybrush recht, ansonsten halte ich es wie homer65.

Bei einem Einmal-Import wie diesem, würde ich:

* kein ORM benutzen
* MySql mit MyIsam-Betrieb nehmen, wenn Du in einer Firma hockst, gibt es da bestimmt einen Server, den Du benutzen darfst
* Geeignete Tabelle(n) erzeugen, überlegen, wo Indizes gut sind und die Tabelle(n) gleich so vorbereiten
* CSV häppchenweise einlesen und in die Datenbank schreiben. Bei 400.000 Inserts schaffst Du vielleicht 10-20K pro Minute, vielleicht auch ein paar mehr, also hält es sich noch in Grenzen
* dann die Analysen fahren

400.000 Zeilen sind noch viel zu süß um groß zu sein, eher putzig

 

[fastjack]

habe jetzt nicht alles gelesen aber ich würde h2 empfehlen. Habe das mal mit einer CSV-Datei von 1mio Datensätzen (ca. 40 Spalten) getestet und es dauerte gerade mal 17s (auf einem damals nicht sehr gutem Laptop)

1M inserts in 17s Sekunden? Mit Java JDBC oder einem Tool für die Embedded um CSV zu importieren?

 

[maki]

fastjack, ich würde auch bei einem (einmaligen) Import keine MyISAM Tabellen verwenden, ausser die Datenkonsistenz ist nicht wichtig

 

[nrg]

Mit Java JDBC oder einem Tool für die Embedded um CSV zu importieren?

mit JDBC. Waren aber anscheinend doch etwas weniger Spalten. Ich habe es jetzt nochmal getestet und h2 braucht für 1mio Datensätze a 20 Spalten (je ca. 10 Zeichen) 45 sec. Die CSV-Datei ist 227MB groß, die Datenbank danach 722

 

[robertpic71]

...Wie schauts z.B. mit mehreren gleichzeitigen Benutzerzugriffen aus? Das eine Embedded womöglich einen Tick schneller ist als MySql oder MsSql hat da wenig zu sagen, vielleicht verreckt sie dafür an 10 gleichzeitigen Nutzern,...

Nach dem der Threadersteller (Plopp) auch XML & Co. bzw. Memory-Lösungen in Betracht zieht, handelt es sich bei ihm wohl um eine "Singleuser" Anwendung.

ich zitier mich mal selber:

...Durch den entfallenen TCP-Stack und die "Singleuser-Optimierung" ist die H2-Datenbank bei solchen Anwendungen in der Regel viel schneller als herkömmliche DB's.

Ich betreibe hier in der Firma enige h2-Instanzen. Wir haben die volle Palette an Anwendungen:
größere und kleinere Datenbanken (50-500MB und eine 3GB Ram-Datenbank für OLAP), Plain-JDBC und Hibernate, SingleUser und Multiuser (bis zu 150 concurrent Users).

Ich arbeite weiters noch mit DB2, MSSQL, Oracle, PostreSQL, und MySQL (innoDB) - aber für bestimmte Anwendungen (sowie diese hier) ziehe ich H2 allen anderen vor. Für mich ist H2 alles andere als ein Spielzeug.

 

[fastjack]

fastjack, ich würde auch bei einem (einmaligen) Import keine MyISAM Tabellen verwenden, ausser die Datenkonsistenz ist nicht wichtig

die Inkonistenzen habe ich persönlich allerdings noch nie erlebt.

 

[Plopp]

Erst einmal vielen Dank für die ganzen Kommentare, ein großes Lob an das Forum… :toll:

@turtle
Das man mit SQL Befehlen CSV Dateien bearbeiten und durchsuchen kann wusste ich garnicht, das ist auf jeden Fall gut zu wissen. Weist du, ob er dabei die gesamt Datei in den Speicher laden muss? Ich vermute das mal…

@robertpic71, hansmueller, nrg
Das mit der h2 DB behalte ich mal im Auge und werd mich mal genauer damit befassen. Für meinen speziellen Fall hört sich das nach einer sehr guten Lösung an. :rtfm:
Gerade nach der Praktischen Erfahrung von robertpic71 macht mir eine Embedded-Lösung wieder Mut…
(Mit HSQLDB hat das nicht funktioniert…. langes Warten, Programmabstürze und Speicherüberlastung waren die Folgen, auch mit einer Speichererweiterung auf 1024mb)

@alle
Ich habe mich bisher nach mehrfachen Versuchen mit HSQLDB nach Homer65 und fastjack gehalten, und eine externe Datenbank (MySQL) getestet.
Da ich für eine Zwischenspeicherung allerdings einen großen Datenverkehr über einen Server vermeiden möchte habe ich eine lokale MySQL Datenbank bevorzugt (mit Xampp).

Für eine Langzeitanalyse nutze ich aber noch die Serverdatenbank, da die Daten nicht andauernd gelöscht und gespeichert werden. Ist aber ein anderes Thema.

Mein bisheriges Ergebnis mit MySQL…
MySQL läuft super damit.
Einspielen der Daten ca. 2min bei ca. 10mb Speicherauslastung bei meinem Programm (MySQL benötigt allerdings auch noch Speicher, den ich nicht beobachtet hab). Dabei hab ich mit ALTER TABLE jede Zeile einzeln integriert.
Bei der Auswertung, also das Abholen der Daten, ist allerdings darauf zu achten nicht zu viele Zugriffe durch „SELECT … FROM …. WHERE … ORDER BY“ -Befehle zu generieren, sondern ein gesundes Verhältnis zwischen Speicherauslastung und der Anzahl an Aufrufen zu treffen….
Ich habe erst jedes Bauteil einzeln abgeholt(über 150.000 Aufrufe). Da jeder Aufruf ca. 0,5 - 1s gedauert hat, hätte das mehrere Tage dauern können.
Ich habe dann, nach einer anderen Auswahl, gleich mehrere Daten bei einem Aufruf abgeholt (ca. 300 Aufrufe). Die Speicherauslastung lag bei ungefähr 25mb (GC kam hin und wieder zum Einsatz) und die Analysezeit bei weiteren ca. 2 min.
Mit diesen Werten hätte ich nicht gerechnet….bin mehr als zufrieden bei derartigen Datenmengen und dem Fehlversuch mit HSQL.
Werde aber auf jedenfall h2 noch testen und, wenn ich das nicht vergessen sollte, ein Bericht hier im Thread nachtragen.
Ansonsten vielen Dank an alle für eure Hilfe

Gruß
Plopp

 

[robertpic71]

Noch zur Vervollständigung:
CREATE TABLE bei HSQL erzeugt per Default eine Memory-Tabelle - das erklärt auch den hohen Speicherverbrauch. Als Nebeneffekt führt das auch zu etwas längeren Zeiten für das Öffnen und das Schließen der HSQL-DB. Eine "normale" Tabelle wird bei HSQL mit CREATE CACHED TABLE erzeugt.

H2 legt per Default keine Memory-Tabelle an - sondern nur den Index. Bei Einzelzugriffen (über den Index) sollte das ähnlich schnell sein - wie eine Memorytabelle. Auch dort ist aber eine Memorytable möglich.

Den (JVM) Speicherverbrauch zwischen einer embedded-DB und dem Clientteil einer Server-DB hinkt natürlich.

Unabhängig von der verwendeten DB:
Bei vielen gleichartigen Zugriffen: PreparedStatements
CREATE INDEX für die Abfrage bzw. Gruppenfelder