BigData - Milliarden Zeilen aus SQL Tables laden?
Anstatt direkt auf Stack-Overflow zu lümmeln möchte ich der deutschen Community mal ne Chance geben. In einem meiner Projekte geht es darum mehrere Millarden Zeilen an Relationalen Daten zu laden, lokal in einer DB zu speichern und dann in die Cloud zu laden.
- Nein wir haben keinen Zugang zum Azure Backbone
- Ja, traffic ist aktuell ein Problem aber nicht das Akute
Nun haben wir eine DB2 OnPrem und wir ich bisher in den Datagateways vorgegangen bin ist mit ORDER BY X OFFSET X FETCH FIRST X um die Datenmenge aufzuteilen und parallel abzuarbeiten.
Die o.g. Datenmenge von ein paar Milliarden setzen sich aus mehreren Tabellen zusammen, alle haben einen Primary Key. Jage ich nun eine Query mit Order-By über die Datenmenge, dauert das für 35k Datensätze ca. 2:15 Minuten.
Kurze Formel wegen dem Microbatching:
135 Sekunden * 256 (Microbratches) * 8 (Jobbatches) landen wir bei einer Ladezeit (READ ONLY) von ca. 76,8 Stunden.
Hat jemand von euch eine Idee, wie man das Problem angehend könnte?
Hier mein Lösungsansatz:
- Temptable der Quelle errichten, da ich auf die Quelle KEIN Lock setzen kann
- OrderBy weglassen und die physische reihenfolge des statischen Temptables als Faden für die Ingestion der Daten verwenden.
Mit dem Ansatz würde es nur ca. 12 * 256 * 8 Sekunden brauchen also 24.576 was durchaus akzeptabel wäre.
Für den Zukünftigen Real-Time Ansatz werden ohne hin in die Quellsysteme Events eingebaut, welche die eindeutige ID an die Gateways kommunizieren um die Daten in die Cloud zu transferieren. - Meiner Meinung nach der einzige Weg near-real-time in dieser Datenmenge zu realisieren (Gibts hier vielleicht alternative Vorschläge? - Ich kann ja nicht annehmen, dass jedes Quellsystem änderbar ist und ich möchte Insellösungen vermeiden)
Danke schonmal im Voraus :)
Grüße
1 Antwort
Auch die deutsche Community tummelt sich bei Stackoverflow…
Ich verstehe noch nicht, was Du eigentlich willst. Willst Du eine gespiegelte Datenbank in der Cloud einrichten? Warum machst Du nicht einen simplen SQL-Dump? Warum nutzt Du nicht die DB2-Mechanismen zur Replikation?
Und warum machst Du ein Order by? Das dauert doch nur extra. Du schreibst, Du willst irgendwas parallel abarbeiten. Wozu? Komplette Spiegelung in nicht-Echtzeit -> SQL-Dump. Komplette Spiegelung in Echtzeit -> Replikationsmechanismen nutzen, dafür sind sie ja da.
Vergiss den Unsinn mit Events. Das können die SQL-Server selber. Hier für DB2: https://www.ibm.com/docs/en/db2/11.5?topic=options-replication-tools-by-component
Ein Dump ist genau dazu da, effizient die Daten abzuziehen. Und der geht so schnell wie möglich auch für beliebige Datenmengen.
Die Reihenfolge der Ergebnisse ändert sich nicht zufällig, sondern ist deterministisch. Solange Du das gleiche Select machst, wird sich in der Reihenfolge nichts ändern - wenn zwischenzeitlich keine Schreibvorgänge erfolgten. Aber daran würde Dein bisheriger Ansatz ja eh scheitern. Jedenfalls: Wenn Du ein Order By machst, dann natürlich nur auf ein Feld mit einem Index.
Die Spiegelungsmechanismen nicht zu verwenden, ist dumm und ineffizient. Die sind ja dafür optimiert und getestet. Aber wenn es unbedingt sein muss: Mache das nicht innerhalb des SQLs mit Events, sondern nutze das Transaction-Log des SQLs und arbeite die mit einem Microservice ab. Leider speichert das DB2 nur in einem Binärformat und dann ist dieser Weg etwas aufwändiger. Dafür bist Du dann nicht mehr auf die Performance des SQLs angewiesen und kannst das in einer eigenen VM machen. Aber es gibt auch Software von Drittanbietern, die das Transaction Log auswerten.
Wer auch immer bei Euch die Nutzung der Replikationsmechanismen nicht wünscht, sitzt auf dem falschen Posten. Es geht doch hier sicherlich um eine Produktivumgebung und nicht um eine Azubi-Spielwiese?
@segler1968 Hab mir das mal angeschaut, werde das Ganze mal benchmarken.
Die Reihenfolge der Ergebnismenge kann sich tatsächlich zwischen SELECTS ändern, da sich auch die Query in sich ändert (OFFSET etc.) Ist aber eh egal, wenn das über Dumps wirklich so zu realisieren ist... Sich hier also alleine auf die physikalische Reihenfolge zu verlassen ist keine Möglichkeit
So eine Entscheidung als Dumm zu betiteln halte ich für sehr mutig... Es hat durchaus valide und nachvollziehbare Gründe, warum unser Architekt das nicht möchte. - Das hier zu erläutern würde unnötig Zeit rauben, es ist wie es ist und so wird es gemacht, also ohne Spiegelungsmechaniken. Das near-real-time gedudel habe ich über das Backup-Logging der Datenbank realisiert.
Es geht um eine Produktivumgebung.
ja, war etwas mutig formuliert. Und Adressat war eher die Community und nicht der Architekt :-)
Danke für den Tipp mit dem Dump, hast du hier Erfahrungen wenn es um Milliarden von rows geht?
orderby wird gemacht um die Reihenfolge pro batch zu sichern, da diese sich von SQL zu SQL Statement ändern könnte, habe hier schon an ein InBetween bei der ID gedacht.
das mit der Spiegelung über IBM bzw. mit den Replikationen ist so nicht gewünscht, es soll ein eigenes Tool sein, welches als Microservice skalierbar ist.