Was ist der beste Ort zum Speichern von Binärdateien, die sich auf Daten in Ihrer Datenbank beziehen? Sollten Sie:

1. In der Datenbank mit einem Blob speichern
2. Speichern Sie im Dateisystem mit einem Link in der Datenbank
3. Im Dateisystem speichern, aber in einen Hash des Inhalts umbenennen und den Hash in der Datenbank speichern
4. Daran habe ich nicht gedacht

Die Vorteile von (1) sind (unter anderem), dass die Atomizität von Transaktionen erhalten bleibt. Die Kosten sind, dass Sie möglicherweise die Speicheranforderungen (und die damit verbundenen Anforderungen für Streaming / Backup) drastisch erhöhen

Das Ziel von (3) ist es, die Atomizität bis zu einem gewissen Grad beizubehalten - wenn Sie erzwingen können, dass das Dateisystem, in das Sie schreiben, das Ändern oder Löschen von Dateien nicht zulässt und immer den richtigen Hash als Dateinamen hat. Die Idee wäre, die Datei in das Dateisystem zu schreiben, bevor das Einfügen / Aktualisieren unter Bezugnahme auf den Hash zugelassen wird. Wenn diese Transaktion nach dem Schreiben des Dateisystems, aber vor der Datenbank-DML fehlschlägt, ist dies in Ordnung, da das Dateisystem das Repository für alle ist Mögliche Dateien und Hashes - es spielt keine Rolle, ob sich darin Dateien befinden, auf die nicht verwiesen wird (und Sie könnten sie regelmäßig bereinigen, wenn Sie vorsichtig sind).

BEARBEITEN:

Es sieht so aus, als hätten einige RDBMS dies auf ihre individuelle Art und Weise abgedeckt - ich wäre interessiert zu wissen, wie andere es tun - und insbesondere an einer Lösung für Postgres

1. In der Datenbank mit einem Blob speichern

   Ein Nachteil ist, dass dadurch Ihre Datenbankdateien sehr groß und möglicherweise zu groß werden, um mit Ihrer vorhandenen Konfiguration gesichert zu werden. Ein Vorteil ist Integrität und Atomizität.

2. Speichern Sie im Dateisystem mit einem Link in der Datenbank

   Ich bin dabei auf solch schreckliche Katastrophen gestoßen, und es macht mir Angst, dass die Leute es immer wieder vorschlagen. Zu den Katastrophen gehörten:

   • Ein privilegierter Benutzer, der die Dateien neu anordnete und die Verknüpfungen zwischen den Pfaden in der Datenbank und dem Ort, an dem sie sich jetzt befinden, häufig unterbrach (aber irgendwie wurde dies meine Schuld).
   • Beim Umzug von einem Server auf einen anderen ging der Besitz einiger Dateien verloren, da die SID für das Administratorkonto des alten Computers (auf dem die alte Website ausgeführt wurde) nicht Teil der Domäne war und die kopierten Dateien daher möglicherweise über Zugriffssteuerungslisten verfügten nicht aufgelöst werden, so dass Benutzer den Benutzernamen / das Kennwort / die Domänenanmeldeaufforderung erhalten.
   • Einige der Wege am Ende länger als 256 Zeichen aus dem C:\ganzen Weg zu dem .docund nicht alle Versionen von NT der Lage waren , mit langen Wegen zu beschäftigen.

3. Im Dateisystem speichern, aber in einen Hash des Inhalts umbenennen und den Hash in der Datenbank speichern

   Der letzte Ort, an dem ich gearbeitet habe, tat dies, basierend auf meiner Erklärung der obigen Szenarien. Sie hielten es für einen Kompromiss zwischen der Unfähigkeit des Unternehmens, Erfahrung mit großen Datenbanken zu sammeln (alles, was größer als 40 GB war, wurde als "zu groß" eingestuft), der Unfähigkeit des Unternehmens, große Festplatten zu kaufen, und der Unfähigkeit, ein moderneres Back zu kaufen und die Notwendigkeit, die oben genannten Risiken 1 und 3 zu umgehen.

Meiner Meinung nach ist das Speichern in der Datenbank als Blob eine bessere Lösung und skalierbarer in einem Szenario mit mehreren Servern, insbesondere bei Failover- und Verfügbarkeitsproblemen.

