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

[bernau]

Hallo zusammen,


ich werde für mein größtest Softwarepaket in den nächsten Monaten(Jahren) die Datenbank wechseln. Weg von ADS auf einen SQL-Server. Mein Favorit ist grade Firebird.

Ein Problem, was ich immer habe, ist die riesige Datenmenge an Dokumenten. Dokumente werden nur zugefügt und werden nicht gelöscht. Das macht bei einem Backup (manchmal über das Internet) regelmäßig Probleme.



Was ich mir nun vorgestellt habe. Alle bestehenden Tabellen kommen in eine Datenbank.

myData.fdb

Die Dokumente (in Blobs gespeichert) landen in einer zweiten Datenbank

myDataDokuments.fdb

Ich möchten nun, dass ab einer bestimmten Größe (ca. 1GB) eine weitere Datenbank angelegt wird

myDataDokuments1.fdb

Die neue Datenbankdatei soll readonly werden. Diese muss nur ein einziges mal gesichert werden. Alle neuen Dokumente landen weiterhin in der bestehenden, nun wieder kleinen Datenbank.

myDataDokuments.fdb.

Sollte diese wieder größer als 1 GB werden, dann wird die nächste Datenbank angelegt

myDataDokuments2.fdb

u.s.w.



Nun zu meiner Frage:

Ist Firebird in der Lage, dies automatisch zu erledigen? Oder muss ich ein Serviceprogramm schreiben, welches regelmäßig aufgerufen wird, die Größe kontrolliert und die beschriebene Aktion durchführt?



Gerne hätte ich auch Ideen, wie man Dokumente ggf. anders speichern kann, ohne immer für ein Backup riesige Datenmengen schaufeln zu müssen.

[tsteinmaurer]

Hallo Gerd,

Firebird kann das nicht automatisch erledigen.

Generell ist das Aufteilen auf mehrere Datenbanken mit Vorsicht zu genießen, da Dinge wie z.b. FOREGIN KEY Constraints nicht Cross-DB funktionieren, wenn du z.B. archivierte Dokumente auf Stammdaten referenzieren möchtest. Du kannst auch in einem

Code:

SELECT ...

keine mehreren Datenbank ansprechen, sondern nur umständlicher via

Code:

EXECUTE STATEMENT ... ON EXTERNAL ...

in PQSL Blöcken.

LG

[jobo]

Vielleicht hilft Dir der Link:
http://www.firebirdsql.org/file/docu...s-clone-nodump

Man kann dann mit GBAK z.B. sowas unter Linux machen:
ALTER DATABASE BEGIN BACKUP
<Backup Prozess>
ALTER DATABASE END BACKUP

konkret:
ALTER DATABASE BEGIN BACKUP
gbak -backup emptest stdout | gbak -replace stdin emptest_2
ALTER DATABASE END BACKUP

Etwas umständlicher dann halt entsprechend unter Windows.

Dateien würde man per se wahrscheinlich gar nicht in die DB speichern, sondern daneben und nur die Links in der DB verwalten. Der einzige Grund, es anders zu machen ist m.E. ein Zugriffsschutz für die Dateien auf dem Client (oder sogar auf dem Server).
Sprich, speziell die Nutzung von FB als Client DB wäre ein Grund, auch Dateien "sicher" in der DB abzulegen um sie dem direkten Nutzerzugriff zu entziehen.
Wenn Du allerdings davon redest, einen Backup Service zu schreiben, könnte man genau das auch gleich für Dateien tun. Also einen Dienst schaffen, der Dateien gezielt an einem sicheren (und uU lokalen) Ort ablegt oder ggF. einen bestehenden einbinden.

[mkinzler]

Jein. Ist gibt die Möglichkeit eine Datenbank zu erstellen, welche aus mehreren Dateien besteht. (multi-file database). Man kann dan definieren bei welchen Bedingungen dann Sekundärdateien erstellt werden. Dies hat aber einen negativen Effekt auf die Performance.

[Ghostwalker]

