Best Practice Große Anzahl an Objekten speichern und lesen

[Fabse]

Hallo zusammen,

ich habe viele (>100) .csv Dateien. Eine einzelne .csv Datei ist zwischen 10mb und 88mb groß und hat zwischen 300.000 und 2.330.000 Zeilen. Diese .csv Dateien habe ich ausgelesen und in ein Java Objekt gepackt.

    private final Date date;
    private final BigDecimal bid;
    private final BigDecimal ask;
    private final BigDecimal middle;

Das "date" parse ich mit einem SimpleDateFormat. "bid" und "ask" kann ich direkt aus der .csv Datei auslesen. "middle" errechnet sich aus "bid" und "ask" (("bid" + "ask") / 2).
Dann hat mein Objekt noch einen simplen getter für jedes Feld.

Dieses Objekt speichere ich dann auf meine Festplatte ab.

       ObjectOutputStream out = null;
       try {
           out = new ObjectOutputStream(new FileOutputStream(filename));
       } catch (IOException e) {
           e.printStackTrace();
       }
       for (CandleStickTick candleStick : listCandleStick) {

           try {
               out.writeObject(candleStick);
           } catch (IOException e) {
               e.printStackTrace();
           }
       }

Das abgespeicherte File hat dann eine Größe zwischen 18Mb und 400mb. Hat sich von der Größe her also vervierfacht!

Wenn ich das File dann wieder lade über:

       List<CandleStickTick> result = new BigList<>();

       File file = new File(filename);

       try {

           if (file.exists()) {

               System.out.println("Load: "
                                  + filename);

               ObjectInputStream in = new ObjectInputStream(new FileInputStream(filename));
               try {
                   CandleStickTick candleStick = null;
                   while ((candleStick = (CandleStickTick) in.readObject()) != null) {
                       result.add(candleStick);
                   }
               } catch (EOFException e) {
   
               }

               finally {
                   in.close();
               }
           }
       } catch (Exception e) {
           e.printStackTrace();
       }

Dauert das Laden der java objekte bei einem 210mb java file (47mb csv) 110 Sekunden.

Wie kann ich das beschleunigen? Hat da jemand einen Tipp?

Vielen Dank!!

 

[Thallius]

Eine Datenbank benutzen?

 

[Fabse]

Ah sehr gute Idee Thallius. Danke dafür. Habe jetzt mal mit einer hsql DB rumgespielt.
Habe dann versucht alle csv Dateien in eine tabelle zu pumpen. Aber nach ein paar Millionen Datensätzen wurde das Programm extrem langsam und ich habe es abgebrochen. Wahrscheinlich läuft der Speicher voll?
Ist hsql für große Datenmengen geeignet? Muss ich es evtl. nur anders verwenden? Einstellungen ändern oder mehrere Tabellen anlegen?
Insgesamt habe ich wohl über 200 Millionen Datensätze...

 

[Thallius]

Als erstes solltest Du dir mal die Frage stellen ob Du wirklich alle 200Mio Datensätze brauchst. Wenn ja, dann wirst du wohl um eine Skalierung nicht herum kommen. Ich habe keine Ahnung wie die Datensätze aufgerbaut sind aber wahrscheinlich kann man die in Blöcke aufteilen. z.B. nach Datum oder Quelle oder sonstwas. Dann muss halt jeder Block auf einen eigenen Rechner mit eigener Datenbank etc.

Aber das ist eher was für Leute die sich mit sowas auskennen. Als hobbyprojekt wird das wirklich schwer werden.

Gruß

Claus

 

[truesoul]

Hallo Fabse,

bei solchen Datenmengen ist es vll. sinnvoller auf NoSQL Datenbanken zu setzen. Sprich Dokumentenbasierte Dantenbanken. Aber wie schon Thallius schon sagt als Hobbyprojekt könnte es schwer werden.

Zudem solltest du mit Threads gut auskennen.

https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html

Wenn du welche Framework's für ORM (Object-Relational Mapping) verwendest solltest du diese auch gut studieren.

Grüße

 

[Meniskusschaden]