Nummer 1 für vollständige Datenintegrität. Verwenden Sie die anderen Optionen, wenn Sie sich nicht um die Datenqualität kümmern. So einfach ist das.

Die meisten RDBMS verfügen ohnehin über Optimierungen zum Speichern von BLOBs (z. B. SQL Server-Dateistream)

Wenn Sie sich für Oracle entscheiden, schauen Sie sich dbfs und Secure Files an.

Sichere Dateien sagen alles, bewahren Sie ALLE Ihre Daten sicher in der Datenbank auf. Es ist in Lobs organisiert. Secure Files ist eine modernisierte Version von LOBs, die aktiviert werden sollte.

dbfs ist ein Dateisystem in der Datenbank. Sie können es ähnlich wie ein Netzwerkdateisystem auf einem Linux-Host mounten. Es ist sehr mächtig. Siehe Blog Es gibt auch viele Optionen, um auf Ihre spezifischen Bedürfnisse abzustimmen. Als Datenbankadministrator mit einem Dateisystem (basierend auf der Datenbank, gemountet unter Linux) habe ich problemlos eine Oracle-Datenbank darauf erstellt. (eine Datenbank, gespeichert in einer ... Datenbank). Nicht, dass dies sehr nützlich wäre, aber es zeigt die Macht.

Weitere Vorteile sind: Verfügbarkeit, Sicherung, Wiederherstellung, Lesezugriff auf die anderen relationalen Daten.

Manchmal wird die Größe als Grund angegeben, Dokumente nicht in der Datenbank zu speichern. Diese Daten müssen wahrscheinlich auf irgendeine Weise gesichert werden, sodass dies kein guter Grund ist, sie nicht in der Datenbank zu speichern. Insbesondere in Situationen, in denen alte Dokumente als schreibgeschützt betrachtet werden sollen, ist es einfach, große Teile der Datenbank schreibgeschützt zu machen. In diesem Fall ist für diese Teile der Datenbank keine häufige Sicherung mehr erforderlich.

Ein Verweis in einer Tabelle auf etwas außerhalb der Datenbank ist unsicher. Es kann manipuliert werden, ist schwer zu überprüfen und kann leicht verloren gehen. Wie wäre es mit Transaktionen? Die Datenbank bietet Lösungen für all diese Probleme. Mit Oracle DBFS können Sie Ihre Dokumente an Nicht-Datenbankanwendungen weitergeben, die nicht einmal wissen, dass sie in einer Datenbank stecken.

Eine letzte große Überraschung ist, dass die Leistung eines dbfs-Dateisystems oft besser ist als die eines normalen Dateisystems. Dies gilt insbesondere dann, wenn die Dateien größer als ein paar Blöcke sind.

Ich denke, die richtige Antwort hängt in hohem Maße von Ihrer Bewerbung ab und davon, wie wichtig diese Dokumente sind.

Für ein Dokumentenverwaltungssystem oder ein System, bei dem die Wiederherstellbarkeit der gespeicherten Dokumente von entscheidender Bedeutung ist (z. B. in Bezug auf Finanzen, Personalwesen oder CRM), scheint das Speichern von Dokumenten inline oder die Verwendung der proprietären Dokumententechnologie Ihres bevorzugten DB-Anbieters das Richtige zu sein.

Es gibt jedoch viele Anträge, bei denen ich die gegenteilige Entscheidung für angebracht halte.

Helpdesk-Systeme und Wiki-Systeme sind solche, bei denen es meines Erachtens sehr sinnvoll ist, die Daten aus der Datenbank fernzuhalten . Ich glaube, einige, wie Jira, bieten eine Option, um zu entscheiden, ob Sie Dokumente inline speichern möchten oder nicht.

Für ein mittelständisches Unternehmen kann das Speichern von Dokumenten für ein Inline-Ticketing-System den Unterschied zwischen einem komprimierten Backup in Megabyte und einem Backup in Gigabyte bedeuten.

Ich persönlich würde es vorziehen, ein Ticketsystem in wenigen Minuten wieder online zu stellen und einige Stunden mit den (im Allgemeinen weniger wichtigen) Dokumenten zu ringen, als meine RTO zu erhöhen, indem sie wiederhergestellt werden muss und wiedergeben von Protokollen aus einer viel größeren Sicherung.

