Ist es eine schlechte Praxis, große Dateien (10 MB) in einer Datenbank zu speichern?

188

Ich erstelle gerade eine Webanwendung, mit der Benutzer Dateien mit einer Größe von 1 MB bis 10 MB speichern und freigeben können.

Mir scheint, dass das Speichern der Dateien in einer Datenbank den Datenbankzugriff erheblich verlangsamt.

Ist das ein berechtigtes Anliegen? Ist es besser, die Dateien im Dateisystem zu speichern und den Dateinamen und den Pfad in der Datenbank zu speichern? Gibt es Best Practices für das Speichern von Dateien beim Arbeiten mit einer Datenbank?

Ich arbeite in PHP und MySQL für dieses Projekt, aber es ist das gleiche Problem für die meisten Umgebungen ( Ruby on Rails , PHP , .NET ) und Datenbanken (MySQL, PostgreSQL ).

B Sieben
quelle
9
Verwandte Frage zu DBA.SE: Dateien - in der Datenbank oder nicht?
Nick Chammas
11
Überrascht, dass niemand die zu diesem Problem durchgeführten MS-Untersuchungen veröffentlicht hat (für SQL Server 2008): Zu BLOB oder Nicht-BLOB: Speicherung großer Objekte in einer Datenbank oder einem Dateisystem
Datum
2
groß ist eine relative Größe, die ich (und viele andere wahrscheinlich) 10MBin einem modernen System nicht so groß sehe .
27
Dies ist laut FAQ themenbezogen - es passt unter die Aufzählungszeichen "Design Patterns" (Slash Antipatterns) und "Software Architecture". Warum war es geschlossen?
Izkata,
21
Ich sehe keine Unbestimmtheit in der Frage, wie es jetzt ist. Ich habe keine Ahnung, warum es geschlossen wurde.
reinierpost

Antworten:

139

Gründe für das Speichern von Dateien in der Datenbank:

  1. ACID-Konsistenz, einschließlich eines Rollbacks eines Updates, das kompliziert ist, wenn die Dateien außerhalb der Datenbank gespeichert werden. Dies ist nicht leichtfertig zu beschönigen. Es kann sehr nützlich sein, die Dateien und die Datenbank synchron zu halten und an Transaktionen teilnehmen zu können.
  2. Dateien gehören zur Datenbank und können nicht von dieser verwaist werden.
  3. Backups enthalten automatisch die Datei-Binärdateien.

Grund gegen das Speichern von Dateien in der Datenbank:

  1. Die Größe einer Binärdatei unterscheidet sich zwischen Datenbanken. Unter SQL Server sind es beispielsweise 2 GB, wenn das FILESTREAM-Objekt nicht verwendet wird. Wenn Benutzer größere Dateien speichern müssen (z. B. einen Film), müssen Sie durch die Rahmen springen, um diese Magie zu verwirklichen.
  2. Erhöht die Größe der Datenbank. Ein allgemeines Konzept, das Sie zu Herzen nehmen sollten: Der Wissensstand, der für die Pflege einer Datenbank erforderlich ist, steigt proportional zur Größe der Datenbank.Das heißt, große Datenbanken sind schwieriger zu warten als kleine Datenbanken. Durch das Speichern der Dateien in der Datenbank kann die Datenbank erheblich vergrößert werden. Selbst wenn eine tägliche vollständige Sicherung mit einer größeren Datenbank ausgereicht hätte, können Sie dies möglicherweise nicht mehr tun. Möglicherweise müssen Sie in Betracht ziehen, die Dateien in eine andere Dateigruppe zu verschieben (sofern die Datenbank dies unterstützt), die Sicherungen zu optimieren, um die Sicherung der Daten von der Sicherung der Dateien usw. zu trennen Die Wartung wird komplexer, was sich auf die Kosten des Unternehmens auswirkt. Größere Datenbanken belegen auch mehr Speicher, da sie versuchen, so viele Daten wie möglich in den Speicher zu schreiben.
  3. Die Portabilität kann problematisch sein, wenn Sie systemspezifische Funktionen wie das FILESTREAMObjekt von SQL Server verwenden und auf ein anderes Datenbanksystem migrieren müssen.
  4. Der Code, der die Dateien in die Datenbank schreibt, kann ein Problem sein. Ein Unternehmen, für das ich vor nicht allzu vielen Monaten Rücksprache gehalten habe, hat irgendwann ein Microsoft Access-Frontend mit seinem Datenbankserver verbunden und die Fähigkeit von Access genutzt, mithilfe seines Ole Object-Steuerelements "alles" hochzuladen. Später wechselten sie zu einer anderen Steuerung, die sich noch immer auf Ole stützte. Viel später änderte jemand die Schnittstelle, um die rohe Binärdatei zu speichern. Das Extrahieren dieser alten Objekte war eine neue Ebene der Hölle. Wenn Sie Dateien im Dateisystem speichern, ist keine zusätzliche Ebene erforderlich, um die Quelldatei umzubrechen, zu optimieren oder zu ändern.
  5. Es ist komplizierter, die Dateien auf einer Website bereitzustellen. Um dies mit binären Spalten zu tun, müssen Sie einen Handler schreiben, um die Binärdatei aus der Datenbank zu streamen. Sie können dies auch tun , auch wenn Sie Dateipfade zu speichern , aber sie nicht haben , um dies zu tun. Auch hier ist das Hinzufügen eines Handlers nicht unmöglich, erhöht jedoch die Komplexität und ist eine weitere Fehlerquelle.
  6. Sie können den Cloud-Speicher nicht nutzen. Angenommen, Sie möchten Ihre Dateien eines Tages in einem Amazon S3-Bucket speichern. Wenn es sich bei dem, was Sie in der Datenbank speichern, um Dateipfade handelt, können Sie diese in S3 in Pfade ändern. Soweit mir bekannt ist, ist dies in keinem Szenario mit einem DBMS möglich.

