Hardware-Frage: Wie und wo speichert man Blobs?

[dschroeder]

Hallo liebe Forumsteilnehmer,

wir speichern seit einigen Jahren PDFs, Scans usw. in Blob-Tabellen auf der iSeries. Dabei haben wir die Metadaten der Dokumente (z.B. Suchbegriffe) von den eigentlichen Dokumenten getrennt. Das heißt, wir haben Datenbankdateien, in denen sich die Schlüssel und Suchbegriffe usw. befinden und wir haben separate Tabellen, in denen sich nur ein Blob und ein ID-Feld befindet. Die Dokumente (also die Blobs) werden von PC-Seite und von iSeries-Seite erzeugt. Gelesen werden sie hauptsächlich von PC-Seite. Inzwischen ist der durch die Blobs belegte Speicher höher als der Speicher der gesamten restlichen Datenbanktabellen. Unsere Hochrechnungen zeigen, dass der Speicherbedarf für Blobs in Zukunft noch stark ansteigen wird (z.B. weil PDFs immer häufiger farbig und damit größer werden).

Es ist nun die Idee aufgekommen, die Blobs außerhalb der iSeries zu speichern. Die Metadaten sollen natürlich weiterhin in der Datenbank verbleiben.

Deshalb hier mal ein paar Fragen:

Gibt es spezielle Hardware (muss nicht IBM sein), die für die Speicherung von Blobs besser geeignet ist, als eine iSeries Datenbank? Es geht hier nicht darum, revisionssicher "unlöschbar" zu speichern. Aber das Handling unserer Blob-Tabellen ist schon schwierig geworden. Da die Blob-Datenbanktabellen schnell überlaufen (bei ca. 1,7 TB pro Tabelle ist Schluss) und da solche großen Tabellen generell unhandlich sind (beim Kopieren, Sichern, usw.) haben wir die Blobs schon auf viele kleine Tabellen (Größe einer Tabelle ca. 250 GB) aufgeteilt.

Einige Kollegen aus der PC-Abteilung sind der Meinung, dass es Hardware gäbe, die besser mit dieser Art von Daten umgehen könnte als die iSeries Datenbank.
Vielleicht hat der eine oder andere ja bereits Erfahrungen mit diesem Problem.

Wir würden uns natürlich wünschen, dass der Zugriff auf so ein Speichersystem möglichst transparent mit SQL erfolgen könnte (sowohl vom PC über JDBC als auch über embedded SQL aus RPG), so dass wir unsere Software nicht anpassen müssten.

Ist so eine spezielle Hardware billiger als die iSeries-Speicherung? Die Storewize-Systeme der iSeries gehen zugegebermaßen ganz schön ins Geld. Aber die PC-Diskarrays bei uns sind auch nicht ganz billig.

Vielleicht kann ja jemand etwas zu dem Thema sagen.

Im Voraus vielen Dank.

Dieter

[Fuerchau]

Die Art der Speicherung ist nicht so das Problem sondern der Platz.
Mit Compression kann man ja noch etwas erreichen, wobei bei Bildern da nicht mehr viel drin ist.

Andere Datenbanken (PC-basiert) haben da schon Schwierigkeiten, ihre Daten auf verschiedene Platten zu verteilen.

Wenn die Platte voll ist muss man eine neue DB auf der nächsten Platte anlegen.

Bei der AS/400 hats du diese Sorgen nicht da ja dynamisch verteilt wird.

Besser als die DB2/400 mag es durchaus geben, aber mit dann höherem Organisationsaufwand (siehe Plattenverteilung).

Per RAID auf dem PC kann man wohl auch logische Platten mit mehreren physischen Platten verbinden.
Aber ob die PC-Datenbanken mit mehreren Terabytes so umgehen können.

[dschroeder]

Danke für die Antwort.

Ich glaube im Moment auch nicht, dass eine PC-Datenbank mehr bewältigen kann. Unsere Kollegen haben deshalb nicht-datenbankbasierte Systeme ins Spiel gebracht. Dort werden Dokumente wahrscheinlich im Filesystem verzeichnisbasiert abgelegt. Ich weiß zum einen nicht, ob so ein System dann quasi ohne Größenrestriktion ist und ob es Möglichkeitebn gäbe, auf so ein System mit vernünftigen Werkzeugen (z.B. SQL) zugreifen zu können.

[Fuerchau]

Standardfilesysteme kommen mit diesen Datenmengen auch nicht zurecht.
Die Beschränkung ist
a) Plattengröße (ggf. RAID für größere Volumes)
b) Anzahl Objekte im Verzeichnis max. 32K
Die Verwaltung kann auch hier nur über eine SQL-Datenbank (so wie ihr es ja schon macht) per Key und Link auf die Datei erfolgen.
Die Sicherheit ist noch das Problem, da die Fileobjekte nicht durch die DB geschützt sind.

Alternativen sind dann sog. BigData-Lösungen, die dann über mehrere Server die Daten verteilen und über meist eine eigene Abfragesprache parallele Suchen in den Daten erlauben.
Ob dies billiger ist, wage ich fast zu bezweifeln.

Big Data