it-swarm-eu.dev

Sollten Binärdateien in der Datenbank gespeichert werden?

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

  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 bestehen darin, dass Sie die Speicheranforderungen (und die damit verbundenen Streaming-/Backup-Anforderungen) erheblich erhöhen können

Das Ziel von (3) ist es, die Atomizität bis zu einem gewissen Grad beizubehalten - wenn Sie durchsetzen 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 aller "vortäuscht" Mögliche Dateien und Hashes - es spielt keine Rolle, ob sich einige Dateien darin befinden, auf die nicht verwiesen wird (und Sie können 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 Ihre Datenbankdateien dadurch sehr groß und möglicherweise zu groß werden, um mit Ihrem vorhandenen Setup gesichert zu werden. Ein Vorteil ist Integrität und Atomizität.

  2. Im Dateisystem mit einem Link in der Datenbank speichern

    Ich bin dabei auf so schreckliche Katastrophen gestoßen, und es macht mir Angst, dass die Leute es immer wieder vorschlagen. Einige der Katastrophen waren:

    • Ein privilegierter Benutzer, der die Dateien neu anordnet und häufig die Verbindungen zwischen den Pfaden in der Datenbank und ihrem aktuellen Standort unterbricht (aber irgendwie wurde dies meine Schuld).
    • Beim Wechsel 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 über ACLs verfügten, die dies konnten nicht gelöst werden, wodurch den Benutzern der Benutzername/das Passwort/die Domain-Anmeldeaufforderung angezeigt wird.
    • Einige der Pfade waren länger als 256 Zeichen vom C:\ bis zum .doc und nicht alle Versionen von NT konnten lange Wege bewältigen.
  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, hat dies getan, basierend auf meiner Erklärung der obigen Szenarien. Sie hielten es für einen Kompromiss zwischen der Unfähigkeit des Unternehmens, Erfahrungen mit großen Datenbanken zu sammeln (alles, was größer als etwa 40 G ist, wurde als "zu groß" eingestuft), der Unfähigkeit des Unternehmens, große Festplatten zu kaufen, und der Unfähigkeit, einen moderneren Back zu kaufen up Lösung, und die Notwendigkeit, von den Risiken Nr. 1 und Nr. 3, die ich oben identifiziert habe, wegzukommen.

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

61
Tangurena

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

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

29
gbn

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 bereitstellen. Es ist wirklich mächtig. Siehe Blog Es gibt auch viele Optionen, um auf Ihre spezifischen Bedürfnisse abzustimmen. Als Datenbank mit einem Dateisystem (basierend auf der Datenbank, bereitgestellt 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 Kraft.

Weitere Vorteile sind: Verfügbarkeit, Sicherung, Wiederherstellung, alle in Übereinstimmung mit den anderen relationalen Daten gelesen.

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, daher ist dies kein guter Grund, nicht in der Datenbank zu speichern. Insbesondere in einer Situation, in der alte Dokumente als schreibgeschützt betrachtet werden, 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, und diese wissen nicht einmal, dass sie in einer Datenbank stöbern.

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 einige Blöcke sind.

22
ik_zelf

Ich denke, die richtige Antwort hängt stark 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 (also die meisten finanziellen, HR- oder CRM-bezogenen Dinge), 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 Anwendungen, bei denen ich die gegenteilige Entscheidung für angemessen halte.

Helpdesk-Systeme und Wiki-Systeme sind Systeme, bei denen es meiner Meinung nach sehr sinnvoll ist, die Daten out der Datenbank beizubehalten. Ich glaube, einige, wie Jira, bieten tatsächlich die Möglichkeit zu wählen, ob Sie Dokumente inline speichern möchten oder nicht.

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

Ich persönlich würde es vorziehen, ein Ticketingsystem in wenigen Minuten wieder online zu stellen und ein paar Stunden lang mit den (im Allgemeinen weniger wichtigen) Dokumenten zu ringen, als meine RTO "Es ist kaputt und der CTO atmet mir den Hals runter" zu erhöhen, indem ich sie wiederherstellen muss und Wiedergabe von Protokollen aus einer viel größeren Sicherung.

Es gibt noch weitere Vorteile, wenn Dokumente getrennt aufbewahrt werden.

  • Sie können problemlos separate Prozesse ausführen, die Dokumentmetadaten katalogisieren, Viren scannen, Schlüsselwortindizierungen durchführen usw.
  • Sie können Tools zur Unterstützung von Sicherungen oder Wiederherstellungen nutzen - Rsync, Speicher-Snapshots usw. -, die sich für Dateien viel besser eignen als für Datenbanken
  • Sie können tatsächlich Speicher verwenden, der die Komprimierung oder Deduplizierung unterstützt (das Zeug, über das Ihre SAN Admins seit Jahren geredet haben, auch bekannt als der Fluch der Datenbankadministratoren weltweit).
  • Bei einer Installation über mehrere Standorte hinweg können Sie eine zentralisierte Datenbank durch ein verteiltes Dateisystem ergänzen

Ich denke, eine Hybridkombination aus # 2 und # 3 könnte klug sein. Behalten Sie die ursprünglichen Dateinamen bei, berechnen und speichern Sie jedoch einen Hash/eine Prüfsumme des Dokuments, sodass Sie einen Referenzpunkt 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 über das Kabel senden können oder in einer dicken Client-Welt den Benutzer möglicherweise sogar direkt auf den Dateiserver verweisen können.

15
Nathan Jolly

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.

Weiter zu den Fakten:

Verwenden der Datenbank

" [~ # ~] Profis [~ # ~] " ... aber nicht ganz :

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

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

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

Nachteile:

  • Falsches Werkzeug für den Job
  • Schwieriger zu pflegen
  • Langsam
  • Vergessen Sie das Speichern von Hunderten von MB/Gigabyte Daten PRO Benutzer .
  • Das Sichern schnell wachsender Websites wird ein Albtraum sein.
  • Wiederherstellen/Bewegen wird auch saugen.

Verwenden des Dateisystems

PROS:

  • Viel einfacher zu pflegen
  • Schnell
  • Datenbanksicherungen haben damit nichts zu tun
  • Wohl mehr Portabilität *

[~ # ~] Nachteile [~ # ~] :

  • Keiner*

* Kleingedrucktes

Im Moment fragst du dich, warte, 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 würde so weit gehen zu sagen nur Grund, warum dies gefragt wird, sind Dateilinks .

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

"Die Datenbank behebt Probleme beim Verknüpfen von Dateien."

In der Realität sollte logischerweise die Anwendung tatsächlich für die Handhabung und Bereitstellung verantwortlich sein. -) Links.

Eine Lösung:

  1. Lassen Sie Ihre Anwendung URL-Anfragen mit benutzerdefinierten Routen verarbeiten.
  2. Speichern Sie diese Route in Ihrer Datenbank.
  3. Intern jedes Mal, wenn diese Route aufgerufen wird, ordnen Sie sie der gewünschten Datei zu.
  4. Wenn Sie Ihre Dateien jemals an einen anderen Ort verschieben, ändern Sie einfach den Dateinamenwert der Route. Diese Route wird immer dieselbe Datei bereitstellen, unabhängig davon, wo sie im Web gespeichert oder referenziert 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 geht über den Rahmen dieser Antwort hinaus. Sie können sich jedoch ein allgemeines Beispiel in der wohl am weitesten verbreiteten Web-Sprache (PHP) ansehen:

https://github.com/symfony/Routing

https://github.com/kriswallsmith/assetic

Beide zusammen sind wirklich mächtig.

14
Tek

Ich möchte hier meine Erfahrungen 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 Haupt-Heap-Tabellen, um sie aus Operationen zu entfernen, bei denen möglicherweise eine große Anzahl von Datensätzen gezählt 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 hängt dies möglicherweise von der Implementierung ab, aber für PostgreSQL werden die Daten als Escapezeichen ASCII Zeichenfolge (möglicherweise hexadezimal, möglicherweise mit Inline-Escapezeichen) eingegeben muss dann im Frontend wieder in binär konvertiert werden. Viele Frameworks, die ich dafür gesehen habe, beinhalten das Übergeben des Werts (nicht als Referenz) und das Erstellen einer neuen binären Zeichenfolge basierend darauf. Ich habe dies mit Perl berechnet Am Ende wurde der Speicher der ursprünglichen Binärdatei um ein Vielfaches verwendet.

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

9
Chris Travers

Speichern Sie keine Dateien in einer Datenbank.

Jeder, der ausnahmslos jedes RDBMS auf dem Markt ausführen kann, verfügt bereits über eine Datenbank speziell zum Speichern von Dateien, und das RDBMS selbst verwendet sie! Diese Datenbank ist das Dateisystem . Lassen Sie uns nun einige der möglichen Nachteile des Speicherns von Dateien in der Datenbank sowie einige spezifische mildernde Faktoren für das Speichern von Dateien in der Datenbank erläutern.

  • Nein Dateihand zu Dateien in der Datenbank. Was bedeutet das?

    • Programmierer-Talk: Sie KÖNNEN NICHT suchen (fseek), es gibt keine Möglichkeit, die Ressource mit asynchronem Zugriff zu verwalten (asyncio oder epoll), es gibt kein sendfile (speichert die Kopie aus dem Kernelraum).

    • Praktische Anwendung: Möchten Sie ein Video oder Bild über HTTP2/3 an einen Client senden? Wenn es sich in der Datenbank befindet, müssen Sie es zuerst abfragen. Für jede Abfrage, die diese Datei zurückgibt, müssen Sie warten, bis die Abfrage gesamt abgeschlossen ist, bevor diese Datei mit dem nächsten Schritt fortfahren kann. Bei einer Produktionsinstallation mit einem rdbms auf einem anderen Server als dem Webserver müssen Sie zuerst die Datei vollständig übertragen von der rdbms zum webserver anstatt es durch 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 damit beginnen, sie zurück zum Client zu streamen, ohne mehr von der Datei als erforderlich zu puffern. Dies wird routinemäßig vom Webserver nginx , Apache , PureFTP und ProFTP durchgeführt.

  • Doppelte Kopie 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 Updates, nie MVCC bedeutet, dass nichts aktualisiert wird, nur mit Änderungen neu kopiert wird und dann die alte Zeile abgerufen wird als abgelaufen markiert (gelöscht). Für jede Aktualisierung der Datei muss die gesamte Zeile geschrieben werden, nicht nur die gesamte Zeile. Dateisysteme können dies auch mit Datenjournal bereitstellen, aber das benötigen Sie selten.

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

  • Speichernutzung auf dem DB-Client. Der DB-Client (libpq, jdbc, odbc, freetds usw.) oder dergleichen wird die Abfrage wahrscheinlich im Speicher puffern. Wenn dieser speicherinterne Puffer erschöpft ist, kann er einen Festplattenpuffer starten oder, noch schlimmer, auf den Kernel zurückgreifen, um auf die Festplatte ausgelagert zu werden.

  • Abfrage-Drosselung Viele Datenbanken bieten die Möglichkeit, Abfragen zu beenden und zu ernten, wenn sie entweder zu viel Zeit oder Ressourcen beanspruchen. Beachten Sie, dass die Dateiübertragungen in keiner Implementierung 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? Nicht nur "aufgeschlüsselt", wie können Sie effektiv angeben, wie viel Zeit eine Abfrage in Anspruch nehmen soll, wenn 99,9% der Abfragen 1 KB und die andere 1 GB zurückgeben?

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

  • Integrität Viele Leute hier sprechen über Integrität. Was ist Ihrer Meinung nach besser, um eine Beschädigung des Dateisystems zu erkennen, eine Anwendung, die das Dateisystem oder die Kerndienstprogramme des Dateisystems verwendet? Speichern Sie eine Datei in einer Reihe oder außerhalb der Zeile, und jede Beschädigung des Dateisystems wird in der Datenbank verdeckt. xfs_repair Kann verdammt gut wiederherstellen, wenn das Dateisystem oder die Festplatte beschädigt ist. Wenn dies fehlschlägt, ist die Datenforensik immer noch viel einfacher.

  • Cloud-Migration Wenn Sie die Dateien jemals auf einem SAN oder der Cloud) speichern möchten, haben Sie umso größere Schwierigkeiten, als jetzt dieser Speicher- Migration ist eine Datenbankmigration. Wenn Ihre Dateien beispielsweise im Dateisystem gespeichert sind, können Sie sie ziemlich einfach nach S3 verschieben (und mit etwas wie s3fs kann es transparent sein). .

Ausnahmen

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

  • Wenn Sie benötigen, um die Datei vorübergehend zu bearbeiten. Das heißt, es ist buchstäblich Teil Ihrer Transaktion, die Datei zu bearbeiten. Oder Sie müssen die Möglichkeit, Änderungen an der Datei rückgängig zu machen, wenn die Transaktion aufgrund von Datenintegritätsproblemen in den Beziehungen (Tabellen) fehlschlägt.
  • Wenn Sie benötigen, um sicherzustellen, dass das Dateisystem genau mit den Daten versioniert ist und Sie sich kein Risiko leisten können, sie synchron zu halten.
  • Wenn Sie die Datenbank tatsächlich analysieren können, können Sie die Datei abfragen. In PostgreSQL können Topologien beispielsweise Abfragen mit PostGIS sein. Zu diesem Zeitpunkt handelt es sich zwar um eine Datei, aber auch um Daten für die Abfrage und nicht um einen Speicherauszug.

Milderungen

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

  • Einige der Datenbanken speichern große Binärobjekte außerhalb der Zeile oder können, 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 WAL-Protokoll durch und müssen das Schreiben der Datei nicht verdoppeln.

  • Einige der 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 der Datenbankabfrage ausgeführt werden oder nicht. Der Schlüssel hier ist jedoch, dass Sie, während Sie können die Datei streamen (theoretisch), keine Beweise für ein Produkt finden können, das nicht von dem Anbieter hergestellt wurde, der diese Funktion verwendet. Wo befindet sich beispielsweise die NGINX/Apache-Brücke, damit Sie dies tun können?

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

Fazit

Das schlimmste Szenario, wenn Sie eine Datei in die Datenbank einfügen, ist sehr schlecht für die Leistung und Kompatibilität mit Tools. Es ist immer außergewöhnlich implementierungsabhängig. In keiner Weise ist die Datenbank besser als ein Dateisystem als das Dateisystem. In jeder Hinsicht ist es ein Kompromiss, und selbst wenn Sie leistungsstarke Schadensbegrenzungsfunktionen erhalten (wie im Fall von SecureFile), ist das Tooling so schlecht, dass es wirklich 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 lautet . Halten Sie die Dateien aus der Datenbank heraus .

Lösung

Wie sollten Sie Dateien speichern oder ein Dateisystem so abstrahieren, dass es effektiv für mehrere Mandanten und Benutzer funktioniert? Ich bin teilweise daran interessiert, den Dateiinhalt zu hashen. Dies ist heutzutage ziemlich häufig und funktioniert gut.

9
Evan Carroll

Früher hat Microsoft die Möglichkeit, Bilder (und ähnliche Blob-Datentypen) in der Datenbank zu speichern, verbessert. 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 sprangen auf den Zug.

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 von Ihnen gespeicherten BLOBS sehr groß werden. Dies wirkt sich auf Sicherungen, Speicheranforderungen, zeitkritische Wiederherstellungsvorgänge usw. aus.

SQL Server 2008 führte das Datei-Streaming ein. Die Datenbank enthält Zeiger 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 groß werden, aber Sie erhalten keine verwaisten Dateien/Dokumente/Blobs/Bilder.

Meine persönliche Präferenz war es, die Datenbank Zeiger/Netzwerkspeicherorte speichern zu lassen und einen Dateiserver die Dateien verarbeiten zu lassen. Dateiserver sind ohnehin besser für solche Aufgaben optimiert.

7
datagod

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 erhalten Sie die Zuverlässigkeit, dass die Daten immer verfügbar sind, ohne dass Datenbanken in Monstergröße verarbeitet werden müssen.

6
paullb

Obwohl es teilweise von der Anwendung/Umgebung abhängt (einschließlich der Personen), 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 ohnehin nicht geändert werden. Auf einer Produktionswebsite würde ich beispielsweise vermeiden, das Dateisystem jemals für nicht verfügbare Daten zu verwenden (die Website befindet sich unter einem SCM, Daten in einer Datenbank).

Angenommen, wir haben mehrere Benutzer/Anwendungen mit separaten Berechtigungen, bietet jeder Dateisystemspeicher die Möglichkeit für Unterschiede in der Datenbank und den Zugriffsrechten FS).

Die Verfeinerung, die ich für den BLOB-Speicher in Betracht ziehen würde, besteht darin, Daten zu zerlegen, wenn dies sinnvoll ist. Wenn Sie nur 512 Bytes von einem 20-MB-BLOB benötigen, ist dieser sektorähnliche Zugriff ein wahrer Segen, insbesondere wenn Sie mit Remoteclients arbeiten (und auch hier führt eine teilweise Aktualisierung zu viel weniger Replikationsverkehr).

6
Phil Lello

Für Postgres:

Es ist eigentlich direkt vorwärts. Es gibt einen BYTEA Typ, der zum Speichern von Binärzeichenfolgen verwendet werden kann. Standardmäßig gibt es keine eingebauten Dienstprogramme 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 einem ByteStream oder ähnlichem, aber keine Ahnung, wie dies mit den spezifischen Datenbanklösungen für MS/Oracle-Dateien <-> funktioniert). Es gibt auch einen Typ lo , der bei der Verwaltung von BLOBs hilfreich ist, da einige der internen Verwaltungen dieser Typen die Referenzen möglicherweise nicht verfolgen.

3
DrColossos