IMO erfordert mehr Informationen über die Umstände und Anforderungen, wenn die Speicherung von Dateien in der Datenbank als "schlecht" oder nicht als "schlecht" eingestuft wird. Werden die Größe und / oder Anzahl der Dateien immer klein sein? Gibt es keine Pläne für die Verwendung von Cloud-Speicher? Werden die Dateien auf einer Website oder einer ausführbaren Binärdatei wie einer Windows-Anwendung bereitgestellt?

Generell habe ich die Erfahrung gemacht, dass das Speichern von Pfaden für das Unternehmen kostengünstiger ist, selbst wenn das Fehlen von ACID und die Möglichkeit von Waisen berücksichtigt werden. Dies bedeutet jedoch nicht, dass das Internet keine Legion mit Berichten über mangelnde ACID-Kontrolle ist, die beim Speichern von Dateien schief gehen. Es bedeutet jedoch, dass diese Lösung im Allgemeinen einfacher zu erstellen, zu verstehen und zu warten ist.

Thomas
quelle
Warum können Sie keine CDNs verwenden? Dies ist ein unterstütztes Szenario mit so ziemlich jedem CDN, von dem ich je gehört habe.
Billy ONeal
@BillyONeal - Sie können kein CDN verwenden und die Datei nicht in der Datenbank speichern. Wenn Sie mit der Duplizierung nicht einverstanden sind, können Sie nicht beides haben.
Thomas
3
Ähm, der springende Punkt bei einem CDN ist die Vervielfältigung. CDNs speichern lediglich das Ziel einer Webadresse im Cache. Die einzige Voraussetzung ist, dass ein HTTP-Host für den Inhalt vorhanden ist und sich der Inhalt nur selten ändert. (Wie um alles in der Welt soll das CDN sagen, woher Sie das Bild haben?)
Billy ONeal
3
@BillyONeal - Ich denke jedoch, dass dies eine schlechte Wortwahl meinerseits ist und ich habe meine Antwort angepasst. Insbesondere, wenn Sie Cloud-Speicher verwenden möchten (und dann möglicherweise ein CDN für Ihren Cloud-Speicher verwenden möchten ), können Sie dies nicht nativ mit der Datenbankspeicherlösung tun. Sie müssten eine Synchronisierungsroutine schreiben, um die Dateien aus der Datenbank abzurufen und sie dann an Ihren Cloud-Speicheranbieter zu senden.
Thomas
@BillyONeal - In gewisser Weise war Ihr Kommentar die beste Antwort. Sie können alle Vorteile des DB-Speichers nutzen, aber keines der Probleme.
B Seven
89

In vielen Fällen ist dies eine schlechte Idee. Es wird die Datenbankdateien aufblähen und mehrere Leistungsprobleme verursachen. Wenn Sie die Blobs in eine Tabelle mit einer großen Anzahl von Spalten stecken, ist es noch schlimmer.