Von Oracle her kenn ich da nur die "partitioned Tables", da kann man sowas autoatisch machen (Soweit ich weiß, kann das auch MS-SQL).

Denkansätze:

a) Backup-Strategie

Wenn du jedesmal ein Fullbackup machst (also die komplette DB), würd ich erstmal auf inkrementelles Backup umstellen. Dabei erstellst du nur einmalig ein vollständiges Backup, danach werden nur noch die Änderungen gespeichert.


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.


Gruß

Uwe

[Uwe Raabe]

Zitat:

Zitat von bernau (Beitrag 1463439)

Die Dokumente (in Blobs gespeichert) landen in einer zweiten Datenbank

myDataDokuments.fdb

Ich möchten nun, dass ab einer bestimmten Größe (ca. 1GB) eine weitere Datenbank angelegt wird

myDataDokuments1.fdb

Die neue Datenbankdatei soll readonly werden. Diese muss nur ein einziges mal gesichert werden. Alle neuen Dokumente landen weiterhin in der bestehenden, nun wieder kleinen Datenbank.

myDataDokuments.fdb.

Kannst du das nicht ganz einfach so realisieren?

Code:

rename myDataDokuments.fdb -> myDataDokuments1.fdb
create myDataDokuments.fdb

Der Zugriff auf myDataDokuments1.fdb und höher kann dann ja im Programm read-only implementiert werden.

Existieren schon nummerierte Dateien muss das Rename halt zyklisch erfolgen.

[IBExpert]

Das kann Firebird sehr wohl und wir machen genau den Ansatz schon so seit Jahren, mit Blobdatenmengen bis hin in den Terabyte Bereich (Ich geh mal davon aus, das dein Begriff Dokument als Blob zu verstehen ist, also pdf oder sonstwas)

Genereller Ansatz:

-Du speicherst deine blobs (pdfs etc.) am besten in eigene Tabelle, in den Tabellen die dazu gehören packst du zum Beispiel nur den fk zu dem Blob in der Blob Tabelle

-Wenn ein neuer Blob inhalt gespeichert werden soll, speicherst du den ganz normal in deiner aktiven Produktionsdatenbank

-Wichtig: wenn dein Client auf einen Blob Inhalt später lesend zugreift, dann machst du das nicht direkt per select auf der Tabelle, sondern über einen select auf einer sp, die den PK als parameter bekommt (ich nenn die hier mal getblob, ist aber nichts eingebautes, sondern ganz simpel selber zu erstellen)

-Du legst dir entweder jährlich oder in welchen Arten auch immer extra DBs an, in denen nichts als die blob tabelle baugleich ist (B2020.fdb, B2019.fdb, B2018.fdb usw)

-In einem simplen Reorg job, der zum Beispiel jede Nacht auf deiner Produktions DB läuft, schiebst du die blob daten, die z.B. älter als x Tage sind oder wie bei uns alle die gestern oder noch älter sind von der Produktions DB in die aktuelle offene Jahres DB (diese ist readwrite)

-Das übertragen geht per execute statement on external in einer sp oder einem execute block transaktionssicher, also delete in production und insert into jahres db ist ein einziger commit, obwohl 2 dbs

-Wenn du einen blob lesen willst, kann anhand der blob tabellen metadaten (timestamp) erkannt werden, wo die zu finden sind. Deine sp getblob macht nun als nicht anderes, als die metadaten zu dem blob auszulesen und per execute statement on external den eigentlich blob inhalt aus der jahres db in den speicher der production db holen und von da als rückgabe von der sp im client anzeigen, in datei packen oder was auchimmer damit machen.

-am jahresende setzt du die jahresdb auf readonly, select mit execute statement on external geht weiterhin, es muss nicht mal eine db auf dem eigenen server sein, sondern kann irgendwo aus der cloud kommen. Deine Getblob sp kann ja zu den metadaten irgendwelche Connectionstring aus einer tabelle auslesen und die dann benutzen.

