Im Rahmen unserer Entwicklung an der Personalakten-Lösung der GIP GmbH haben wir die Bedingungen und möglichen Limitierungen einer Archivierungslösung auf Basis von Oracle-Datenbanken evaluiert. Dazu haben wir die Grundlagen für ein realitätsnahes Testsystem erarbeitet, welches für Lasttests und Produktentwicklung eingerichtet werden soll.

 

BLOB Datenarchivierung

 

Bereits in der aktuellen Version der KIDICAP.Personalakte werden Bilddaten (Thumbnails) als BinaryLargeObjects (BLOB) in der Oracle DB gespeichert. Daher konnten wir zumindest die technische Machbarkeit als unproblematisch bewerten. Hinsichtlich der generellen Tauglichkeit als Archiv bzw. Fileserver-Ersatz gibt es sowohl gute Gründe die dagegen1, als auch dafür2 sprechen.

 

Was spricht dafür BLOBs in Datenbanken zu speichern?

  • Die Daten sind im Datenbankschema sauber eingebunden und referenziert. Sie können also weder verwaisen, noch können die Referenzen auf die Daten plötzlich ins Leere zeigen.
  • In einem Datenbank-Dump sind sämtliche Daten enthalten: die strukturierten Daten und die BLOBs – was sowohl die Portierung als auch das komplette Zurücksetzen in einen früheren Zustand (Stichwort: Backups) erleichtert.
  • Je nach Datenbanksystem ist es möglich, die BLOB-Daten durch programmierbare Operationen auf dem Datenbankserver (Trigger, Rules, …) zu bearbeiten.
  • Die Rechteverwaltung ist deutlich leichter zu implementieren, wenn die BLOBs mit in der Datenbank liegen.

 

Welche Herausforderungen bringen BLOBs mit?

  • Der Komfort der Speicherung von BLOBs geht einher mit extrem hohen Anforderungen an die Datenbankadministration.
  • Viele Datenbanken werden sehr ineffizient, wenn vergleichsweise große BLOBs ( > 100 MB) zusammen mit anderen, sehr kleinen Objekten in derselben Tabelle gespeichert werden oder wenn eine Tabellenzeile mehr als ein BLOB enthält.

 

Welche Versionen werden unterstützt?

Oracle bietet seit Version 8i Verwaltungsmöglichkeiten für BLOBs (Binär-Daten), CLOB (Text-Daten mit 8-Byte-Codierung) und NCLOB (Unicode-Daten bis 4 GiB) an3.

Aus Kundenreferenzen von Oracle haben wir die Musterkonfigurationen einer Oracle Datenbank für unsere Tests abgeleitet. (Anwenderbericht: National Ignition Facility and 11G secure Files; Oracle OpenWorld 2007).

Die Mengengerüste und die Anforderungen des Referenzkunden an die Zugriffsgeschwindigkeit sind herausfordernd und liegen deutlich oberhalb der Schwelle, die für die Belange der KIDICAP.Personalakte charakteristisch ist (ca. 66 TB/Jahr). Des Weiteren haben sich Datenbankversionen laut der Kunden unterhalb von Oracle 11g als unbefriedigend herausgestellt.

Zusammenfassend empfiehlt sich also die Nutzung ab Oracle 11g SecureFiles für die Speicherung von Large Objects.

 

Unser Fazit

Oracle DBs lassen sich also als performantes Ablagesystem einrichten und sinnvoll verwenden. Allerdings müssen dazu einige Parameter erfüllt werden:

  • die Version der Datenbank (ab Oracle 11g )
  • nur ein File pro Tabellenzeile
  • nur kleinere Files (unter 100MB)
  • In allen Fällen ist es für die Performance entscheidend, dass die Netzwerkleitungen Leistungsstark dimensioniert sein müssen, dies war in unseren Tests der geschwindigkeitsbestimmende Schritt.

Für unseren Projektfall, der Personalakte, werden lediglich Files im einstelligen Megabyte- oder sogar nur im mittleren Kilobyte-Bereich verwendet. Daher erwarten wir, dass keine Performance-Probleme bei der Verwendung von Oracle-Datenbanken als Archiversatz auftreten werden. Mindestens für mittelgroße Installationen die bereits Oracle im Einsatz haben, ist dies also eine günstige Lösung gegenüber einem eigenständigen Archivsystem wie LDMS oder Netapps.

Zumindest Applikationen, die mit größeren Files (ab 100 MB) arbeiten, sollten weiterhin auf ein eigenständiges Archivsystem setzen. Die Anwender könnten ansonsten mit der fallenden Performance der Anwendung nicht besonders glücklich sein.

Für unsere Recherche haben wir mit zwei unterschiedlich großen Testdokumenten gearbeitet. Die Ablage- und Zugriffszeiten unserer Testreihe können sie gerne als Protokoll auf Anfrage von uns erhalten. Schreiben Sie dazu einfach eine Mail an info@stoneone.de.

 

 

Quellennachweise:

1 – http://mysqldatabaseadministration.blogspot.de/2008/01/i-will-not-blob.html

2 – http://deepselect.blogspot.de/2006/05/to-blob-or-not-to-blob.html

3 – http://www.datenbank-sql.de/oracle-datentypen.htm