Jedoch! Einige Datenbanken, z. B. SQL Server, haben den Spaltentyp FILESTREAM. In diesem Fall werden Ihre Daten tatsächlich in einer separaten Datei auf dem Datenbankserver gespeichert, und in der Tabelle wird nur eine ID für die Datei gespeichert. In diesem Fall sehe ich kaum einen Grund, die Daten nicht im SQL Server zu behalten. Die Dateien werden automatisch als Teil der Serversicherung einbezogen, und die Datenbank und die Dateien sind nie nicht synchron. Das Problem mit Tonys Vorschlag, Dateinamen zu speichern, ist, dass die Datenbank und das Dateisystem nicht mehr synchron sind. Die Datenbank behauptet, dass eine Datei vorhanden ist, wenn sie auf der Festplatte gelöscht wurde. Wenn ein Prozess die Datenbank ändert und dann abstürzt, stimmen die Dateien und die Datenbank nicht überein (dh keine ACID mit Dateien außerhalb einer Datenbank).

Timothy Baldridge
quelle
21
Ich bin mit der Aussage nicht einverstanden: "Wenn ein Prozess die Datenbank ändert und dann abstürzt, stimmen die Dateien und die Datenbank nicht überein." Wenn Sie den gesamten Prozess in eine Transaktion einschließen (Datei erstellen, Datei validieren, Datenbank aktualisieren) und Fehlermeldungen ausgeben Wenn etwas schief geht, ist es ganz einfach, sie synchron zu halten.
Briddums
3
Ich bin mit Briddums darüber: Betrachten Sie Szenario: Datei im Dateisystem speichern (ohne alte zu löschen), DB aktualisieren, bei Erfolg alte Datei löschen, bei Rollback neue Datei löschen. Worst-Case-Szenario - Wenn der Prozess unterbrochen wird, haben Sie eine verwaiste Datei. Aber Sie haben immer die Dateien, auf die DB verweist, in der richtigen Version.
Vartec
2
Weitere mögliche Probleme mit der File / DB-Methode: 1) Sie müssen Aktualisierungen als Copy-on-Write durchführen. Wenn Ihr Prozess während eines Updates abstürzt, wird der DB-Status zurückgesetzt, die Datei jedoch nicht. 2) Dies erfordert dann eine Art Garbage Collection der alten Datei. 3) Wenn Sie alles in der Datenbank speichern, sind die Versionen der Datenbank und der Dateien nach den Sicherungen synchron. Stellen Sie vor 2 Wochen Ihren DB-Status wieder her. Was war nun der Inhalt der Dateien zu diesem Zeitpunkt?
Timothy Baldridge
3
@briddums - Nein, da SQL Server direkt in das Dateisystem integriert ist und diese Dateien im Auftrag des Betriebssystems verwaltet. Ich habe sie selbst nicht verwendet, aber die Dokumentation lässt es so aussehen, als ob FILESTREAM und seine Nachkommen FileTables Ihnen das Beste aus beiden Welten bieten: Dateien sind eng an die Datenbank gebunden und verknüpfen Daten (so dass Sie Ihre Daten zentral verwalten können), ohne die Datenbank.
Nick Chammas
1
Ich stimme Nick zu. Wir haben unser Disk + DB-System durch FILESTREAM-Spalten ersetzt und nie zurückgeschaut. Es ist wirklich schön, Dateien über FKs mit anderen Tabellen verknüpfen zu können. Sie können also tatsächlich sagen, dass jeder Person ein oder mehrere HR-Dokumente zugeordnet sein müssen, oder etwas Ähnliches.
Timothy Baldridge
35

Ja, das ist eine schlechte Praxis.

Leistungseinflüsse auf die DB:

  • Wenn Sie eine SELECTmit einer BLOB-Spalte ausführen, wird immer auf die Festplatte zugegriffen, während Sie ohne BLOBs die Möglichkeit haben, Daten direkt aus dem RAM abzurufen (die DB mit hohem Durchsatz wird so optimiert, dass sie Tabellen in den RAM einfügt).
  • Die Replikation ist langsam, die Replikationsverzögerung hoch, da BLOB an die Slaves weitergeleitet werden muss. Eine hohe Replikationsverzögerung führt zu allen möglichen Race-Bedingungen und anderen Synchronisationsproblemen, sofern Sie dies nicht ausdrücklich berücksichtigen.
  • DB Backups / Restores dauern viel länger.