Ich sehe eigentlich nicht, inwieweit dokumentbasierte DBs oder ORM hier weiterhelfen. Es ist ja eine sehr einfache Struktur und die Herausforderung liegt "nur" im Volumen. Ich würde dem Vorschlag von @Thallius folgen und unter dem Thema Datenbank-Partitionierung recherchieren. Habe ich zwar noch nie benutzt, könnte mir aber vorstellen, dass man da nicht alles selbst machen muß, sondern die DB einen unterstützt.

 

[truesoul]

Ich sehe eigentlich nicht, inwieweit dokumentbasierte DBs oder ORM hier weiterhelfen.

Ich habe nicht empfohlen auf ORM zu setzen, nur wenn er auf dies aus setzt, sollte er sich damit befassen. Und NoSQL Datenbanken wie z.B Hadoop sind dafür ausgelegt großen Datenmengen abzuspeichern und wenn man wüsste wie die Datenstruktur ausschaut ist sicherlich sowas wie z. B MongoDB auch geeignet.

Und gegen Datenbank-Partitionierung spricht auch nichts, nur ist es erwähnenswert auf NoSQL Datenbanken hinzuweisen.

 

[Fabse]

Datenstruktur ist simpel wie oben angegeben:

private final Date date;
    private final BigDecimal bid;
    private final BigDecimal ask;
    private final BigDecimal middle;

Was ich genau für ein Date,Timestamp usw. weiter nehme weiß ich noch nicht. Aber zum Abspeichern auf die DB nehme ich einfach nen Timestamp. Ich könnte die Tabellen noch nach Jahr und Monat aufteilen, wenn das was bringen würde oder zusätzliche Spalten.

Ja ich brauche alle Datensätze...wenn ich alle Datensätze in der DB drin habe, wäre mein Vorgehen immer einen Monat in den Speicher zu laden und dann mit den Daten zu arbeiten, wenn diese fertig sind die nächsten usw.

 

[truesoul]

Also Hadoop mit Hive wäre ein Blick wert.

https://www.bigdata-insider.de/was-ist-hive-a-654184/

 

[Thallius]

Dann mach doch erstmal pro Jahr oder Monat oder Tag eine Tabelle, so dass in einer Tabelle nicht mehr als 1Mio Datensätze liegen. Dann hast du zwar 200 Tabellen, diese trennt die DB aber physikalisch so dass du weniger RAM brauchst. Keine Ahnung ob das ein "normaler" PC dann noch schafft aber ein Versuch ist es wert. ISt natürlich immer noch nur eine Krücke aber vielleicht reicht es für Deinen Zweck

Gruß

Claus

 

[pinhead84]

Ah sehr gute Idee Thallius. Danke dafür. Habe jetzt mal mit einer hsql DB rumgespielt.
Habe dann versucht alle csv Dateien in eine tabelle zu pumpen. Aber nach ein paar Millionen Datensätzen wurde das Programm extrem langsam und ich habe es abgebrochen.

Ich halte den Weg über eine Datenbank - egal ob HSQL, H2, MySQL oder PostgreSQL - für den besten Weg. Eigentlich sollte jede der genannten Datenbanken mit der Datenmenge umgehen können. NoSQL-Gedöns funktioniert sicherlich auch.

Standardmäßig hält HSQL die Daten im Arbeitsspeicher vor. Wenn das Programm immer langsamer wird, könnte dies auf einen Engpass beim von der JVM reservierten Arbeitsspeicher hindeuten. Die JVM führt dann permanent eine Garbage Collection durch - in der Hoffnung, dass Speicher wieder frei wird - und es bleibt kaum noch Zeit für die eigentliche Anwendung.

Lange Rede, kurzer Sinn: Erhöhe testweise mal den verfügbaren Arbeitsspeicher der JVM, ändere die Konfiguration von HSQL auf "cached tables" oder steige auf eine andere Datenbank um.

 

[JuKu]

Also HSQL ist für dein Szenario denkbar ungeeignet. Wie Wikipedia schreibt:

Memory only: Alle Daten werden nur im Speicher vorgehalten und nicht auf dem Datenträger gespeichert. Änderungen gehen beim Beenden des Servers (bzw. der Applikation im Standalone-Modus) verloren.

D.h. alle 200 Mio. Datensätze wären dann im RAM.

