Daten einer Datenbank automatisch in eine neu zu erstellende Datenbank verschieben.

[IBExpert]

Zitat:

Zitat von Ghostwalker (Beitrag 1463578)

c) Ein Dateisystem kann genauso skalierbar sein wie jede Datenbank. Wie das bei MS liezenztechnisch aussieht kann ich nicht sagen. Bisher kenn ich nur Systeme die sowas auf Unix/Linux Ebene machen.

Kann! Ist es aber eher selten.

Pack 100000 Dateien in ein einziges Unterverzechnis eines Windows Rechners und such da mal was drin, viel Spaß beim warten, insbesondere wenn das noch nicht mal ssds sind.
Pack 10mio Dateien auf ein NAS (gerne auch vom Marktführer qnap) oder Serversystem deiner wahl, gerne auch in verschiene Unterverzechnisse und such da was drin, viel Spaß beim warten

Das man dann die Metadaten in eine db packt, ist nur konsequent, aber warum muss dann jede beliebige datei nach allen
möglichen Kriterien auch noch beisitzer, sichtbarkeiten, änderunsdaten, letzter zugriff, dateifragmente, usw zusätzlich speichern ...
Das macht dann trotzdem das Filesystem noch mal extra und nicht immer effektiv.
und warum dann nicht die paar mb oder gb extra in die db packen, wo du transaktionssicherheit, trigger und andere vorteile hast. Es wird ja nicht mehr, sondern nur woanders platz belegen.

Bei größeren Kunden kann wir es täglich zwischen 5000 und 50000 neue Dateien (pdfs, email, etc) zu tun, da kommt im jahr einges zusammen und wenn du den kram dann noch 10 Jahre aufbewahren musst, erst recht.

Skalierbarkeit ist weder im Filesystem noch in Datenbanken per se ein Problem, aber erhöhte Anforderungen eben nicht dadurch zu vermeiden, das ich in irgendeiner config datei irgendeinen parameter von a auf b setze.


Es gab vor jahren mal eine Applikationstest, wo jemand mit .NET krams typische Filesystem Aufgaben mit gleichen Datenmenge und diverse hunderttausenden Dateien im Windows Filesystem getestet hat und mit gleichen Operation in einer Firebird db gestest hat. Soweit ich mich erinner, hat der Gesamttest nur mit db in etwa die doppelte geschwindigkeit gehabt, und ja, auch da traue keiner Statistik, die du nicht selbst gefälscht hast, aber Filesysteme als performant und sicher zu betrachten ist eben nicht meine Perspektive.

(wir haben Datensicherungen der letzten jahre auf 3 verteilten QNAP NAS Systemen mit je ca 15TB mittlerweile und da was in den 20mio dateien zu suchen, von dem man nur ahnt wo es sein könnte, ist nicht sonderlich performant)

[bernau]

Zitat:

Zitat von Ghostwalker (Beitrag 1463578)

a) Das ein Client direkten Zugriff auf die Dateien braucht, wär mir neu. :)

Ähm. Das hast du selber geschrieben.

Zitat:

Zitat von Ghostwalker (Beitrag 1463453)

b) Dokument auslagern
Dokumente würd ich im Filesystem speichern, in der DB nur Links zu den entsprechenden Dateien. Dabeneben stehen in der DB nur die Meta-Daten.

Wie soll ich denn auf die Dokumente im Filesystem zugreifen, wenn ich keinen Zugriff habe?

[Ghostwalker]

@bernau

Ja, die Dokumente werden ins Filesystem ausgelagert, aber doch nicht auf dem Client, sondern logischerweise auf dem Server (dort ist ja auch die DB). Der Server liefert dann die Dateiinhalte aus wenn das ganze benötigt wird. :)

@IBExpert
Wenn ich IN den Dateien etwas suche, dann schenkt sich eine DB warscheinlich nicht viel mit einem Filesystem, was die Geschwindigkeit betrifft (also nach einem Teil eines BLOB-Feldes). Da seh ich natürlich den Vorteil einer DB, was den Komfort angeht. Allerdings würd ich bei den von dir beschriebenen Datenmengen auch keine Relationale Datenbank nehmen, sondern eher in Richtung Mongo-DB mit Elastic Search guggen, da diese Kombination auf so etwas abzielt (Bsp. GitHub).

