High Performance Spatial Computing mit Oracle 12c
Teil I: Grundlagen und Ressourcenoptimierung
Datenbanken können weit mehr als nur Daten und schnelle Views bereitstellen. Immer schnellere Systeme und ein immer größerer Funktionsumfang ermöglichen es, auch komplexe Projekte vollständig in der Datenbank zu bearbeiten. Hier präsentieren wir dir einige unserer Erfahrungen mit Oracle 12c, High Performance sowie Tipps und Tricks zum Spatial Computing.
Anfang 2014 startete Disy ein großes Kundenprojekt, in welchem diverse Herausforderungen gemeistert werden mussten. Inhaltlich ging es um die Aufbereitung heterogener Geometrie- und Sachdaten zu einem konsistenten Gesamtdatenbestand, der für eine anschließende Weiterverarbeitung in Modellrechnungen benötigt wurde.
Das gesamte Projekt stand unter extremem Zeitdruck, so dass keine klassische Projektdurchführung möglich war. Die Daten mussten in sehr kurzer Zeit analysiert und bzgl. ihrer grundsätzlichen Eignung für die Fragestellung qualifiziert werden. Anschließend waren sie attributiv aufzuwerten, mit Blick auf Relevanz zu filtern und räumlich zu verschneiden.
Heruntergebrochen in Teilschritte bedeutete dies über 250 Algorithmen. Damit die Projektdurchführung in der verfügbaren Zeit möglich war, musste auf getrennte Implementierungs-, Software-QS- und anschließende Berechnungsphasen verzichtet werden. Und selbst dann war der Zeitplan nur mit absoluter Höchstleistung des Systems und kreativen Lösungen zu stemmen.
Grundlegende Entscheidungen
Oracle 12c
Unter diesen Umständen kam für die Berechnungen nur eine Lösung direkt in der Datenbank in Frage.
Damit stand eine schwierige Entscheidung an. Sollten wir auf die bewährte und bei uns vielfach erprobte Funktionalität von Oracle 11g setzen, oder es mit Oracle 12c im Release 1 probieren?
Letztendlich gab die Erwartungshaltung an die Rechenzeit den Ausschlag mit Oracle 12c ins Rennen zu gehen.
Die umfangreichen Optimierungen der gesamten Spatial-Funktionalitäten, und hier besonders die
Spatial Vector Acceleration
(SPATIAL_VECTOR_ACCELERATION = TRUE;), gaben den entscheidenden Ausschlag.
Bei einem Projekt dieser Größenordnung ist es zu erwarten, dass man auf Fehler stößt, insbesondere wenn frische Softwarereleases genutzt werden. Die in Oracle 12c gefundenen Probleme wurden alle durch Hotfixes sehr schnell gelöst oder konnten durch einfache Workarounds umgangen werden. An dieser Stelle noch einmal vielen Dank an Oracle Deutschland für die sehr gute Zusammenarbeit.
Ein Beispiel für ein Problem war die Nutzung der Pufferfunktion
SDO_GEOM.SDO_BUFFER,
die eine Pufferfläche um existierende Geometrien berechnet.
Unter bestimmten Umständen konnte diese Funktion falsche Ergebnisse liefern.
Ein anderes Beispiel war die häufig verwendete Funktion
SDO_AGGR_UNION
zur räumlichen Vereinigung von Geometrien.
Wurde diese in Schleifen verwendet, passierte es, dass die Prozedur ohne eine informative Fehlermeldung einfach abgebrochen ist.
Solaris
Das zweite zentrale Element zur Einhaltung des Projektplans war neben der Verwendung von Oracle 12c das von uns gewählte Server Setup, auf dem die Datenbank installiert wurde. Für maximale CPU- und I/O-Performance sowie Stabilität setzten wir auf Solaris mit ZFS als Dateisystem sowie Solaris-Zonen.
In einer RAM-Disk waren sowohl die komplette Datenbank installiert, als auch I/O-kritische Tablespaces abgelegt. Weitere Tablespaces mit normaler I/O-Last wurden auf einem Storage abgelegt. Durch die LZ4-Kompression von ZFS und Hyper-Threading standen dem Projekt somit 500 GB RAM und 60 Kerne zur Verfügung sowie weitere 1500 GB auf dem Storage. Durch Snapshots, welche auf ein zweites Solaris-System repliziert wurden, war keine Ausfallzeit für ein Backup des Systems notwendig.
Dadurch waren wir in der Lage, im Falle eines Fehlers sehr schnell und einfach auf den letzten bekannten Snapshot zurückzugehen. Durch die schnellere Berechnung wurde der Zeitverlust durch Rücksprünge auf bis zu zwei Tage alte Snapshots mehr als aufgewogen. Entsprechende Mechanismen ermöglichten es, die Oracle Datenbank ohne Verzögerung in Betrieb zu nehmen. Zunächst mit Performance-Einschränkungen; sobald alle Daten auf die RAM-Drives migriert waren (ca. 4 Stunden nach einem Systemneustart), stand dann die volle I/O-Performance zur Verfügung.
Maximale Auslastung
Um die maximale Rechenleistung zu erreichen, mussten alle verfügbaren CPU-Kerne durchgängig ausgelastet werden. Solange es berechenbare Schritte gab, sollte kein Thread ungenutzt bleiben!
Letztendlich blieben wir kurz unter diesem Ziel. Von 64 CPU-Kernen wurden 60 Kerne für die Berechnung verwendet. Die restlichen 4 Kerne blieben dem Betriebssystem und dem Datenbanksystem als solchem vorbehalten, da es für die Performance von Oracle 12c nicht förderlich ist, wenn zu viele Threads aus Hintergrundprozessen auf den gleichen Kernen laufen.
Disy Spatial Workbench
Für die Ablaufsteuerung haben wir mit der Disy Spatial Workbench über die Jahre ein eigenes Framework in Java entwickelt. Die Workbench verwaltet vollautomatisch alle verfügbaren Threads und kennt die noch offenen Aufgaben mit entsprechenden Abhängigkeiten. Solange rechenbereite Aufgaben vorliegen, werden diese in logisch sinnvoller Reihenfolge gestartet.
Im Falle eines Fehlers wird die entsprechende Aufgabe protokolliert und übersprungen, so dass der Thread direkt freigegeben wird. Damit ist es möglich, von dem Fehler unabhängige, weitere Berechnungen direkt neu zu starten, ohne dass die Threads blockiert bleiben.
Als Trade-Off dieses Ansatzes konnten wir die von Oracle über SQL direkt nutzbare parallele Verarbeitung von Statements nicht verwenden. Damit hätten wir die Kontrolle über die Threads aus der Hand gegeben, was in Summe wahrscheinlich Rechenzeit gekostet – auf jeden Fall aber die Zahl der grauen Haare in die Höhe getrieben – hätte.
Ausblick
Mit diesen kniffligen Voraussetzungen stellte sich schlussendlich die Frage wie wir bei komplexen geometrischen Aufgaben mit Oracle 12c zum Ziel kommen würden. Lies im nächsten Beitrag wie wir das geschafft haben.
Das Titelbild Too Busy To Improve wurde von Alan O'Rourke unter CC-BY 2.0 veröffentlicht. Wir haben “Errr…” verschoben und den Ausschnitt geändert.
Teilen via