Es gibt andere Vorteile, Dokumente getrennt zu halten.

• Sie können problemlos separate Prozesse ausführen, um Dokumentmetadaten zu katalogisieren, Viren zu scannen, Schlüsselwörter zu indizieren usw.
• Sie können Tools zur Unterstützung von Sicherungen oder Wiederherstellungen verwenden - rsync, Speicher-Snapshots usw. -, die sich für Dateien viel besser eignen als für Datenbanken
• Sie können tatsächlich Speicher verwenden, der Komprimierung oder Deduplizierung unterstützt (das Material, über das Ihre SAN-Administratoren seit Jahren geredet haben, auch bekannt als der Fluch der Datenbankadministratoren weltweit).
• Bei einer Installation an mehreren Standorten können Sie eine zentralisierte Datenbank mit einem verteilten Dateisystem ergänzen

Ich denke, eine Hybridkombination aus Nr. 2 und Nr. 3 könnte klug sein. Behalten Sie die ursprünglichen Dateinamen bei, aber berechnen und speichern Sie einen Hash / eine Prüfsumme des Dokuments, damit Sie einen Bezugspunkt haben, der die Wiederherstellung unterstützt, falls jemand die Datei verschiebt oder umbenennt.

Das Speichern der Dateien mit ihren ursprünglichen Dateinamen bedeutet, dass Anwendungen sie buchstäblich direkt aus einem Dateisystem ziehen und sie über das Netzwerk oder in einer Thick-Client-Welt senden können, wobei der Benutzer möglicherweise sogar direkt auf den Dateiserver verwiesen wird.

Tu es nicht.

Es ist wirklich kein Vorteil, Dateien in der Datenbank zu speichern.

Fühlt es sich nicht schon komisch und faul an, wenn Sie sich denken:

Soll ich Dateien in einer Datenbank oder einem Dateisystem speichern ?

Noch besser, sag es laut.

Zu den Fakten:

Nutzung der Datenbank

" PROS " ... aber nicht ganz :

• "Atomicity" ist richtig, aber es ist ein zweischneidiges Schwert. Weil es die Nachteile mit sich zieht.
• Integrität. Das gleiche wie oben.

Ich möchte wirklich nicht voreingenommen sein, aber ich denke nicht, dass es mehr gibt, um hinzuzufügen. Die Profis sind nicht so toll, wenn man darüber nachdenkt.

Wenn ich unten einen Kommentar vergessen habe, lies in der Zwischenzeit weiter.

Nachteile:

• Falsches Werkzeug für den Job
• Schwieriger zu pflegen
• Schleppend
• Vergessen Sie das Speichern von Hunderten von MB / Gigabyte Daten pro Benutzer .
• Sichern von schnell wachsenden Standorten wird ein Albtraum sein.
• Wiederherstellen / Bewegen wird auch saugen.

Verwenden des Dateisystems

PROS:

• Weg leichter zu pflegen
• Schnell
• Datenbank-Backups haben damit nichts zu tun
• Wohl mehr Portabilität

Nachteile :

• Keiner*

*Kleingedrucktes

Momentan fragst du dich, warte, du meinst, es gibt keine Nachteile ?! Woher?

Der größte Fehler dabei ist, dass die Leute versuchen, eine Schraube mit einem Hammer zu schrauben.

Der Hauptgrund , und ich so weit gehen würde , zu sagen , nur Grund , dies verlangt wird, weil der ist Dateiverknüpfungen .

Dies ist ein Problem, das die Datenbank nicht lösen soll. Es klingt sogar albern, wenn Sie darüber nachdenken.

"Die Datenbank wird meine Dateiverknüpfungsprobleme beheben."

Wenn in Wirklichkeit logisch die Anwendung sollte zuständig sein tatsächlich von Handhabung und Ausschank Links.

Eine Lösung:

1. Lassen Sie Ihre Anwendung URL-Anforderungen mit benutzerdefinierten Routen verarbeiten.
2. Speichern Sie diese Route in Ihrer Datenbank.
3. Jedes Mal, wenn diese Route aufgerufen wird, ordnen Sie sie der gewünschten Datei zu.
4. Wenn Sie Ihre Dateien an einen anderen Ort verschieben, ändern Sie einfach den Dateinamen der Route, und diese Route liefert immer die gleiche Datei, unabhängig davon, wo sie im Internet gespeichert ist oder auf die verwiesen wird.

Dies würde auch die nativen Pfade abstrahieren, die Anwendung portabler und wartbarer machen und es ermöglichen, zu jeder Art von Dateisystem zu wechseln, ohne irgendetwas zu beschädigen.

Die Implementierung würde den Rahmen dieser Antwort sprengen, aber Sie können sich ein allgemeines Beispiel in der wohl am häufigsten verwendeten Web-Sprache (PHP) ansehen:

https://github.com/symfony/Routing

https://github.com/kriswallsmith/assetic

Beide zusammen sind wirklich mächtig.

Ich möchte hier meine Erfahrung in Bezug auf die Kompromisse hinzufügen. Zumindest in PostgreSQL sind die Auswirkungen auf die Leistung in Bezug auf den Datenbankserver recht gering. Große Blobs werden in separaten Dateien gespeichert, nicht in den Hauptspeichertabellen, um sie aus dem Weg zu räumen, mit dem möglicherweise eine große Anzahl von Datensätzen erfasst wird. Andere dbs können etwas Ähnliches tun.

Der Hauptvorteil ist die Möglichkeit, alle zugehörigen Daten für Atomaritäts- und Sicherungszwecke an einem Ort zu speichern. Dies verringert die Wahrscheinlichkeit, dass etwas schief geht, erheblich.

Der Hauptnachteil ist nicht der, den ich oben gesehen habe, und das ist die Speichernutzung im Front-End. Ich weiß nicht genau, wie jede Datenbank damit umgeht, daher kann dies von der Implementierung abhängen, aber für PostgreSQL werden die Daten als ASCII-Escape-Zeichenfolge (möglicherweise hexadezimal, möglicherweise mit inline-Escape-Zeichen) eingegeben. Diese muss dann im Frontend wieder in binär umgewandelt werden. Viele Frameworks, die ich dafür gesehen habe, beinhalten die Übergabe des Werts (nicht als Referenz) und die Erstellung einer neuen darauf basierenden Binärzeichenfolge. Ich habe berechnet, dass die Verwendung von Perl zu diesem Zweck ein Vielfaches des Speichers der ursprünglichen Binärdatei beansprucht.

Fazit: Wenn auf die Dateien nur gelegentlich zugegriffen wird, würde ich sie in der Datenbank speichern. Wenn, zumindest mit PostgreSQL, häufig und wiederholt auf sie zugegriffen wird, überwiegen meines Erachtens die Kosten die Vorteile.

Früher hat Microsoft die Möglichkeit erweitert, Bilder (und ähnliche Blob-Datentypen) in der Datenbank zu speichern. Das war eine coole neue Funktion von SQL Server 2000 (ich bin mir ziemlich sicher, dass es 2000 war, nicht 7.0) und viele Leute sind auf den Zug gesprungen.

Das Speichern von BLOBS in der Datenbank hat Vor- und Nachteile:

Einerseits können alle Ihre Daten und zugehörigen Bilder oder Dokumente an einem Ort gespeichert und abgerufen werden. Anwendungsbenutzer benötigen keine speziellen Netzwerkberechtigungen, da SQL die Bilder / Dateien / Dokumente bereitstellt.

Andererseits kann Ihre Datenbank abhängig von der Größe und Anzahl der BLOBs, die Sie speichern, sehr groß werden. Dies wirkt sich auf Sicherungen, Speicheranforderungen, zeitkritische Wiederherstellungsvorgänge usw. aus.

In SQL Server 2008 wurde das Streamen von Dateien eingeführt. Die Datenbank enthält Verweise auf die Dateien. Die Dateien befinden sich auf dem Server, nicht in der Datenbank. Wenn Sie jedoch die Datenbank sichern, werden auch die Dateien gesichert.

Ihre Backups können sehr umfangreich sein, aber Sie haben keine verwaisten Dateien / Dokumente / Blobs / Bilder.

Meine persönliche Vorliebe war es, die Datenbank Zeiger / Netzwerkspeicherorte speichern zu lassen und einen Dateiserver mit den Dateien zu beauftragen. Dateiserver sind sowieso besser für solche Aufgaben optimiert.

Speichern Sie keine Dateien in einer Datenbank.

Jeder, der ausnahmslos ein beliebiges RDBMS auf dem Markt ausführen kann, verfügt bereits über eine Datenbank speziell zum Speichern von Dateien, die das RDBMS selbst verwendet! Diese Datenbank ist das Dateisystem . Lassen Sie uns nun einige der potenziellen Nachteile des Speicherns von Dateien in der Datenbank sowie einige spezifische Schadensbegrenzungsfaktoren für das Speichern von Dateien in der Datenbank besprechen.

• Keine Dateihandes zu Dateien in der Datenbank. Was bedeutet das?

  • Programmierer-Diskussion: Sie KÖNNEN NICHT suchen ( fseek), es gibt keine Möglichkeit, die Ressource mit asynchronem Zugriff zu verwalten ( asynciooder epoll), es gibt keine sendfile(Sie sparen die Kopie aus dem Kernel-Speicherplatz).

  • Praktische Anwendung: Möchten Sie ein Video oder Bild über HTTP2 / 3 an einen Client senden? Wenn es in der Datenbank ist, müssen Sie es zuerst abfragen. Unabhängig davon, welche Abfrage diese Datei zurückgibt, müssen Sie warten, bis die gesamte Abfrage abgeschlossen ist, bevor Sie mit dem nächsten Schritt fortfahren können. Bei einer Produktionsinstallation mit einem rdbms auf einem anderen Server als dem Webserver müssen Sie zuerst die Datei vollständig vom rdbms auf den Webserver übertragen, anstatt sie zu streamen. Wenn die Transportschicht jedoch eine Dateisystemabstraktion bereitstellt (die sogar von NFS unterstützt wird), können Sie nach der Hälfte der Datei suchen und sofort mit dem Streaming zum Client beginnen, ohne mehr Dateien als erforderlich zu puffern. Dies wird routinemäßig vom Webserver durchgeführtnginx , Apache , pureftp und ProFTP.

• Doppelkopie auf dem RDBMS. Aufgrund der Tatsache, dass es sich in der Datenbank befindet, werden Sie es wahrscheinlich zweimal schreiben. Einmal in einem Write-Ahead-Protokoll (WAL) und dann wieder in den Tablespace.

• Keine Aktualisierungen, MVCC bedeutet jedoch, dass nichts aktualisiert, nur mit Änderungen neu kopiert und dann die alte Zeile als abgelaufen (gelöscht) markiert wird. Bei jeder Aktualisierung der Datei muss die gesamte Zeile und nicht nur die gesamte Datei geschrieben werden. Dateisysteme können dies auch mit Datenjournaling bereitstellen, aber das brauchen Sie selten.

• Datei lesen und übertragen, um die Abfrage zu verlangsamen Wenn die Datei selbst in einer abzufragenden Zeile gespeichert ist, muss die gesamte Zeile entweder auf die Übertragung der Datei warten, oder Sie müssen zwei separate Abfragen ausführen .

• Speichernutzung auf dem DB-Client. Der DB-Client (libpq, jdbc, odbc, freetds usw.) oder dergleichen puffert die Abfrage wahrscheinlich im Speicher. Wenn dieser speicherinterne Puffer erschöpft ist, wird möglicherweise ein Plattenpuffer gestartet, oder es wird schlimmer noch auf den Kernel zurückgegriffen, der auf die Platte ausgelagert werden soll.

• Abfragedrosselung Viele Datenbanken bieten die Möglichkeit, Abfragen abzubrechen und zu ernten, wenn sie zu viel Zeit oder Ressourcen in Anspruch nehmen. Beachten Sie, dass die Dateiübertragungen in keiner Implementierung einzeln aufgeführt werden. Wurde diese Abfrage nach 3 Sekunden beendet? Oder hat es 1 Sekunde gedauert und das Backend 2 Sekunden damit verbracht, eine Datei zu übertragen? Wie können Sie effektiv angeben, wie lange eine Abfrage dauern soll, wenn 99,9% der Abfragen 1 KB und die andere 1 GB zurückgeben?

• Keine Kopie beim Schreiben oder Deduplizieren XFS und BTRFS unterstützen das transparente Kopieren beim Schreiben und Deduplizieren . Dies bedeutet, dass das Dateisystem transparent vorgehen kann, wenn überall dasselbe Bild vorhanden ist oder eine zweite Kopie benötigt wird. Wenn die Datei jedoch nicht für sich alleine steht und sich entweder in einer Zeile oder in einem Geschäft befindet, kann das Dateisystem sie wahrscheinlich nicht deduplizieren.

• Integrität Viele Menschen sprechen hier von Integrität. Was ist Ihrer Meinung nach besser für die Erkennung von Dateisystembeschädigungen, einer Anwendung, die das Dateisystem oder die Kerndienstprogramme des Dateisystems verwendet? Speichern Sie eine Datei hintereinander oder offline, und beschädigte Dateisysteme werden in der Datenbank verdeckt. xfs_repairist verdammt gut darin, Daten wiederherzustellen, wenn das Dateisystem oder die Festplatte beschädigt ist, und wenn dies fehlschlägt, ist die Datenforensik immer noch viel einfacher.

• Cloud-Migration Wenn Sie die Dateien jemals in einem SAN oder in der Cloud speichern möchten, haben Sie umso größere Schwierigkeiten, als die Speichermigration jetzt eine Datenbankmigration ist. Wenn Ihre Dateien zum Beispiel im Dateisystem gespeichert sind, können Sie sie ziemlich einfach nach S3 verschieben (und mit so etwas s3fskann es transparent sein).

Ausnahmen

Das Speichern von Dateien in der Datenbank hat einige gültige Anwendungsfälle.

• Wenn Sie benötigen übergangsweise die Datei zu bearbeiten. Das heißt, es ist buchstäblich Teil Ihrer Transaktion, die Datei zu bearbeiten. Oder Sie müssen die Möglichkeit haben, Änderungen an der Datei rückgängig zu machen, wenn die Transaktion aufgrund von Datenintegritätsproblemen in den Beziehungen (Tabellen) fehlschlägt.
• Wenn Sie sicherstellen müssen , dass das Dateisystem genau mit den Daten versioniert ist und Sie kein Risiko eingehen können, diese synchron zu halten.
• Wenn Sie die Datenbank kann die Datei tatsächlich analysieren und Sie können es abfragen. In PostgreSQL können Topologien beispielsweise Abfragen mit PostGIS sein. An diesem Punkt sind es, während es sich um eine Datei handelt, auch Daten für die Abfrage und kein Speicherabbild.

Milderungen