-archivierte readonly jahresdbs packen wir auch meistens nicht auf schnelle ssds, sondern durchaus auf große hdds, weil die nur ein mal beim read only setzen gesichert werden müssen und dann nie wieder, weil die ja auch nie wieder geändert werden. Da alte Dokument selten geschwindigkeitskritisch sind, reciht das auch von hdds.

Wenn Interesse besteht können wir genau das Thema auch gerne mal nächsten Mittwoch um 17 Uhr im Stammtisch besprechen, weil ich weiss, das viele so eine Anforderungen haben und gerne den ganzen Kram in die db packen, aber dann in Probleme laufen, wenn die db nach wenigen Monaten oder Jahren dann dutzende oder hunderte Gigabyte haben und Backup/Restores endlos dauern.


Ganz wichtig aus meiner sicht: Mit "Nicht Blob Daten" ist das Mumpitz, geht auch, z.B. per datebase trigger oder table trigger, ist aber dann extrem umständlich, damit foreignkey beziehungen in abfragen sauber über mehrere Datenbank abzubilden und bringt nichts an Speed, ganz im Gegenteil.

[IBExpert]

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.

genau das würde ich nicht machen, weil dafür jeder Client Zugriff auf diese Dateien im Dateisystem braucht, das freut jeden Trojaner

Und wenn die jemand mal in seiner Trotteligkeit versehentlich eine Datei oder gleich ganze Ordner von da verschoben hat, sind deine
Metadaten unbrauchbar, weil da zwar was sein müsste, aber nix ist und keiner weiß warum. Das Filesystem ist in dem Sinne
nicht wirklich transakionssicher, alles readonly machen kann zwar helfen, ist aber umständlich, Filesysteme sind auch nur begrenzt
skalierbar und in der Microsoft Welt auch lizenztechnisch nicht ganz banal.

[tsteinmaurer]

Hallo Holger,

Zitat:

Das kann Firebird sehr wohl und wir machen genau den Ansatz schon so seit Jahren ...

Ja, wenn man dann selbst (sehr) viel herumbaut, was du ja mit deiner 9 Punkteliste gezeigt hast. Wollte Gerd nur vermitteln, dass man hier "Out-Of-The Box" wenig Wunder erwarten kann bzw. dass es Cross-DB gewisse Einschränkungen gibt und z.b. kein Löschen in deiner Stammdaten-DB unterbunden wird (z.B. Adresse, Rechnung, Kunde etc.), obwohl dieser Datensatz in der Archiv-DB noch referenziert wird.

LG

[bernau]

Hallo zusammen,


danke erst einmal für eure Antworten.

Auslagern der Dokumente in einzelne Dateien ins Filesystem kommt aus verschiedenen Gründen nicht in Frage.

* 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.

* Bei einer großen Anzahl (>50.000) von Dateien in einem Verzeichnis habe ich schon öfter Probleme mit Performance des Dateisystem bekommen. Habe das gelöst, in dem ich max 1000 Dateien in viele Unterverzeichnis gelegt habe. Aber auch das ist nicht das gelbe vom Ei.


Die angesprochene Funktion "out of the Box" wäre schön. Deshalb habe ich ja gefragt. Ist aber für mich nicht ein Ausschlusskriterium. Wenn ich mich für eine DB entschieden habe, werde ich wohl damit bis zu meiner Rente arbeiten. Eine Umstellung meiner Software auf die neue DB würde auch > 6 Monate in Anspruch nehmen. Bis dahin werde ich mich wohl gut in die neue DB eingearbeitet haben. Aber wenn es "out of the Box" gehen würde, dann wäre das natürlich angenehm.


@Holger: Ich werde mir mal am Mittwoch deinen Stammtisch anschauen. Freue mich schon drauf.

[IBExpert]

ich hab dann schon mal dieses Themenpaket für Mittwoch vorgesehen

-Dateien und Blobs in der Firebird Datenbank
-Verteilen auf verschiedene Datenbanken, Readonly Jahresarchive
-Zugriff über execute statement on external, transaktionssicherheit
-kurze Codebeispiele für lazarus/delphi und Einblick in reale Projekte
-Tips und Tricks für Dateivearbeitung in der Datenbank
-eingescannte Dokumente und serverside OCR
-EMails abrufen, verabeiten, preview erzeugen und anhänge extrahieren

Wird ja wie immer auch auf Video ausgezeichnet, aber direkte Fragemöglichkeiten und Antworten gibt es dann zwischen 17 und 19 Uhr

[bernau]

Zitat:

Zitat von IBExpert (Beitrag 1463472)

ich hab dann schon mal dieses Themenpaket für Mittwoch vorgesehen

Cool.:thumb:

[olaf]

Mit postgresql läßt sich Deine Anforderung über Partionen einfach lösen.

[bernau]

Zitat:

Zitat von olaf (Beitrag 1463535)

Mit postgresql läßt sich Deine Anforderung über Partionen einfach lösen.

Ich werde mir mal die Doku dazu anschauen. Hast du ein Stichwort, nach dem ich suchen kann?

[hoika]

Hallo,
Stichwort
"PostgreSQL - Partionen"

Eine Partition ist vereinfacht ein separate Datei (jaja, sehr vereinfacht).
Man kann einer Tabelle eine separate Partition zuordnen, aber auch einen Teilbereich einer Tabelle
(ähnlich wie ein View, nur dass die Daten wirklich separat gespeichert werden).

Links:
https://severalnines.com/database-bl...ata-postgresql
https://www.postgresql.org/docs/10/d...titioning.html

[taveuni]

Zitat:

Zitat von IBExpert (Beitrag 1463459)

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.

genau das würde ich nicht machen, weil dafür jeder Client Zugriff auf diese Dateien im Dateisystem braucht, das freut jeden Trojaner

Und wenn die jemand mal in seiner Trotteligkeit versehentlich eine Datei oder gleich ganze Ordner von da verschoben hat, sind deine
Metadaten unbrauchbar, weil da zwar was sein müsste, aber nix ist und keiner weiß warum. Das Filesystem ist in dem Sinne
nicht wirklich transakionssicher, alles readonly machen kann zwar helfen, ist aber umständlich, Filesysteme sind auch nur begrenzt
skalierbar und in der Microsoft Welt auch lizenztechnisch nicht ganz banal.

Verstehe ich nicht. Meiner Meinung nach sollte eine moderne Client/Server Anwendung sowieso niemals einem Client direkten Zugriff auf Daten ermöglichen. Weder auf eine Datenbank noch auf serverseitig gespeicherte Dateien. Moderne IT Umgebungen lassen dass sowieso seit Jahren bei uns nicht mehr zu. Es gibt genau eine TCP Verbindung von den Clients zum Server. Demzufolge ist dann der Server exklusiv für die Datenhaltung zuständig. In unserem Fall können dies auch mehrere Terrabytes umfassende Videodaten (=Dateien) sein. Diese in Blobs in einer Datenbank zu speichern wird dann eher schwierig.

[IBExpert]

Partitionierung ist für Firebird 5 in Arbeit, löst aber bei denen die es schon haben keineswegs das
Problem, das Teile der DB nach eigener Organisationsvorgabe in readonly Teile ausgelagert werden
können und damit gar nicht mehr in Backups gesichert werden müssen. Wenn am Ende eine DB
1TB hat und du eine Sicherung machen musst, ist es egal, ob die Partitioniert ist oder
nicht. In die Sicherung muss die komplett rein, es sei denn, du willst dich mit den
Varianten von partieller Sicherung herumärgern, bei denen du auch alle Zwischenstände
vorhalten muss, was dazu führen kann, das deine Sicherung deiner 1TB DB am Ende sogar
weit mehr als 1TB an Platz braucht.

Nur weil eine Plattform deklarative Möglichkeiten hat, gewisse Problemstellungen zu lösen,
wage ich zu behaupten, das die begrenzten Möglichkeiten innerhalb dieser deklarativen
Variante keineswegs die Vorteile aufwiegen, das selber umzusetzen und vollständig
zu verstehen und erweitern zu können.