Geschwindigkeitsvorteil - keiner ! Während einige ältere Dateisysteme Verzeichnisse mit Millionen von Dateien nicht gut handhaben würden, haben die meisten modernen überhaupt kein Problem und verwenden tatsächlich dieselbe Art von Datenstrukturen wie BDs (typischerweise B-Bäume). Zum Beispiel verwendet ext4 (Standard-Linux-Dateisystem) Htree .

Fazit: Dies beeinträchtigt die Leistung Ihrer Datenbank und verbessert nicht die Leistung beim Abrufen von Dateien.

Da es sich um eine Webanwendung handelt, ist das Bereitstellen statischer Dateien direkt aus dem Dateisystem mithilfe eines modernen Webservers, der sendfile()Syscall ausführen kann, eine enorme Leistungsverbesserung. Dies ist natürlich nicht möglich, wenn Sie Dateien aus der DB abrufen. Betrachten Sie zum Beispiel diesen Benchmark , in dem Ngnix 25 KBit / s mit 1000 gleichzeitigen Verbindungen auf einem Low-End-Laptop ausführt . Diese Art von Ladung würde jede Art von DB braten.

vartec
quelle
6
+1. Lassen Sie Ihren Webserver das tun, was er am besten kann, und stellen Sie Dateien von der Festplatte bereit. Lassen Sie es nicht PHP fragen, da PHP MySQL usw. fragen muss
deizel
3
Wann werden Programmierer erfahren, dass Leistung nicht alles ist, was zählt?
reinierpost
2
@reinierpost: lol. wahrscheinlich, wenn wir liberal arts
majors
1
@BillyONeal: warum nimmst du an, dass du denselben Server für statische und dynamische Inhalte haben musst? Für die Synchronisierung von Dateien zwischen Servern gibt es speziell dafür entwickelte Tools, die viel effizienter sind als Datenbanken. Die Verwendung der Datenbank als Dateiserver ist wie der Versuch, einen Nagel mit einem Schraubendreher zu hämmern.
Vartec
1
@BillyONeal: Ich stimme zu, dass es einige "Lösungen" gibt, bei denen das funktionieren würde. Ich habe ziemlich viele Amateur-PHP-Setups mit Bildern in MySQL gesehen. In einer solchen Konfiguration unterstützt eine Datenbank jedoch niemals BLOBs mit hohem Datenverkehr.
Vartec
18

Ich wäre pragmatisch und würde dem Prinzip "noch nicht optimieren" folgen. Entscheiden Sie sich für eine Lösung, die im Moment Sinn macht und für die Sie die Entwicklungsressourcen haben, die Sie ordnungsgemäß implementieren können. Es gibt viele mögliche Probleme . Aber diese werden nicht unbedingt zu echten Problemen. ZB wäre es wahrscheinlich kein Problem, wenn Sie 100 Benutzer haben. Es könnte ein Problem sein, wenn Sie 100.000 oder 10.000.000 Benutzer haben. Im letzteren Fall sollte es jedoch eine Grundlage für mehr Entwicklungsressourcen geben, um alle Probleme zu lösen.

Das Speichern der Daten in der Datenbank entlastet Sie jedoch nicht von anderen Problemen, z. B. wo die Dateien gespeichert werden sollen, wie sie gesichert werden sollen usw. Da Sie eine Webanwendung schreiben, ist dies aus Sicherheitsgründen eine sehr gute Idee Um sicherzustellen, dass der Prozess, der die Anwendung hostet, keinen Schreibzugriff auf das Dateisystem hat, müssen Sie den Server so konfigurieren, dass der Prozess Lese- / Schreibzugriff auf den Ordner hat, in dem die Daten gespeichert sind.

Ich persönlich würde wählen, die Daten in der Datenbank zu speichern, aber sicherstellen, dass die BLOBS nicht gelesen werden, bis sie wirklich benötigt werden, dh kein "SELECT * FROM ..." für die Tabellen, die Blogs enthalten. Und ich würde sicherstellen, dass das Design es einfach macht, die Daten aus der Datenbank in das Dateisystem zu verschieben, wenn Leistungsprobleme auftreten. Speichern Sie beispielsweise die Dateiinformationen in einer separaten Dateitabelle , um die Dateiinformationen von anderen Unternehmenseinheiten fernzuhalten.