Aber egal, es wird denk ich nicht DIE Lösung geben, sondern schlicht mehrere Möglichkeiten. Mir ging es auch nur darum einige Denkansätze zu liefern.

[mkinzler]

Zitat:

Ja, die Dokumente werden ins Filesystem ausgelagert, aber doch nicht auf dem Client, sondern logischerweise auf dem Server (dort ist ja auch die DB). Der Server liefert dann die Dateiinhalte aus wenn das ganze benötigt wird.

Dann wird das Ganze aber wieder komplizierter. Man würde dann ja wieder einen extra Dienst o.ä. benötigen oder eine Erweiterung des Servers (UDF, ...).

Zitat:

Wenn ich IN den Dateien etwas suche, dann schenkt sich eine DB warscheinlich nicht viel mit einem Filesystem, was die Geschwindigkeit betrifft (also nach einem Teil eines BLOB-Feldes).

Was dann eine weitere Datenbank wäre, welche aber ausserhalb der Kontrolle wäre (OS).

Zitat:

Allerdings würd ich bei den von dir beschriebenen Datenmengen auch keine Relationale Datenbank nehmen, sondern eher in Richtung Mongo-DB mit Elastic Search guggen, da diese Kombination auf so etwas abzielt

Löst aber das Grundproblem hier nicht. Dann hat man wieder alles in einer Datei.

[himitsu]

Jupp, ich hatte auch erst an sowas wie in Postgres gedacht.
Man kann in so manchem DBMS derartiges anlegen, wo nach gewissen Regeln eine Tabelle aufgeteilt wird.
https://www.postgresql.org/docs/10/d...titioning.html

Das SELECT/INSERT/UPDATE/DELETE geht dann transparent immer nur auf eine Tabelle, deren Inhalt aber auf unterschiedliche Dateien verteilt wird.

Auch nett für ein Backup: z.B. nach Jahr/Monat getrennt, verändern sich die alten Partitionen nicht mehr, außer man löscht/editiert was, also aktuellere Datensätze haben keinen/selten einen Einfluß auf uralte Daten-Dateien.

Zitat:

Zitat von bernau (Beitrag 1463468)

Ich möchte keinen Zugriff mehr vom Programm auf das Dateisystem. Ein reiner IP-Zugriff ist für mich aus Gründen der Datensicherheit ein Totschlagargument geworden.

Auch das ist bei vielen DBMS möglich, selbst wenn man hier über den DB-Server geht.
Oftmals ist es möglich über die DB auf das Dateisystem im Server zuzugreifen. (unter gewissen sicherheitsbedingten Restriktionen)

So kann man auch die Daten/BLOBs durch die DB getrennt in ein/mehrere Verzeichnisse speichern, die Metadaten in einer Tabelle ablegen und dann beim SELECT den Dateiinhalt als BLOB mit anjoinen oder via SP nachladen.
https://www.postgresql.org/docs/current/lo-funcs.html
https://www.postgresql.org/docs/current/adminpack.html

[bernau]

Zitat:

Zitat von Ghostwalker (Beitrag 1463636)

@bernau

Ja, die Dokumente werden ins Filesystem ausgelagert, aber doch nicht auf dem Client, sondern logischerweise auf dem Server (dort ist ja auch die DB). Der Server liefert dann die Dateiinhalte aus wenn das ganze benötigt wird. :)

Natürlich nicht auf dem Client. Aber wenn die Dateien auf ein Laufwerks-Share des Fileservers landen, dann hast du ja trotzdem Zugriff auf die Dateien. Alternativ müsste man wieder ein Serverprogramm parallel zu Firebird haben, welches die Dateien ausliefert. Dann doch lieber in die Datenbank. Für den Client ist der Zugriff dann einfacher.

[himitsu]

Zitat:

Zitat von bernau (Beitrag 1463646)

Alternativ müsste man wieder ein Serverprogramm parallel zu Firebird haben, welches die Dateien ausliefert.