MySQL & PostGreSQL sind beides relationale Datenbanken, d.h. sie können - je nach Anwendung - Abhängigkeiten besitzen und skalieren demnach nicht so gut.
Was du auf jeden Fall brauchst, ist ein Datenbanken Cluster. Denn 200 Mio. Datensätze auf einem Rechner schafft kein gewöhnlicher Computer in kurzer Zeit. Zumindest wäre das auch nicht sinnvoll.

Ich persönlich halte sogar eine NoSQL Datenbank für die bessere Lösung.
Die "Großen" wie z.B. Twitter, Facebook & Google setzen z.B. auf Cassandra (Facebook), HBase (Twitter) oder "Big Table" (Google), wobei letzteres wieder sehr ähnlich zu HBase ist.
Cassandra ähnelt einer relationalen Datenbank wohl noch am meisten, deshalb würde ich an deiner Stelle auf Cassandra setzen (falls du bereits Erfahrung mit relationalen Datenbanken hast).

 

[mrBrown]

Also HSQL ist für dein Szenario denkbar ungeeignet. Wie Wikipedia schreibt:
D.h. alle 200 Mio. Datensätze wären dann im RAM.

HSQLDB hält nicht zwingend alles im Speicher, der kann das durchaus auch auf der Platte cachen...

Ich persönlich halte sogar eine NoSQL Datenbank für die bessere Lösung.

Halte ich für die falsche Lösung - hier sinds strukturierte Daten ohne Relationen, da gewinnt man nichts mit NoSQL, vermutlich verliert man eher Performance...

 

[pinhead84]

Also HSQL ist für dein Szenario denkbar ungeeignet. Wie Wikipedia schreibt:
D.h. alle 200 Mio. Datensätze wären dann im RAM.

Das ist gefährliches Halbwissen. - Man kann in HSQLDB global oder für jede Tabelle einzeln definieren, ob diese

(a) temporär und vollständig im Arbeitsspeicher liegen sollen,
(b) permanent gespeichert und beim Programmstart vollständig in den Arbeitsspeicher geladen werden sollen oder
(c) permanent gespeichert und nur nach Bedarf in den Arbeitsspeicher geladen werden.

Bei H2 ist dies sicherlich ähnlich und bei MySQL / PostgreSQL erübrigt sich die Frage.

Was du auf jeden Fall brauchst, ist ein Datenbanken Cluster. Denn 200 Mio. Datensätze auf einem Rechner schafft kein gewöhnlicher Computer in kurzer Zeit. Zumindest wäre das auch nicht sinnvoll.

Grundsätzlich sollte jede (sinnvoll konfigurierte) Datenbank mit diesen Datenmengen umgehen können. Ob SQL oder NoSQL - ob embedded (HSQL / H2) oder als Server / Cluster - es hängt vom Anwendungsfall, dem Einsatzzweck, den Kundenvorgaben und auch den persönlichen Vorlieben ab, welche Lösung man am besten einsetzen sollte.

 

[truesoul]

Meine Erfahrungen sagen da was anderes. Zwei Projekte umgesetzt wo jeden Tag bis zu 30 Mio. Datensätze rein kamen. Und mit Relationalen Datenbanken ist es faktisch nicht möglich diese von der Performance abzuspeichern und auszulesen. Dafür sind von @JuKu erwähnten Datenbanken halt geschaffen. Die Daten hatten auch keine Relationen unter einander. Ich würde einfach mal ein Versuch starten und eine NoSql verwenden. Google und Co. können sich nicht irren... Beruflich wird das sicher zu keinen Nachteil sich auch damit mal beschäftigen

https://www.techworm.net/2013/05/what-database-actually-facebook-uses.html

 

[mrBrown]

https://www.techworm.net/2013/05/what-database-actually-facebook-uses.html

Facebook primarily uses MySQL for structured data storage such as wall posts, user information, timeline etc

Hm...aber wie ihr schon sagtet, die Großen können nicht irren, also wohl doch kein NoSQL

 

[truesoul]

Hm...aber wie ihr schon sagtet, die Großen können nicht irren, also wohl doch kein NoSQL

Na mit dem link ins eigene Bein geschossen

Scherz beiseite. Einfach mal Casandra im Cluster vs MySQL. Und dann beurteilen was besser ist.

Grüße

 

[Meniskusschaden]

