PostgreSQL als "Filesystem"...

Hallo,

Ich hoffe hier erschrickt nicht jemand gleich :wink:

Es geht um eine Mediendatenbank. Die Mediendatenbank soll hauptsächlich Bilder verwalten.

Ziel soll eigentlich sein das alle Daten in der Datenbank liegen und nicht als Datei auf dem Filesystem. In anderen Foren wurde mir geraten dies nicht zu tun da die Datenbank (egal welche) damit Probleme hat und die Performance darunter leidet.

Jetzt habe ich mich mal umgschaut und es gibt auch DMS die auch Ihre Binary Files auf der Datenbank ablegen und nicht auf dem Filesystem. Da ich mich nun nicht so lange mit PostgreSQL beschäftige (arbeite schon seit ein paar Jahren mit MSSQL) wollte ich nun Informationen von euch ob das sinnvoll ist auf der Datenbank zu speichern? Was beachtet werden soll usw?

Am Anfang stehen im Moment ca 30 - 40 GB Bildmaterial zu Verfügung die in die neue Anwendung importiert werden soll.

Desweiteren habe ich auch von Partitionierung von Tabellen gehört. Wäre das für mein vorhaben sinnvoll?

Vielen Dank im Voraus.

Das hat alles Vor- und Nachteile. nachteilig ist auf alle Fälle, daß die Daten vom FS durch die DB wandern müssen, was ein Umweg ist. Vorteil wäre ein wirklich komplettes Backup.


Jetzt habe ich mich mal umgschaut und es gibt auch DMS die auch Ihre Binary Files auf der Datenbank ablegen und nicht auf dem Filesystem. Da ich mich nun nicht so lange mit PostgreSQL beschäftige (arbeite schon seit ein paar Jahren mit MSSQL) wollte ich nun Informationen von euch ob das sinnvoll ist auf der Datenbank zu speichern? Was beachtet werden soll usw?

Am Anfang stehen im Moment ca 30 - 40 GB Bildmaterial zu Verfügung die in die neue Anwendung importiert werden soll.

Also ich würde sagen, sinnvoll wäre es, Metadaten zu den Bildern in der DB zu speichern und die Bilder selbst als Files und lediglich die Dateinamen in der DB plus halt benötigte Metadaten.

Es gibt im übrigen psqlfs - A File System using PostreSQL, was aber einen recht toten Eindruck macht.




Desweiteren habe ich auch von Partitionierung von Tabellen gehört. Wäre das für mein vorhaben sinnvoll?

Vielen Dank im Voraus.

Nicht wirklich. Das ist eher was, wenn Du sehr viele Datensätze hast, z.B. der letzten 10 Jahre, aber Auswertungen sich fast immer mit dem aktuellen Jahr befassen. Dann kann man das so splitten.

Andreas

Vielen Dank für deine Antwort.

Das hilft mir ein wenig weiter. Nur verstehe ich nicht warum einige DMS Daten auf die DB packen. Ist das wirklich aus Geschwindigkeitsgründen nachteilig?

Der Vorteil wäre wirklich das die Datensicherung der Binary Files entfallen würde. Der andere Hintergrund ist das in Zukunft auch Daten wie Word Dokumente usw. verwaltet werden sollen und später indiziert werden sollen. Wie könnte das ablaufen? Funktioniert das überhaupt mit PostgreSQL?

Es wird nicht dramatisch, aber messbar sein, denke ich mal.

Der Vorteil wäre wirklich das die Datensicherung der Binary Files entfallen würde. Der andere Hintergrund ist das in Zukunft auch Daten wie Word Dokumente usw. verwaltet werden sollen und später indiziert werden sollen. Wie könnte das ablaufen? Funktioniert das überhaupt mit PostgreSQL?

Jetzt wird es eklig. Du könntest die Grütze durch antiword filtern und das indizieren. Oder, und besser, sowas wie ODF nehmen als Dateiformat.

Andreas

Die Frage kannst du dir eigentlich selbst beantworten:
In einem normalen Filesystem bekommt das Betriebssystem gesagt: öffne diese Datei, schreib da was hinein, schliesse diese Datei. Dauert Zeit t1.

In einer Datenbank muss zuerst einmal die Verbindung zur DB bestehen oder geöffnet werden. Danach wird ein Query abgesetzt, der potentiell (oder auch nicht) schon prepared ist. Zu diesem Query müssen die Daten (das ist in diesem Fall der Inhalt deiner Datei) erst einmal über das Netzwerk oder den Filesystemsocket geschoben werden. Schliesslich kommen die Daten in der DB an, die DB muss für die komplette Größe Speicher reservieren, um die Daten zu halten. Danach findet die DB heraus, wo die Daten geschrieben werden sollen, potentiell in eine Datei, vielleicht aber auch aufgrund der Größe in 2 oder mehr. Zusätzlich muss, um Transaktionssicherheit zu wahren, ein Logfile geschrieben werden.
Dauert Zeit t2.

Das t2 (wesentlich) größer als t1 ist, dürfte sich abzeichnen, oder?


Es gibt auch Mittel und Wege, ein Dateisystem DB-basiert zu gestalten und die Daten trotzdem im Dateisystem liegen zu lassen. Dafür müsste man verhindern, das der normale User im Datenbestand herumpfuschen kann. Alle anderen Inkonsistenzen, hervorgerufen durch Abbrüche bei Dateioperationen kann man durch geschicktes Kapseln mit Transaktionen abfangen.

Wir haben da mal was entwickelt … ist aber eher ein virtuelles Dateisystem für eine Community Plattform.

Vielen Dank für deine Antwort @ads.

Kann man sich “virtuelles Dateisystem” irgendwo anschauen?

Ich hab mich nun entschieden die Binary Files entsprechend auf dem FS abzulegen und in der Datenbank sozusagen nur die Metainformationen usw. zu speichern.

Hmm, wenn du Student bist und in Magdeburg studierst, ja …

Ansonsten wenn du Student bist und ein Studentenportal betreiben möchtest g

Scherz beiseite: nein, die Plattform ist nur Studenten zugänglich.
Im Prinzip sind alle Aktionen jedoch so ausgelegt, das sie innerhalb der DB in Transaktionen gekapselt sind. Wenn etwas schief geht, kann man später zurückrollen. Bei manchen Sachen erfordert das etwas nachdenken, aber wenn das einmal umgesetzt ist, klappt das wunderbar.
Zusätzlich kann man dann so nette Features wie virtuelle Archive ect. allein in der Datenbank implementieren :wink: