Zum Inhalt springen
  • Von: Marina Fischer
  • Datenbank
  • 26.10.2017

“Wir fürchteten, dass wir an die Grenzen der Datenbank stoßen würden”

Am CERN wird im Rahmen des ATLAS-Experiments eine sehr große Anzahl an Partikel-Kollisionen aufgezeichnet. Dadurch entsteht eine enorme Datenmenge, die unter der eingesetzten Oracle-Datenbank 11g verarbeitet und analysiert werden muss. Wie können Tausende Kollisionen pro Sekunde gehandhabt werden und was bedeutet das für das Datenbankdesign? Fünf Fragen an Gancho Dimitrov, Datenbankarchitekt am CERN und Referent bei der DOAG 2017 Konferenz + Ausstellung.

Herr Dimitrov, an welchen Projekten haben Sie in der letzten Zeit gearbeitet?

Ein besonders herausforderndes Projekt war für uns in der ATLAS-Datenbank-Community die Aufzeichnung der einzelnen Kollisionen im Rechengitter des „Large Hadron Colliders“ (LHC): Dies umfasst den Aufbau eines zentralen Katalogs von ATLAS-Ereignissen am CERN, in dem wir wesentliche Kennwerte jeder Partikel-Kollision in ATLAS erfassen und zusätzlich Verweise zu den relevanten Datendateien festhalten. Unser Katalog ist nun fertig gestellt und bietet uns eine wachsende Zahl an Anwendungsfällen für das Experiment mit hoher Leistungsfähigkeit. Darüber hinaus ist der Katalog dafür ausgelegt, Zeilen im Bereich von zweistelligen Milliarden pro Jahr zu laden und über Jahre hinweg skalierbar zu sein. Dieses System wurde von einem aus drei Personen bestehenden Kernteam konzeptioniert und installiert (Elizabeth Gallas, Petya Vasileva und mir). Jeder brachte dabei unterschiedliche Kenntnisse und Fähigkeiten in das Projekt ein.

Welche Herausforderungen begegneten Ihnen im Verlauf der Projektentwicklung?

Es gab viele technische Herausforderungen. Erst einmal haben die erwarteten 30 bis 35 Milliarden Zeilen pro Jahr natürlich einen erheblichen Datenbank-Ressourcenbedarf beim Speicher in Bezug auf Tabellen- und Indexsegmente. Weitere gravierende Herausforderungen waren die Datenladegeschwindigkeit, die Transaktionsgröße und das Datenbank-Undo-Volume. Da Daten in logische Einheiten von Datensätzen eingeteilt sind, mussten aus Datenkonsistenzgründen große Datenbanktransaktionen von Zeilen in zwei- bis dreistelliger Millionenhöhe pro Jahr unterstützt werden. Daraus folgt die Frage: "Was geschieht, wenn aus irgendeinem Grund eine aktive Transaktion in dieser Größenordnung zurückgerollt werden muss?" Solche Rollback-Operationen müssen ziemlich schnell sein. Unser System muss außerdem in der Lage sein, große Datensätze schnell zu ersetzen für den Fall, wenn die vorgelagerten Datenquellen ihre Inhalte aktualisieren. Zu guter Letzt gab es noch Herausforderungen beim Erreichen einer annehmbaren Datenbank-Antwortzeit beim Data-Mining und bei einer Vielzahl an einfachen Look-up-Suchen.

Wie haben sich die Voraussetzungen auf das Datenbankdesign ausgewirkt?

Ich musste einen sehr effizienten Ansatz im Bereich der Datenorganisation und Datenverdichtung entwickeln, um den benötigten Speicherplatz so klein wie möglich zu halten. Das hatte außerdem einen positiven Effekt bei der Minimierung des Sicherungsdatenträgers. Einige Elemente des passenden Datenbankdesigns für das System waren in der Community der Oracle-Datenbankentwickler noch nicht sehr weit verbreitet, sodass es an vielen Stellen der Bereitstellung Befürchtungen gab, dass wir auf einen Oracle-Bug oder an die Grenzen der Datenbank stoßen. Die gewählten Technologien erwiesen sich jedoch als robust und boten vor allem die erwarteten Vorzüge bei betrieblicher Kapazität und Performance.

Wie können Sie solch riesige Datenmengen beherrschen?

Ich habe so viele in Oracle 11g verfügbare Datenbank-Features wie möglich genutzt. Einige davon verwenden wir bereits seit Jahren und sie haben sich als sehr zuverlässig herausgestellt. Andere hingegen sind (relativ) neu oder nicht so gefragt. Beispiele sind Bulk Inserts und Datendeduplizierung, Listentypen-Partitionierung mit angepasster Speicherspezifikation und virtuelle Spalten. Bis zum heutigen Tag enthält das System etwa 120 Milliarden Zeilen, da die Datenverzehrrate über die ursprünglich vorgesehenen 30 Milliarden Zeilen pro Jahr hinausgegangen ist. Derzeit verwenden wir in ATLAS die Oracle Enterprise Edition 11.2.0.4 auf Rechnern im mittleren Bereich (20 CPU-Kerne und 512 GB RAM pro Maschine). Wir haben vier Oracle-Datenbank-Cluster, wobei jeder eine dedizierte Rolle und eine unterschiedliche Anzahl an Knoten hat, um eine Vielzahl an Datenbankanwendungen zu bedienen.

Was möchten Sie jemandem empfehlen, der eine möglichst effiziente und stabile Datenbank plant?

Als erstes ist die Gesamtbetrachtung wichtig. Versuchen Sie das Backbone Ihres Datenbanksystems so auszulegen und zu bauen, dass es mit Gewissheit funktioniert und dass Sie Erfahrung mit diesem Aufbau haben. Denken Sie stets an den Skalierungsaspekt. Bereiten Sie sich auf über die Zeit wachsende Anforderungen vor. Wenn den Benutzern Funktionalität und Performance Ihres Systems gefallen, werden sie mit Sicherheit nach mehr verlangen. Zweitens, auch wenn die Gesamtbetrachtung wichtig ist, kommt es auf viele kleine, aber entscheidende technische Details an. Besonders relevant sind die Wartungskosten über die Lebensdauer der Anwendung. Ich weiß, es ist einfacher gesagt als getan, da üblicherweise die Unternehmensaufgaben sehr komplex sind, aber versuchen Sie zu guter Letzt, das System auf Einfachheit auszulegen. Die Tendenz zum Overengineering wird mit hohen Kosten im Change Management einhergehen.

 

Veranstaltungshinweis:

Gancho Dimitrov berichtet bei der DOAG 2017 Konferenz + Ausstellung vom 21. bis 24. November in seinem Vortrag von seinen spannenden Projekterfahrungen am CERN.

Tickets und Anmeldung