Habe dann versucht alle csv Dateien in eine tabelle zu pumpen. Aber nach ein paar Millionen Datensätzen wurde das Programm extrem langsam und ich habe es abgebrochen.

Im Moment ist das Problem offenbar noch die Datenübernahme. Es ist ja noch gar nicht klar, ob es danach im regulären Betrieb überhaupt Performance-Probleme gibt. Es müssen ja sicher nicht jeden Tag 200 Millionen Sätze importiert werden. Ich würde mich deshalb zunächst auch etwas mit dem Thema Bulk Loading beschäftigen, um die Erstbefüllung zu beschleunigen.

 

[samatthias]

Hallo Zusammen

Ich werfe mal Apache Ignite (oder Hazzlecast) in den Raum. Beide über SQL Interfaces anzusprechen und extrem leistungsfähig, da RAM only.
Wichtig ist noch das Apache Ignite SQL ANSI 99 unterstütz. Wirklich sehr nett, wenn's denn adhoc sehr schnell gehen muss.
Ansonsten gibt es diverse Datenbanktechniken, mit dem man ohne Probleme optimieren kann: Indexes richtig legen, Partitionen in einer Tabelle erstellen. SQL Query Planer studieren (hat auch Mysql resp. MariaDB). Bei diversen Datenbanken gibt es auch InMemory Tabellen, die helfen können.
Oder man erstellt sich eine MySQL Instanz auf einer RAMDISK. Das hat auch swag.
Achtung beim Bulkload sollten unbedingt die Indexes vorher gedropped werden. Meiner Meinung nach ist das in den meisten Fällen schneller.

So genug gelabert für heute. Gute Nacht.

Beste Grüsse
Matthias

 

[JuKu]

Hm...aber wie ihr schon sagtet, die Großen können nicht irren, also wohl doch kein NoSQL

Na das stimmt ja so nicht.
Denn wo werden die Daten denn normalerweise abgerufen? Sicherlich nicht in der MySQL Datenbank, sondern in der NoSQL Datenbank! Die halten quasi alles im Memcache Cache vor.

The Facebook fleet has grown fairly dramatically of late. For example, Facebook is the largest Memcached installation and the most recent reports I had come across have 200 Memcached servers at facebook. At the Scaling MySQL panel, they report 805 Memcached servers.

Quelle: http://www.datacenterknowledge.com/archives/2008/04/23/facebook-now-running-10000-web-servers

Als nächstes muss gesagt werden, dass Facebook keine herkömmlichen MySQL Server verwendet, wie sie auf ihrer Seite schreiben. Stattdessen haben sie ihre eigene MySQL Storage Engine "RocksDB" entwickelt.

This led us to build MyRocks, a new open source project that integrates RocksDB as a new MySQL storage engine. With MyRocks, we can use RocksDB as backend storage and still benefit from all the features in MySQL.

Quelle: https://code.facebook.com/posts/190251048047090/myrocks-a-space-and-write-optimized-mysql-database/

Und laut Wikipedia nutzen sie nur Apache HBase fürs Messaging. Wieso wohl?
Vermutlich weil MySQL niemals so gut skalieren würde!
2010 haben sie von Apache Cassandra auf HBase umgestellt. Und Facebook schreibt auf der offiziellen Seite sogar, dass die MySQL Performance nicht ausreichte:

We spent a few weeks setting up a test framework to evaluate clusters of MySQL, Apache Cassandra, Apache HBase, and a couple of other systems. We ultimately chose HBase. MySQL proved to not handle the long tail of data well; as indexes and data sets grew large, performance suffered. We found Cassandra's eventual consistency model to be a difficult pattern to reconcile for our new Messages infrastructure.

HBase comes with very good scalability and performance for this workload and a simpler consistency model than Cassandra.

Quelle: https://www.facebook.com/notes/face...derlying-technology-of-messages/454991608919/

Und wenn wir schon dabei sind, Apache Cassandra wurde von Facebook initiert, bis sie es 2008 Open Source gemacht haben. Also kann es doch nicht schlecht sein, oder? Es wurde immerhin genau für riesige Datenmengen geschaffen!
Links:

• https://www.facebook.com/notes/face...derlying-technology-of-messages/454991608919/
• https://www.facebook.com/note.php?note_id=24413138919

@samatthias Du meinst Hazelcast, oder?