Bilder in (Firebird-)Datenbank speichern

[Frickler]

Hallo,

wir wollen Bilder in einer Firebird-Datenbank speichern. Bislang wird über eine Dateifreigabe darauf zugegriffen. In den "HomeOffice-Seminaren" dieses Frühjahr von Holger Klemt wurde schön beschrieben, wie man das macht. Die technische Seite sollte also weniger das Problem sein.
Was mir eher Sorgen macht, ist die Datenmenge: es sind ca. 170.000 JPEG-Bilder (Tendenz: steigend) mit einer Gesamtgröße von 24 GB. Was sind so die Erfahrungswerte bei euch - kann ich das alles in eine einzelne FDB-Datei packen oder muss ich das aufteilen?

[mkinzler]

Sollte kein Problem sein.

[haentschman]

Moin...

Zitat:

wir wollen Bilder in einer Firebird-Datenbank speichern

...würde ich nicht machen. Bei der Datensicherung mußt du immer alle 24GB+ sichern. Bei den Bildern im Ordner mußt du ggf. nur die geänderten Bilder sichern oder die Sicherung unabhängig von der DB Sicherung laufen lassen.

PS:
Denkst du auch an den Entwickler? Wenn der Entwickler die Datenbankstruktur ändern muß, muß er beim Testen der neuen Statements, es geht nie beim ersten Mal glatt, immer die 24GB+ Datenbank wiederherstellen. Der kann sich dann den halben Tag Kaffee holen...

[bernau]

Zitat von haentschman:

Moin...

Zitat:

wir wollen Bilder in einer Firebird-Datenbank speichern

...würde ich nicht machen. Bei der Datensicherung mußt du immer alle 24GB+ sichern. Bei den Bildern im Ordner mußt du ggf. nur die geänderten Bilder sichern oder die Sicherung unabhängig von der DB Sicherung laufen lassen.

Dann hat aber jeder direkten Zugriff auf die Dateien. Das ist ggf nicht gewünscht, da auf dem Server ggf nur der Firebird-Port geöffnet ist.

Mit der großen Datenbank habe ich auch so meine Probleme und in folgendem Thread gefragt, ob man ggf. auslagern kann

https://www.delphipraxis.net/204179-...rschieben.html

Darauf hin hat Holger Klemt ein echt ansehnliches Video-Tutorial auf Youtube gestellt. Dabei werden Daten in eine weitere Datei ausgelagert, die dann readonly ist. Diese muss man also dann nicht mehr permanent sichern.

[IBExpert]

die größte db mit der ich aktuell regelmäßig zu tun hab, hat mit bildern und pdfs derzeit ca 600GB
über alle datenbanken hinweg sind das mehr als 2TB

mein Tip (kam glaub ich auch im Video): beim Zugriff auf die Blob Inhalte
die Client Anwendung nicht direkt auf die Tabelle zugreifen lassen, sondern
über den Umweg einer SP, die einen blob als Rückgabe parameter hat und eine
id o.ä. als eingabeparameter, weil du dann die clientseitige Implementation
immer nur ein mal machen musst, serverseitig aber die sp so umbauen kannst, das
die per execute statement on external auch auf andere (zB Read Only Archiv)
Datenbanken sogar auf anderen Servern zugreifen kannst, auch wenn deine
client app davon gar nichts weiss, muss die ja auch nicht.

[Frickler]

Zitat von haentschman:

PS:
Denkst du auch an den Entwickler? Wenn der Entwickler die Datenbankstruktur ändern muß, muß er beim Testen der neuen Statements, es geht nie beim ersten Mal glatt, immer die 24GB+ Datenbank wiederherstellen. Der kann sich dann den halben Tag Kaffee holen...

Der Entwickler bin ich insofern...

Zur Klarstellung: Das sind nicht unsere Bilder. Die meisten Kunden haben auch deutlich weniger davon, etwas 10-20% der Menge. Aber ein Kunde hat halt Massen davon.

Den Nachteil sehe ich eher darin, nicht mal eben die Bilder außerhalb der Software anschauen zu können. Wir haben Kunden, die nach Vorgängen suchen, indem sie den Bilderordner im Total Commander öffnen, nach Datum sortieren, und dann alle Bilder vom Zeitraum anschauen, ob da Bilder des gesuchten Vorgangs dabei sind...
Ich hatte schon überlegt, mit einem Listview einen Explorer zu faken, der dann die Bilder in der Datenbank so anzeigt, als seien diese in einem Ordner. Stelle mir das aber kompliziert vor.

[IBExpert]

Die Ansicht mal eben nach Datum sortieren, wenn es nur ein Pfad ist, sollte im Explorer im Filesystem kein them sein, selbst nicht mit der im Explorer vorhandenen Preview Ansicht.
Aber mach das einfach mal testweise mit wahlweise einer Millionen bilder in einem pfad oder auch in Unterpfaden, die geschwindigkeit vom filesystem gerade auf windows wird bei großen Datenmengen (im sinne von anzahl dateien) recht gemütlich, um das mal freundlich zu sagen.

