Video in Firebird Datenbank

[Perlsau]

Zitat von PhilmacFLy:

Ich nehm mithilfe des DSPack ein Video auf und möchte diese nun in der Datenbank ablegen. Ich dachte mir zuerst das ich die Datei in einen Stream lade und dann in ein Blob Feld ablege ...

Über Sinn & Unsinn, Videodateien in Datenbanken zu speichern, wurde schon viel geschrieben. Es kommt eben darauf an, wie viele solcher Video-Dateien man in der Datenbank haben möchte. Vidso-Sammler haben zu Hause schon mal ein paar hundert Terrabyte an Videos auf ihren USB-Laufwerken. Für eine gewöhnliche Firebird-Datenbank bräuchte man allerdings eine Festplatte, die das aufnehmen kann, und am besten kein USB-Laufwerk, denn die sind langsamer als Sata-Platten. Es soll aber auch die Möglichkeit geben, Firebird als Multi-File-DB zu verwenden, aber darüber weiß ich nichts Genaues ...

Der größte mir bekannte Ram-Speicher der Welt ist wohl der von IBM vor zwei Jahren entwickelte: Satte 120 Petabyte sollten damals durch den Verbund von 200.000 herkömmlichen Festplatten den größten Speicher der Welt bilden. Das sind über 125 Millionen Gigabyte

Die derzeit größten Sata-Platten scheinen nicht mehr als 4000 Gigabyte zu bieten. Ich hab jetzt über eine Stunde gesucht und konnte keine größere finden. Da kommt man als Filme-Sammler schnell an seine Grenzen, bedenkt man, daß hochwertige BluRay-Filme mindestens 4 Gigabyte groß sind, für größere Bildschirme wohl bis zu 20 GB. Das wären dann 200 Bluray-Filme pro 4 TB. Nicht die Welt ... Oder bei herkömmlichen 4,7-GB-Filmen (DVD) wären das imerhin mehr als 800 Filme.

Videos für kommerziellen Gebrauch sind ja meist nicht so groß: Rechnen wir mal 1 GB pro Video, würden auf die größte Sata-Platte um die 4000 Videos passen, das könnte man dann schon in einer Multiuser-DB unterbringen ...

Man kann ohne Videos in der DB aber dennoch einen Multiuser-Zugriff entwickeln. Ich würde hier eine 3-Schicht-Lösung anstreben: Client - Zwischenschicht - Datenbank. Requests werden dann an die Application gestellt, die ich laienhaft als Zwischenschicht bezeichne, und diese packt dann die angeforderten Daten aus Datenbank und Dateisystem zusammen und schickt sie an die Client-App.

[PhilmacFLy]

Mit dem Unterschied das die Videos die ich mach maximal 10s lang sind und damit ungefähr eine größe von ca 20-30 mb haben.

[IBExpert]

Bezgl. Videos in Datenbank: Es spicht nichts dagegen, zum Beispiel mit Techniken wie EXECUTE STATEMENT ... ON EXTERNAL für Videos, die ja nun mal per se relativ statisch sind, eine eigene Datenbank zu haben, die ich aber aus meiner Datenbank transparent abrufen kann.

Wir machen das mit dem Bereich Dokumentmanagement, wo einfach alle PDF und Bilddateien der Thumbnails monatlich in eine zweite teilweise sehr große Archivdatenbank verschoben werden, diese wird nach der Übertragung dann auf Readonly gesetzt und braucht auch nur ein mal pro Monat gesichert werden.

Während des Monats laufen dann die neue PDFs und Images in die Produktionsdatenbank hinein, die dann beim nächsten Monatswechsel wieder archiviert werden. Der Zugriff auf die Dokumente läuft dabei über eine Tabelle, in der die Volltextdaten enthalten sind, diese bleibt auch immer komplett in der Echtdatenbank. Der Zugriff auf die JPG oder PDF Daten erfolgt immer über den Umweg einer Prozedur und diese entscheidet intern, das das Objekt, das in der Produktsdatenbank gerade ein leeres Blobfeld hat, eben per execute statement on external die daten aus der anderen DB holt, die ggf sogar auf einem anderen Server liegen kann.

Die Übertragung in die zweite DB als auch der Zugriff läuft alles ab fb25 mit Bordmitteln.