Konkretes Beispiel: Das Replikationsprojekt mit mehr als 200 Standorten wäre hoffnungslos
gescheitert an mehreren Faktoren, wenn wir uns dabei auf vorhandene Replikationslösungen
verlassen hätten, weil die deklarative Variante zwar das kann, wofür die designt wurde,
die realen Anforderungen aber in verschiedenen Schritten immer weiter gingen und wir
dann dauernd hätten sagen müssen, geht nicht ...

Ist vielleicht auch eine Mentalitätsfrage, ob man ähnlich wie bei Kompnenten die fertige
eierlegende Wollmilchsau sucht oder konkret hinterfragt, welcher Aufwand ist wirklich
erforderlich, um das zu machen, was man wirklich braucht.

[IBExpert]

Nur um mal eben auf den Boden der Tatsachen zu kommen und eingeworfene Buzzwords zu vermeiden:
Welche mehrere Terabyte große Videodateien speichert Ihr denn irgendwo im Filesystem oder ruft
die on Demand über eine tcp/ip verbindung von wo nach wo ab?

Wir haben diverse Kunden im Medizinumfeld, von denen viele Bilddateien und teilweise auch Videos
oft auch nur verlustfrei komprimiert in blobs landen, ein terabyte in einem Datensatz hat dabei
aber noch niemand erreicht. Und ein CD, die ich nach einer MRT Untersuchung für meinen Facharzt
mitbekam, hatte nicht mal 200MB an Daten auf dem Datenträger ... , passt also locker in blobs,
insbesondere weil die dutzenden einzeldateien noch wesentlich kleiner waren. Nach meinem
Kenntnisstand sind MRT Daten schon ziemlich detailliert, aber wer weiß, vielleicht gibt es
ja aktuell Youtube Livestreams in 4k bei der Darmspiegelung ....

Videos sind genau wie Bilder zwar groß, aber eigentlich auch extrem langweilig, weil sich
die im Gegensatz zu zum Beispiel industrielle 3D CAD Zeichnungsdateien nicht mal eben
nur an einer Stelle minimal ändern, dadurch aber komplett neu gebraucht werden. Versionierung
von Dateien, Reproduzierbarkeit von Vorgängerversionen, usw. Den 3D Viewer interessiert
es nicht, das deine Daten irgendwo per tcp/ip stream kommen könnte, ob das modern ist oder
nicht, dafür werden auch aus caching gründen gerne und oft lokale Dateien benutzt.

Was "moderne IT Anwendungen" sind, weiss ich nicht, aber generelle Regeln, das die irgendwas
immer irgendwie machen, halte ich für gewagt. Der Mehrwert durch solche Anmerkungen ist also
begrenzt.

[hoika]

Hallo,
ja, es gibt keinen "so geht das immer"-Weg.

Alles in die DB:
- alles an einem Platz
- Backup dauert sehr lange

Dokumente auslagern
- DB + Metadaten der Dokumente (Pfad)
- Backup der DB und Smart-Backup der Dokumente (alias Sync z.B. via RoboCopy)


Beides hat Vorteile und Nachteile.

[Ghostwalker]

Zitat:

Zitat von IBExpert (Beitrag 1463459)

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.

genau das würde ich nicht machen, weil dafür jeder Client Zugriff auf diese Dateien im Dateisystem braucht, das freut jeden Trojaner.

Und wenn die jemand mal in seiner Trotteligkeit versehentlich eine Datei oder gleich ganze Ordner von da verschoben hat, sind deine
Metadaten unbrauchbar, weil da zwar was sein müsste, aber nix ist und keiner weiß warum. Das Filesystem ist in dem Sinne
nicht wirklich transakionssicher, alles readonly machen kann zwar helfen, ist aber umständlich, Filesysteme sind auch nur begrenzt
skalierbar und in der Microsoft Welt auch lizenztechnisch nicht ganz banal.

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

b) Ja...wenn der Administrator Scheiß baut, kann die beste Software nix mehr retten (sprich wenn der die Dateien löscht oder verschiebt).

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.

Gruß Uwe

[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.