Und von einem Zugriff auf die gleiche Ordnerstruktur über ein Netzwerk rede ich dabei noch gar nicht.

Es hindert dich ja auch keiner daran, in einem Filecache auf der Platte die native files abzulegen, das mach ich bei jeder zu öffnenden pdf Datei auch so, weil ich keine Lust hab, mit irgendwelchen Memory Streams halb funktionierende Komponenten und DLLs zu füttern, weil ich dafür ja sumatra als eigene exe einbinde, TImages aber direkt aus dem blob in die eigene Applikation zu ziehen und dort dann dazustellen, ist für png und jpg auch kein wirkliches Problem, aber erzeuge mal testweise auf einer Scrollbox zB 2000 TImages deiner Wahl und lade in alle ein anderes Bild aus dem Filesystem oder aus dem Datenbankblob. Bei png weiss ich ganz sicher, das das schnell mal 10-20 Sekunden dauert auch wenn nur ein Bruchteil davon sichtbar ist oder kleiner skaliert wird. Die Zeit verbrät aber nicht die lese/schreibe Operation sondern das decoding der Bilder. Da gibt es schnellere und langsamere TImage Varianten, aber zaubern können die alle nicht. Wenn du aber zB auf deinem Screen 10 Bilder nebeneinander darstellst und 5 Untereinander und eine unabhängige Scrollbar daneben baust, mit der man navigieren kann, wird das um längen schneller und dafür dann Bild 9950-10000 zu holen geht per sql befehl mit select first 50 skip 9950 * from ... und es fallen viele Overhead Operationen komplett weg, viele Webseiten arbeien übrigens ähnlich und auch da wird nix geholt was nicht explizit dargestellt werden soll.

Bei großen Datenmengen im Sinne von Anzahl Dateien und Bildern im Filesystem zu bleiben halte ich für eine Sackgasse, unter der gerade deinen Anwender mit großen Datenmenge leider werden, ich würde das niemals so machen.

[IBExpert]

ach ja, und bezüglich der Suche nach Datum, unser größter Kunde mit so einer pdf/png Archiv DB kann auch auf allen Dokumenten nicht nur nach dem Datum suchen oder einschränken, sondern hat in einem extra blob die erkannte OCR Volltext Inhalte des Dokuments bei scans oder bei pdfs das was als Text im pdf war, das hat sich insbesondere bei technischen Zeichnungen schon bewährt, weil oft in der Zeichnung schon Begriffe stehen, wo man was ähnliches sucht, geht in google ähnlicher Syntax, die aber die db auseinander nimmt.

Nur nach datum einschränken, dann würden die mir den Kopf abreissen ....

[jobo]

In der DB finde ich das auch nicht so toll. Eine DB ist halt kein Fileserver.
Bei dem Speicherverfahren von FB weiß ich nicht, ob es sich negativ bemerkbar macht. Aber in einem System, das auf Point In Time recovery ausgelegt ist, entstünden viele Änderungsdaten, die alle gemanaged werden müssten.
Ich habe mal ein System gebaut, wo die Datein (egal was) auch per SP geladen wurden. Auf dem Server wurde dann je nach Einstellung, Größe eine Speicherung in das Dateisystem vorgenommen. Wahrscheinlich etwas ähnlich zu dem was ibexpert geschrieben hat. Die Datenbank hat verwaltet, wo die Dateien liegen und Metadaten gespeichert.
Auf die Art hat man Sicherheit, Flexibilität und Ordnung mit wenig Ressourcenverbrauch.

[himitsu]

Wenn einem die Datenbank-Dateien zu groß werden, dann könnte man die Tabellen auch noch partitionieren (aufteilen).

Dem Plattenspeicher selber ist es ja egal, ob die Dateien einzeln oder in einer großen DB rumliegen. (sind ja insgesamt gleich viele Bytes)


Wir hatten früher auch mal alle Dateien als Blob in der DB und jetzt liegen sie im Dateisystem.
Hat aber vorallem mit Gründen des Backups und einer revisionssicheren Speicherung (Unterstützung für ein WORM-Laufwerk) zu tun.
Und die Dateien werden hier in der DB-Verwaltet, zusätzlich mit HASH, um die Datenintegrität prüfen zu können, und dann werden sie über DataSnap vom Server rausgegeben, aber da geht auch jede andere Client/Server-Architektur.


In einigen DBMS kann man auch von der DB auf das Dateisystem des Servers zugreifen.
Rein theoretisch könnte man die Dateien dann in einer Tabelle verwalten und die Dateiinhalte statt in Blobs als einzelne Dateien speichern, aber sie dennoch über die DB-Verbindung speichern und abrufen, also z.B. beim Abruf der Tabelle als Blob anjoinen.