Bilder in der Datenbank vs Dateisystem

Question

Wir haben ein Projekt, bei dem wir ein ganzes Backend -CMS -System bauen werden, das unser gesamtes Extranet und unser Intranet mit einem Paket mit Strom versorgt. Die Frage, auf die ich versucht habe, eine Antwort zu finden, ist besser: Bilder in der Datenbank (SQL Server 2005) zu speichern, damit wir möglicherweise Integrität, Einzelreplikationsplan usw. haben oder auf dem Dateisystem gespeichert werden?

Ein Problem, das wir haben, ist, dass wir mehrere Server ausbalanciert haben, für die jederzeit die gleichen Daten haben. Ab sofort haben wir die SQL -Replikation, die sich um diese kümmert, aber die Dateireplikation scheint etwas schwieriger zu sein. Ein weiteres Anliegen ist, dass wir mehrere Auflösungen desselben Bildes haben möchten. Wir sind uns nicht sicher, ob das Erstellen und Speichern jeder Version auf dem Dateisystem am besten oder möglicherweise dynamisch das Auflösungsbild erstellt und auf Anfrage erstellt wird.

Unsere Bedenken sind die folgenden:

• Datenintegrität
• Datenreplikation
• Mehrere Auflösungen
• Geschwindigkeit der Datenbank vs Dateisystem
• Overhead -Ladung des Datenbank -VS -Dateisystems
• Datenverwaltung und Sicherung

Hat jemand eine ähnliche Situation oder Input zu dem, was empfohlen wird? Vielen Dank im Voraus für die Hilfe!

Answer 1

Es gab eine schöne Forschungsarbeit, die von Microsoft Research mit dem Titel "Microsoft Research" veröffentlicht wurde Zu blättern oder nicht zu blättern wo sie sich alle möglichen Variablen und Auswirkungen ansahen.

Ihre Feststellung am Ende:

• Bis zu 256 kb Größe werden in der Datenbank effizienter gespeichert als im Dateisystem
• Für 1 MB und größer ist das Dateisystem effizienter
• Dazwischen ist es ein Wurf

Seit diesem Papier hat SQL Server 2008 auch das FileStream -Attribut hinzugefügt, das das Speichern von Sachen im Dateisystem macht, jedoch unter der Transaktionskontrolle Realität. Sehr empfohlen, das zu überprüfen!

Answer 2

Diese Frage erscheint oft - siehe Dies Also Suchergebnis.

Es gibt keine richtige Antwort - es hängt von den Umständen ab.

Persönlich - behalten Sie einen Dateipfad im DB und in der Datei im Dateisystem. Jeder hat seine eigenen Stärken. Sie können sowohl Dateien als auch Datenbanken sichern. Dies ist auch die Schlussfolgerung von dieser Typ, wer verwaltet TBs von Daten.

Answer 3

Die Replikation statischer Dateien, insbesondere über eine Reihe von Servern, kann schwierig zu verwalten sein. Es kommt wirklich auf einen Kompromiss zwischen Verwaltung, Überwachung und Debuggen von Replikationsproblemen im Vergleich zur Datenbankgröße und -belastung an.

Ich denke, ich würde wahrscheinlich den Datenbankansatz auswählen, und wenn Last zu einem Problem wurde, um eine Art Cache -Ebene um die Bildaufrufe zu setzen.

Vorschläge zum Speichern eines Pfades im DB fehlen das eigentliche Problem, was dies über mehrere Maschinen hinweg repliziert.

Answer 4

Ihre Bedenken zerbrechen in zwei Lager. Die folgenden Bedenken bevorzugen das Speichern von Dokumenten in der Datenbank:

• Datenintegrität
• Datenreplikation
• Mehrere Auflösungen
• Datenverwaltung und Sicherung

Diese Bedenken bevorzugen (wahrscheinlich) das Speichern von Dokumenten im Dateisystem:

• Geschwindigkeit der Datenbank vs Dateisystem
• Overhead -Ladung des Datenbank -VS -Dateisystems

Entscheiden Sie also, was am wichtigsten ist, und wählen Sie entsprechend.

Answer 5

Nun, wenn Ihre beiden Top -Bedürfnisse Integrität und Replikation sind, dann ist die Antwort definitiv DB.

Sie andere Punkte:

• Integrität - DB, deshalb gibt es Datenbanken im Vergleich zu flachen Dateisystemen.

• Replikation - Ich bin mir nicht sicher, ob Sie Bildreplikation meinen, aber wenn ja, dann ist es sicherlich DB, dass Sie dies nicht laden, dies sicherlich auszugleichen.

• Aus dem DB -Bild können mehrere Auflösungen ausgeführt werden, dies fügt jedoch die Verarbeitungskosten hinzu. Je höher die Auflösung, desto größer ist die Größe, je länger das Netzwerk wartet. Mehrere Auflösungen handeln Platz für Geschwindigkeit.

• Geschwindigkeit - Abhängig vom Zugriff auf die Bilder könnte dies vernachlässigbar sein. Wenn Sie Bilder über eine Dateifreigabe aufnehmen, müssen Sie auf jeden Fall im Netzwerk warten und das Netzwerk ist so ziemlich immer der Engpass.

• Overhead - Ehrlich gesagt hängt es von Ihrer Definition von Overhead und dem Zugriff auf die Bilder ab.

• Management, DB, zweifellos. Singular Storage = eine weniger Sorge, und Sie sollten auf jeden Fall immer Backups in der Datenbank ausführen. Dateisystemsicherungen über mehrere Server sind in vielerlei Hinsicht kostspielig.

Answer 6

Auf beiden Seiten der Debatte gibt es gültige Bedenken, also geben Sie immer Ihre Anforderungen. Wie viel Daten, wie viele Bilder, wie groß?