• Einige Datenbanken haben den Begriff "extern verwaltete Ressource", bei der die Datenbank die Datei entweder privat auf der Festplatte verwaltet, z

  • PostgreSQL über die Large Object-Infrastruktur stellt für die Dauer der Transaktion ein Dateihandle für eine Ressource bereit.

  • Die Filestream-Infrastruktur von SQL Server 2017 bietet einen temporären Zugriff, der für die Dauer der Transaktion gültig ist. Mit diesem Zugriff können Sie den Dateipfad abrufen und ein Dateihandle für öffnen.

  • Oracle bietet BFILE(das hat nichts mit ihren internen LOB Sachen zu tun , die aufgerufen wird ,SecureFile

• Einige der Datenbanken speichern große binäre Objekte offline oder können dies, wie z. B. Oracle SecureFile. Auf diese Weise können Sie die Zeile aktualisieren, ohne die Datei neu schreiben zu müssen.

• Einige Datenbanken wie Oracle führen ihre MVC ohne ein WAL-Protokoll aus und müssen das Schreiben der Datei nicht verdoppeln.

• Einige Datenbanken, wie SQL Server und Oracle, bieten die Möglichkeit, Daten aus der Datei zu "streamen", ohne jemals ein Dateihandle zu haben. Dies kann auf einer anderen Verbindung als die Datenbankabfrage ausgeführt werden oder nicht. Der Schlüssel hierbei ist jedoch, dass Sie zwar (theoretisch) die Datei streamen können , ich jedoch keine Beweise für ein Produkt finden kann, das nicht vom Anbieter erstellt wurde, der diese Funktion verwendet. Wo befindet sich zum Beispiel die NGINX / Apache-Bridge, damit Sie dies tun können?

• Oracle bietet optionale Deduplizierung, Komprimierung und Verschlüsselung über den internen LOB-Speicher (wie SecureFile).

Fazit

Das Worst-Case-Szenario, in dem Sie eine Datei in die Datenbank einfügen, ist für die Leistung und die Kompatibilität mit den Tools sehr schlecht . Es ist immer ausnahmsweise implementierungsabhängig. In keiner Weise ist die Datenbank besser als ein Dateisystem als das Dateisystem. In jeder Hinsicht handelt es sich um einen Kompromiss, und selbst wenn Sie leistungsstarke, mildernde Funktionen erhalten (wie im Fall von SecureFile), ist das Tool so schlecht, dass es nicht viel mehr als ein Marketingpunkt ist, es sei denn, Ihr gesamter Stack wird vom RDBMS-Anbieter erstellt.

Halten Sie es einfach und die allgemeine Regel ist , die Dateien aus der DB herauszuhalten .

Lösung

Wie sollten Sie Dateien speichern oder ein Dateisystem so abstrahieren, dass es für mehrere Mandanten und Benutzer effektiv funktioniert? Ich bin teilweise zu den Dateiinhalten Hashing. Das ist heutzutage ziemlich verbreitet und funktioniert gut.

Obwohl es teilweise von der Anwendung / Umgebung abhängt (einschließlich der Leute), würde ich mich für den Blob entscheiden.

Wenn Sie alles in der Datenbank behalten, funktioniert die Replikation für Dateidaten. Sie benötigen einen separaten Mechanismus, um FS-Dateien zu synchronisieren.

In einigen Anwendungen sollte das Dateisystem sowieso nicht geändert werden. Auf einer Produktionswebsite würde ich beispielsweise vermeiden, das Dateisystem jemals für nicht verfügbare Daten zu verwenden (die Site befindet sich unter einem SCM, die Daten in einer Datenbank).

Angenommen, wir haben mehrere Benutzer / Anwendungen mit separaten Berechtigungen, dann bietet jeder Dateisystemspeicher die Möglichkeit, Unterschiede in den DB- und FS-Zugriffsrechten zu erkennen.

Die Verfeinerung, die ich für den BLOB-Speicher in Betracht ziehen würde, besteht darin, Daten zu teilen, wenn dies sinnvoll ist. Wenn Sie nur 512 Bytes von einem 20-MB-BLOB benötigen, ist dieser sektorähnliche Zugriff ein echter Segen, insbesondere wenn Sie sich mit Remoteclients befassen (und ein teilweises Update erzeugt wiederum viel weniger Replikationsdatenverkehr).

Meine Stimme wäre für keine. Speichern Sie die Daten in einem System wie Amazon S3 oder Microsfts CDN und speichern Sie diese URL in der Datenbank.

Auf diese Weise haben Sie die Gewissheit, dass Sie jederzeit auf die Daten zugreifen können, ohne über Datenbanken in Monstergröße verfügen zu müssen.

Für Postgres:

Es ist eigentlich direkt vorwärts. Es gibt einen BYTEATyp, der zum Speichern von Binärzeichenfolgen verwendet werden kann. Standardmäßig gibt es keine eingebauten Hilfsprogramme wie die für MS oder Oracle genannten. Das Speichern und Abrufen vieler großer Dateien kann daher mühsam werden. Sie müssen auch die Konvertierung der Dateien innerhalb der Anwendung durchführen (wie bei einer ByteStreamoder ähnlichen, keine Ahnung, wie dies mit den spezifischen MS / Oracle-Dateidatenbanklösungen <-> funktioniert). Es gibt auch einen loTyp, der bei der Verwaltung von BLOBs hilfreich ist, da einige der internen Verwaltungsfunktionen dieser Typen die Referenzen möglicherweise nicht verfolgen.

Teilen Sie meine Erfahrungen mit Frau SQL Server und einer großen Anzahl von Dateien. Wir speichern die Dateien auf einem Dateiserver. Die Datenbank enthält zwei Tabellen, eine für die Dateiordner und die Zugangsdaten, eine für den Dateinamen. Es ist einfach, die Datenbank und die Dateien zu pflegen. Sie können die Dateien auch problemlos über die Server hinweg verschieben, indem Sie lediglich die Ordnertabelle ändern.