Angenommen, Sie haben eine File- Klasse zum Darstellen einer in der Datenbank gelesenen Datei, dann ist der Codierungsaufwand beim späteren Verschieben minimal.

Pete
quelle
Dies ist ein ausgezeichneter Vorschlag. Lösen Sie keine Probleme, die Sie nicht haben.
Schwere
16

Microsoft hat dazu vor einigen Jahren ein Whitepaper veröffentlicht. Es konzentriert sich auf SqlServer, aber Sie können einige interessante Informationen darin finden:

BLOB oder nicht BLOB? Großobjektspeicher in einer Datenbank oder einem Dateisystem?

Eine sehr knappe Fassung ihrer Schlussfolgerung lautet:

Beim Vergleich des NTFS-Dateisystems mit SQL Server 2005 werden BLOBS mit einer Größe von weniger als 256 KB von SQL Server effizienter verarbeitet, während NTFS für BLOBS mit einer Größe von mehr als 1 MB effizienter ist.

Ich würde empfehlen, dass Sie einige kleine Tests für Ihren speziellen Anwendungsfall schreiben. Denken Sie daran, dass Sie auf Caching-Effekte achten müssen. (Ich war erstaunt, als ich zum ersten Mal Speicherkapazitäten bekam, die einen höheren Durchsatz zu haben schienen, als dies physikalisch möglich war!)

Benjol
quelle
4
Sie sollten wissen, dass sich NTFS sehr unregelmäßig verhält, wenn Sie mehr als ~ 100K-Dateien in einem einzigen Verzeichnis ablegen. Der Dateizugriff verlangsamt sich erheblich (mindestens eine Größenordnung) und die Operationen zum Öffnen von Dateien schlagen (scheinbar) zufällig fehl. Ich habe diesen Effekt auf Windows 2008- und Windows 7-Systemen erlebt. Wenn ich Dateien auf mehrere Verzeichnisse umverteilte, kehrte alles zum Normalzustand zurück. Ich weiß nicht, ob sich die Situation seitdem verbessert hat.
Ferruccio
11

Die alte konventionelle Weisheit, Dateien außerhalb der Datenbank zu speichern, ist möglicherweise nicht mehr gültig. Grundsätzlich würde ich Integrität der Geschwindigkeit vorziehen, und mit einem modernen DBMS können Sie beides haben.

Tom Kyte scheint zuzustimmen :

Ich kenne keine Vorteile beim Speichern von Daten, die ich für längere Zeit außerhalb einer Datenbank aufbewahren möchte.

Wenn es in der Datenbank ist, kann ich

Stellen Sie sicher, dass es professionell verwaltet wird

Gesichert

wiederherstellbar (mit dem Rest der Daten)

gesichert

skalierbar (versuchen Sie 100.000 Dokumente in ein einziges Verzeichnis zu legen, und legen Sie sie in eine Tabelle - welche skaliert - es ist nicht das Verzeichnis)

Ich kann (Rückblende) leicht wiederherstellen

Ich habe einen Verschluss

Ich habe Konsistenz gelesen ...

Branko Dimitrijevic
quelle
8

Ja.

Wenn Sie eine Datei aus Ihrem Dateisystem bereitstellen, kann Ihr Webserver Kernel-Code wie sendfile () unter BSD oder Linux verwenden, um die Datei direkt in den Socket zu kopieren. Es ist sehr schnell und sehr effizient.

Wenn Sie Dateien aus der Datenbank bereitstellen, müssen Sie Daten von der Festplatte des Datenbankservers in den Speicher des Datenbankservers kopieren, dann vom Speicher des Datenbankservers in den Netzwerkport des Datenbankservers, dann vom Netzwerk in den Webserverprozess und dann wieder in den ausgehende Netzwerkverbindung.

Sofern Sie keinen guten Grund haben, dies nicht zu tun, ist es immer besser, statische Dateien aus dem Dateisystem bereitzustellen.

Evan P.
quelle
Dies ist wahr, aber ich kann nicht erkennen, wo der Benutzer in der Frage angibt, dass er statische Dateien aus der Datenbank bereitstellen wird. Dies können sehr gut dynamische Dateien oder vom Benutzer hochgeladene Dateien sein, die, wenn sie im Dateisystem gespeichert sind und von der Datenbank getrennt sind, jetzt synchronisiert werden müssen und einen separaten Sicherungs- / Wiederherstellungsprozess haben.
maple_shaft
1
Meines Erachtens geht es bei der Frage darum, vom Benutzer hochgeladene Dateien bereitzustellen. "Ich erstelle gerade eine Webanwendung, mit der Benutzer Dateien speichern und freigeben können. [...] Es scheint mir, dass die Dateien in einer Datenbank gespeichert werden. [...]" Ich denke nicht, dass es wirklich so bequem ist, DB-Dumps mit vielen Multi-Megabyte-Blobs in der Datenbank zu erstellen. Außerdem: Ja, es ist schwierig, mit Dateien umzugehen. Synchronisation und Archivierung sind schwieriger. Es ist jedoch nicht viel schwieriger, und es ist ein großer Fehler, die Online-Leistung zu opfern, um ein paar Zeilen in Ihrem nächtlichen Backup-Skript zu speichern.
Evan P.
5

Der berühmte Tom Kyte hat geschrieben, dass sie (das Oracle) die Oracle-Datenbank als Dateiserver verwenden und dass sie einwandfrei funktioniert, sogar schneller als das normale Dateisystem, mit vollständiger Transaktionalität, ohne Leistungsverlust und mit einer einzelnen Sicherung.

Ja, aber beachten Sie, dass sie der Hersteller der Oracle-Datenbank sind und für alle anderen Benutzer Kostenprobleme auftreten. Kommerzielle Datenbanken wie Oracle für die Speicherung von Dateien zu verwenden, ist einfach ineffektiv.

Mit PostgreSQL zum Beispiel können Sie jedoch einfach eine andere DB-Instanz nur zum Speichern von Blobs ausführen. Sie haben dann volle Transaktionsunterstützung. Die Transaktionalität kostet jedoch Speicherplatz in der Datenbank. Die Datenbank muss mehrere Blob-Instanzen für mehrere gleichzeitige Transaktionen speichern. Unter PostgreSQL ist dies am schmerzhaftesten, da in dieser Datenbank die Duplikate der für die Transaktion erstellten Blobs gespeichert werden, auch wenn sie nicht mehr benötigt werden, bis der VACUUM-Prozess abgeschlossen ist.

Andererseits müssen Sie beim Speichern von Dateisystemen sehr vorsichtig sein, wenn jemand die Datei ändert, da die Transaktion zurückgesetzt werden kann und die Kopie der Datei aufbewahrt werden muss, bis die alte Version nicht mehr sichtbar ist.

In dem System, in dem Dateien nur hinzugefügt und gelöscht werden und der transaktionale Zugriff auf Dateien kein Problem darstellt, ist der Dateisystemspeicher meiner Meinung nach die beste Wahl.

Donau Seemann
quelle
Hallo, wenn Sie sagten "Oracle für die Speicherung von Dateien zu verwenden ist einfach kostengünstig", was ist, wenn wir bereits Oracle für die Speicherung anderer Nicht-Dateidaten verwenden? Wird das immer noch ineffektiv sein?
Xiao Peng - ZenUML.com
RE: "Sie müssen sehr vorsichtig sein, wenn jemand die Datei ändert" ... Als ehemaliger Oracle DBA muss ich vorschlagen, dass große Dateien nicht in der Datenbank gespeichert werden und dass Sie niemals zulassen, dass die Dateien geändert werden. Menschen machen Fehler. Die einzige praktische Möglichkeit, das Rollback (Rückgängigmachen) dieser Dateien zu verwalten, besteht darin, ein Copy On Write-System für sie zu implementieren. Alle Versionen werden somit gepflegt und archiviert. Die ältesten können in den
Remotespeicher
5

In der Regel ist es am besten, große BLOBs in einer separaten Tabelle zu speichern und einen Fremdschlüsselverweis auf das BLOB in Ihrer Haupttabelle zu speichern. Auf diese Weise können Sie die Datei immer noch aus der Datenbank abrufen (sodass Sie keinen speziellen Code benötigen) und die Probleme mit externen DB-Abhängigkeiten (Synchronisierung von DB und Dateisystem usw.) vermeiden, aber nur diesen Overhead wenn Sie sich explizit dieser Tabelle anschließen (oder einen separaten Aufruf tätigen). 10 MB sind nicht sonderlich groß, die meisten modernen kommerziellen Datenbanken haben kein Problem. Der einzige Grund, warum ich eine Datei im Dateisystem speichern würde, ist die Reduzierung der Datenbankbandbreite. Wenn Ihre Datenbank viele dieser Dateien mischen wird, müssen Sie möglicherweise die Arbeitslast aufteilen und nur eine Art Dateideskriptor speichern. Dann können Sie einen separaten Aufruf haben, um die Datei von einem anderen Server zu laden,

TMN
quelle
4

Sie könnten auf einige dieser Probleme stoßen:

  • Das Ausführen einer SELECT *Zeile mit dem großen Blob dauert sehr lange, auch wenn Sie den Blob nicht benötigen.
  • Das Erstellen eines Backups kann viel länger dauern. Abhängig von Ihren Anforderungen müssen Sie möglicherweise Ihre Tabellen für die Zeit der Sicherung sperren, sodass Sie möglicherweise die Sicherungszeit niedrig halten möchten
  • Das Wiederherstellen wird auch viel mehr Zeit in Anspruch nehmen.
  • Wenn Ihnen der Speicherplatz ausgeht, müssen Sie sich eine Möglichkeit überlegen (möglicherweise die gesamte Datenbank auf einen neuen Server verschieben), um dieses Problem zu lösen. Wenn Sie die Dateien im Dateisystem speichern, können Sie jederzeit eine andere Festplatte einbinden und Softlinks einrichten.
  • Das einfache Durchsuchen einer Datei zum Debuggen oder anderer Informationen ist nicht so einfach. Dies schließt auch Skripte ein, die möglicherweise keinen Zugriff auf die Datenbank haben, jedoch Informationen aus verschiedenen Dateien benötigen.

Natürlich erhalten Sie auch einige Vorteile:

  • Sichern von Daten und Datei-Menüs, die synchron sind
  • Das Entfernen der Datei ohne Kenntnis der Datenbank ist nicht möglich
  • Sie müssen die Datei nicht von der Festplatte lesen, sondern können sie in einer SQL-Anweisung ausführen
  • Sie können die Datenbank herunterladen, den Speicherauszug in Ihre Entwicklungsumgebung aufnehmen und alle Abhängigkeiten direkt dort haben

Persönlich mache ich das nicht, da ich die Nachteile viel schwerer finde als die Vorteile. Aber wie oben erwähnt, hängt es ganz von Ihrem Anwendungsfall und so ab.

Sgoettschkes
quelle
1

Einige Enterpirse Content Management-Systeme wie SiteCore verwenden eine Datenbank zum Speichern von Seitendaten und eine andere Datenbank zum Speichern von Dateien. Sie verwenden MS SQL Server.

šljaker
quelle
Wie beantwortet dies die gestellte Frage?
gnat
Wenn Sie ein bisschen recherchieren, werden Sie feststellen, dass SiteCore eines der beliebtesten Enterprise-Content-Management-Systeme ist. SiteCore unterstützt eine große Anzahl von gleichzeitigen Benutzern und lässt sich recht gut skalieren. Ja, das Speichern von Dateien in einer separaten Datenbank ist keine schlechte Praxis, wenn Sie es richtig machen.
Sljaker
1

Für die praktische Umsetzung können Sie Folgendes in Betracht ziehen:

Vorteile:

  1. Alle Dateiinhalte sind definitiv mit Ihrer Tabelle synchronisiert. Wie bereits erwähnt, ist das Sichern von Daten äußerst praktisch, da Sie die Daten nicht mit dem Dateisystem synchronisieren müssen.
  2. Durch das Codieren können Sie Dateiinhalte direkt aus einer SQL-Auswahl abrufen.
  3. Aus einer Abfrage heraus können Sie sogar Dateiinhalte oder deren Größe explizit aus der SQL-Anweisung herausfiltern.

Nachteile:

  1. Im Vergleich zu einer Datenbank, deren Struktur semantisch identisch ist, die jedoch keinen Dateiinhalt speichert, verbraucht Ihre Datenbank beim Abfragen in der Regel erheblich mehr Speicher.
  2. Auto-Backup kann Leistungsprobleme verursachen, aber nicht viel. Stellen wir uns vor, Ihr Datenbankserver sichert alle 6 Stunden Daten und die Datenbanken, die Sie haben, speichern 10 MB Dateien pro Datensatz. Dieses Szenario ist nicht das, was Sie wollen.
PataoEngineer Tao
quelle