Inline / Blob -Speicher

Auf den Kopf: vereinfacht Architektur und Implementierung, vereinfacht die Sicherung und Wiederherstellung oder Migration des Systems. Machen Sie einfach eine Müllkippe, Backup, exportieren (unabhängig von dem Begriff für Ihren DB -Geschmack) und bewegen Sie sie in die neue Datenbank. Die Versionskontrolle / Konsistenz wird von der DB behandelt und ermöglicht daher die Erholung der Punkte in der Zeit. Die Sicherheits- / Zugriffskontrolle ist auch sauberer, da der Zugriff auf einen Bildblob für den Zugriff auf die Gesamtreihe intrinsisch ist. Wenn Sie das Bild außerhalb der DB bewegen und den HTTP -Server aufnehmen lassen, können Sie jedoch Probleme mit der Sicherstellung haben, dass Personen keine URLs hacken und Bilder anfordern können, die sie nicht besitzen. Wenn Sie sie außerhalb der DB unterbringen, stellen Sie sicher, dass Ihre Sicherheitsrichtlinie die Zugriffskontrolle für Bilder zwischen Benutzern abdeckt. Entweder muss Ihre HTTP -Server -Authentifizierung in die Authentifizierung des Gesamtsystems integrieren, oder Ihr HTTP -Serverprogramm, mit dem die Bilder dienen, verwendet einen Sitzungsmechanismus, um sicherzustellen, dass die HTTP -Anforderung gültig ist. Dies ist ein sehr großes Anliegen in Multi-Mieter-Datenbanken. Weniger Anlass zur Sorge in Einzelzwecken, Single-Mieter-Systemen, mit einfacher Authentifizierung.

Nachteil: Für wirklich große Datenbanken werden die Backup und die Wiederherstellung frustrierend oder sogar problematisch und kostspielig, da Sie möglicherweise einen kleinen Kerndatensatz haben, sonst haben Sie möglicherweise viele GB oder TB Bilddaten. Die Behandlung von alles als eine konsistente Datenbank ist aus Integritätssicht gut, aber schlecht für Backups, es sei denn, Sie verwenden DBMSES mit Unternehmensqualität, Data Warehouse Tuned Backup und Recovery (Beispiel ist Oracle Rman und Rolling Backups).

Betrachten Sie immer Zeit für die Wiederherstellung in jedem System. Wenn Ihre Speicheranforderungen <ein paar Gigabyte sind, sagen wir sogar 50-100 GB, und Sie haben eine ausreichende Sicherungsfläche geplant, ist der Inline-Speicher sauberer. Darüber hinaus wird die Trennung von Bedenken und das Erleben des Dateisystems seinen Job zu einem zentralen Vorteil. Nichts ist schlimmer, als zu versuchen, eine riesige Datenbank wiederherzustellen, wiederherzustellen und zu öffnen, um einen kleinen Datenfehler zu machen. Die Erholungszeit wäre mein größtes Anliegen.

Answer 7

Im Allgemeinen sind anhaltende Bilddaten in der DB möglicherweise nicht so effizient wie das Dateisystem, was ein CMS betrifft. Zu einer Zeit möchten Sie wahrscheinlich nur das Bild statisch anzeigen. Zu anderen Zeiten möchten Sie, dass das Bild Ihren Grafikdesigern für Updates usw. verfügbar ist.

Betrachten Sie den Verarbeitungsaufwand, der mit dem Abrufen des Bildes jedes Mal, wenn Sie damit arbeiten möchten, zugeordnet.

Ein paar Punkte, warum Sie das Dateisystem berücksichtigen sollten

1. Der Browser erledigt die ganze Arbeit und die Sie profitieren vom Stellvertreter von Bildern usw.
2. Als Ableger des oben genannten können Sie problemlos Content Delivery Networks (CDN) verwenden
3. Die Replikation von Bilddaten ist bei Tools wie RSYNC usw. einfach
4. Verarbeitungszeit (IE CPU) ist drastisch optimiert

Answer 8

Angenommen, Sie befinden sich in einer Windows -Umgebung, gibt es keinen guten Grund, das Dateisystem zu verwenden. Möglicherweise möchten Sie vorsichtig sein, wie Sie die Bilder in den Tischen speichern, um unerwünschte Seitenaufenthalte zu vermeiden, aber das ist ein Leistungsverbot, kein großes Problem.

Nachteile zum Dateisystem

-NOT automatisch repliziert

-Möglicherweise erschweren Sie Ihre Replikation, indem Sie für jede Instanz unterschiedliche physische Standorte haben

-Slow mit einer sehr großen Anzahl von Dateien

Auf dem Kopf zum Dateisystem

-Wenn Sie ein paar sehr große Dateien speichern, wird es etwas besser abschneiden.

Answer 9

Ich würde;

1) Zuweisen Sie jedem Bild eindeutig (GUID).

Das Speichern von Bildern in der Datenbank ist in Bezug auf Speicher und Wartung zu teuer. Das Speichern nur der FQN -Zeiger würde eine bessere Lösung bieten. Sie können auch Back-End-Integritätsprüfung durch Trigger und einige gespeicherte Verfahren erstellen.

Answer 10

Ich würde Bilder aus einem Grund nicht in der Datenbank speichern (meine Antwort kommt von SQL Server):

Ich möchte nicht, dass SQL -Server -Datencache, die von einfachen Bildern für die Website besiedelt wurden. Ich möchte, dass der Datencache tatsächlich Daten enthält. Auch wenn Sie eine mehrstufige Architektur haben, ist es viel einfacher, eine URL für ein Bild zu übergeben als einen Blob binärer Daten. Wo Sie jedoch auf Probleme stoßen, wenn Sie nur bestimmte Personen die Bilder sehen möchten (Sicherheit).