Jupp, wir hatten schon einen Dienst, aktuell mit DataSnap, der seit einer ganzen Weile auch die Dateien des DMS zum Client bringt, welche in der DB verwaltet werden.

Also ja, eine Netzwerkfreigabe (Dateiserver) geht, sowie auch andere Dinge ala Samba/FTP/WebDAV,
auch kann man manuell mit INDY spielen oder einen höheren FunktionsServer (ala DataSnap/REST/SOAP/...) benutzen
oder eben auch eventuelle Dateifunktionen des Datenbank-Servers.

Sowoe eben doch die Daten als BLOBs direkt in der Datenbank,
automatisch oder manuell aufgeteilt, wenn es zuviel für eine Datenbank/Datei ist.


Irgendein Server/Service muß also am anderen Ende hängen und was man nun benutzt, das ist kann jeder selbst entscheiden.
Vorhandene Dienste sind am Einfachsten, weil schon da und nur benutzt werden müssen, oder andere Dienste, welche man erst aktivieren/freigeben, installieren oder gar erst selber bauen muß.

[jobo]

Zitat:

Zitat von bernau (Beitrag 1463646)

Zitat:

Zitat von Ghostwalker (Beitrag 1463636)

@bernau
Ja, die Dokumente werden ins Filesystem ausgelagert, aber doch nicht auf dem Client, sondern logischerweise auf dem Server (dort ist ja auch die DB). Der Server liefert dann die Dateiinhalte aus wenn das ganze benötigt wird. :)

Natürlich nicht auf dem Client. Aber wenn die Dateien auf ein Laufwerks-Share des Fileservers landen, dann hast du ja trotzdem Zugriff auf die Dateien. Alternativ müsste man wieder ein Serverprogramm parallel zu Firebird haben, welches die Dateien ausliefert. Dann doch lieber in die Datenbank. Für den Client ist der Zugriff dann einfacher.

Das geht auch anders und bringt dann ja erst den Nutzen. Eine Dateiupload SP mit der Steuermöglichkeit, Dateiablage in FS/DB/BOTH. Die DB schreibt die Datei bei entsprechender Konfiguration ins lokale Dateisystem und niemand kommt da sonst dran.
Also zur Klarheit: ein DB Server benötigt keine Share Laufwerke, um dort Dateien abzulegen oder anzunehmen. Das geht über normale Insert/Update/Select oder eleganter über SP.

Zitat:

Zitat von Ghostwalker (Beitrag 1463636)

Wenn ich IN den Dateien etwas suche, dann schenkt sich eine DB warscheinlich nicht viel mit einem Filesystem, was die Geschwindigkeit betrifft (also nach einem Teil eines BLOB-Feldes). Da seh ich natürlich den Vorteil einer DB, was den Komfort angeht. Allerdings würd ich bei den von dir beschriebenen Datenmengen auch keine Relationale Datenbank nehmen, sondern eher in Richtung Mongo-DB mit Elastic Search guggen, da diese Kombination auf so etwas abzielt (Bsp. GitHub).

Suche in Dateien artet natürlich beliebig aus ohne Formateinschränkung. DB Seitig würde man hier wohl Volltext Indizierung einsetzen, sodass die eigentliche Datei gar nicht angepackt wird zur Suche. Setzt voraus, dass man für die Dokumente automatisierte Textextraktion verfügbar hat.
MongoDB klingt nett und modern, würde ich aber ohne Kenntnis des Gesamtbedarfs unter keinen Umständen empfehlen. Um es mal ganz einfach zu sagen: für Mongo sprechen eigentlich nur sehr spezielle Datensituationen und vielleicht Geschwindigkeit bei sehr großen Datenmengen. Das eine ist hier nicht bekannt, große Datenmengen schließe ich nach den jetzigen Angaben aus.
Ich meine :“MongoDB kann jetzt auch Transaktionen! (Aber benutzt es besser nicht)“ sagt schon eine Menge. Oder die Anzahl an MongoDB Threads hier und ihre Natur (wie neulich).

Ich finde, eine DB Empfehlung ist bei der derzeitigen Beschreibung schwierig, weil es nur um das eine Problem geht und das nicht sehr typische Datenbankanforderungen stellt.