Video in Firebird Datenbank

[PhilmacFLy]

Moin DPler

Ich hab folgende Frage:
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,
nun ist das Problem das das Blob feld sich nicht so groß einstellen lässt.
Jetzt wollt ich wissen ob es da eine Möglichkeit gibt? Denn ansonsten wird mir wohl nichts
anderes übrig bleiben als auf dem DB Server noch eine SMB Freigabe zu erstellen.

Danke jetzt schon für eure Hilfe :)

[DeddyH]

AFAIK beträgt die maximale Größe eines BLOB-Werts 32 GB. Die stellt man aber gar nicht nicht ein, sondern die Blockgröße. Wird diese überschritten, speichert Firebird nur eine Referenz in der Tabelle und legt die Daten in einem gesonderten Bereich ab.

Das war jetzt bewusst vereinfacht ausgedrückt, sollte ich Quatsch erzählen, bitte ich um Korrektur.

[Nersgatt]

Du stellst doch bei Blobfeldern nur die Segmentgröße ein, nicht die Größe des Blobfeldes selber.
Wenn Du also eine Segmentgröße von x Bytes einstellst, legt die Datenbank die Daten halt in Segment in der eingestellten Größe ab.

[PhilmacFLy]

Ah ok nur versteh ich nicht ganz was die Segmentsize bedeutet oder wie ich die einstellen muss

[DeddyH]

Belass sie einfach auf dem Standardwert, das passt normalerweise. Mehr dazu: http://groups.yahoo.com/neo/groups/f.../topics/115818

[Nersgatt]

Die Datenbank verarbeitet die Daten in Segmenten der angegebenen Größe. Wenn wir wissen, dass wir in einem Blobfeld immer Daten speichern möchten, die z.B. in der Regel 100 Bytes groß sind, dann würde sich eine Segmentgröße von 100 Bytes anbieten.
Bei größeren Dateien (wie z.B. die Videos) würde ich eine entsprechend größere Segementgröße wählen.

[Nersgatt]

Zitat:

Zitat von DeddyH (Beitrag 1228643)

Belass sie einfach auf dem Standardwert, das passt normalerweise.

Genau das würde ich nicht machen. Es ist schon sinnvoll kurz über die Segementgröße nachzudenken. Grade wenn man große Datenblöcke speichert ist es sinnvoll die Segementgröße auch höher einzustellen.

[DeddyH]

OK, ich habe mich noch einmal belesen:

Zitat:

A blob segment size can be defined, to increase the performance when inputting and outputting blob data. This should roughly correspond to the data type size. With a memo field, for example, for brief descriptions which could however, in individual cases, be considerably longer, the segment length could be defined as 100 bytes, whereby the blob data type is processed in 100 byte blocks.

When processing videos or large graphics in the database, a large segment length should be selected. The maximum length is 65536 bytes. This is because all blob contents are stored in blocks, and are fetched via these blocks. A typical segment size from the old days is 80 (because 80 characters fit onto one monitor line).

When a blob is extracted, the Firebird/InterBase® server reads the number of segments that the client has requested. As the server always selects complete blocks from the database, this value can in effect be ignored on modern powerful computers. 2048 is recommended as a standard since version InterBase® 6.

Quelle: http://ibexpert.net/ibe/index.php?n=...ob#SegmentSize

[PhilmacFLy]

Alles klar vielen Dank habt mir sehr weiter geholfen :thumb:

[tsteinmaurer]

Ich würde der Segment Size keine Beachtung schenken. Dieses Konzept ist aus den 80er, wo RAM spärlich und teuer war und man dem Client irgendwie mitteilen wollte, in welchen Chunks der Client Daten abholen soll/kann. AFAIK, aktuelle Zugriffsbibliotheken fangen mit dieser Information überhaupt nichts an. Zumindest sind mir diesbzgl. Aussagen seitens Ann Harrison und Co in Erinnerung.

[MyRealName]

Segmentsize kann wichtig sein, da ja immer nur ein blob pro segment drin sein kann

Sind deine daten normalerweise 100-500 byte pro blob, lohnt sich eine Segmentgrösse von 8192 byte nicht, da verschwendest viel.
Aber wenn Du videos ablegst die mehrere Megabyte sind, dann nimm die segmentgrösse so hoch wie geht, weil dann brauch er nicht soviele Identifikatoren um pro blob festzulegen, wo das video verteilt gespeichert ist

[mkinzler]

Wieviele Videos passen den in 500 Bytes? ;)

[haentschman]

Moin...
[mein Senf]
Wenn Bilder in die Datenbank gespeichert werden sollen erschallt ein Aufschrei, daß man so etwas nicht macht sondern nur den "Link" in die DB speichert. Mit Videos würde ich das, auf Grund der Größe, erst Recht machen.
Damit muß sich Windows mit der Ablage beschäftigen und nicht die DB muß MB an Daten schaufeln wo sie wichtigeres zu tun hat. Desweiteren dürfte das auch wesentlich pflegbarer sein.
[/mein Senf]

[Morphie]

Das musst du jetzt aber mal erklären. ;-)
Was sollte denn dagegen sprechen Binärdaten in der Datenbank abzulegen?

Stell dir mal eine Multi-User-Datenbank vor. Wie willst du da einen Pfad zur eigentlichen Datei speichern?
Soll jeder Client neben der Datenbankverbindung auch noch ein Netzlaufwerk oder eine UNC-Freigabe mit Schreib/Leserechten eingerichtet bekommen?
Das halte ich für viel schlimmer als eine Datenbank, die Binärdaten akzeptiert.

Oder was ist, wenn sich die Pfade mal ändern?

[Hansa]

Zitat:

Zitat von haentschman (Beitrag 1228777)

Moin...
[mein Senf]...Mit Videos würde ich das, auf Grund der Größe, erst Recht machen...

Wie rum jetzt ? :shock: Was gehört in die DB ? Das Video oder nur der Dateipfad ? Gegen ersteres spricht folgendes : Szenario Immobilienmakler. Der hat 1000 Immobilien und zu 500 hat er ein Video. Dauernd kommen neue Objekte hinzu. Bei Bedarf auch neue Videos. Jetzt macht der jeden Tag Datensicherung, damit die Adressen im Notfall immer aktuell bleiben. Muss der wirklich jeden Tag die Videos (die sich selten oder nie ändern) mitsichern ? Sagen wir 1 GB pro Video. Jeden Tag wären dann 500 GB mitzusichern (bei 1000 Adressen hätten die Nutzdaten wohl kaum mehr als 20 MB), sofern die Videos in der DB liegen. Werden die Videos separat gespeichert, dann kann man die ja auch ab und zu sichern. Der viel wichtigere "richtige" Datenbestand wäre dann täglich mit wesentlich geringerem Aufwand (an Zeit und Geld) zu sichern.

Anderes Beispiel : Produkt-Katalog, wo sich die Preise täglich ändern. Wann ändern sich da die Bilder ?

[mkinzler]

Für diesen Fall würde sich eher eine inkrementelle Sicherung anbieten. Die Speicherung des kompletten Inhalts hat auch den Vorteil, dass der Speichereort einfach geändert werden kann und das die Komplettsicherung deutlich schneller ist. Das Sicherheitsproblem von weiteren benötigten Freigaben wurde ja schon agesprochen.

[Perlsau]

Zitat:

Zitat von PhilmacFLy (Beitrag 1228621)

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.