Ich verwende also eine App, die Bilder stark in der Datenbank speichert. Wie sehen Sie das? Ich bin eher ein Typ, um den Speicherort im Dateisystem zu speichern, als ihn direkt in der Datenbank zu speichern.
Was denkst du sind die Vor- / Nachteile?
Antworten:
Ich bin verantwortlich für einige Anwendungen, die viele TB Bilder verwalten. Wir haben festgestellt, dass das Speichern von Dateipfaden in der Datenbank am besten ist.
Es gibt einige Probleme:
Wie bei den meisten Problemen ist es nicht so einfach, wie es sich anhört. Es gibt Fälle, in denen es sinnvoll wäre, die Bilder in der Datenbank zu speichern.
Andererseits sind Probleme damit verbunden
Dateispeicher. Facebook-Ingenieure hatten ein tolles Gespräch darüber. Ein Vorteil war, die praktische Grenze der Dateien in einem Verzeichnis zu kennen.
Nadel im Heuhaufen: Effiziente Speicherung von Milliarden von Fotos
Dies mag etwas langwierig sein, aber wenn Sie SQL Server 2008 verwenden (oder planen), würde ich empfehlen, einen Blick auf den neuen FileStream- Datentyp zu werfen .
FileStream löst die meisten Probleme beim Speichern der Dateien in der Datenbank:
Die "Transparente Datenverschlüsselung" von SQL verschlüsselt jedoch keine FileStream-Objekte. Wenn dies in Betracht gezogen wird, ist es möglicherweise besser, sie nur als varbinary zu speichern.
Aus dem MSDN-Artikel:
Transact-SQL-Anweisungen können FILESTREAM-Daten einfügen, aktualisieren, abfragen, suchen und sichern. Win32-Dateisystemschnittstellen bieten Streaming-Zugriff auf die Daten.
FILESTREAM verwendet den NT-Systemcache zum Zwischenspeichern von Dateidaten. Dies hilft, die Auswirkungen von FILESTREAM-Daten auf die Leistung des Datenbankmoduls zu verringern. Der SQL Server-Pufferpool wird nicht verwendet. Daher steht dieser Speicher für die Abfrageverarbeitung zur Verfügung.
Dateipfade in der Datenbank sind definitiv der richtige Weg - ich habe Geschichte für Geschichte von Kunden mit TB an Bildern gehört, dass es ein Albtraum wurde, eine signifikante Anzahl von Bildern in einer Datenbank zu speichern - der Leistungseinbruch allein ist zu groß.
Nach meiner Erfahrung besteht die einfachste Lösung manchmal darin, die Bilder nach dem Primärschlüssel zu benennen . So ist es einfach, das Bild zu finden, das zu einem bestimmten Datensatz gehört, und umgekehrt. Gleichzeitig speichern Sie jedoch nichts über das Bild in der Datenbank.
Der Trick dabei ist, kein Eiferer zu werden.
Hierbei ist zu beachten, dass niemand im Pro-Dateisystem-Camp ein bestimmtes Dateisystem aufgelistet hat. Bedeutet dies, dass alles von FAT16 bis ZFS jede Datenbank handlich übertrifft?
Nein.
Die Wahrheit ist, dass viele Datenbanken viele Dateisysteme schlagen, selbst wenn es nur um rohe Geschwindigkeit geht.
Die richtige Vorgehensweise besteht darin, die richtige Entscheidung für Ihr genaues Szenario zu treffen. Dazu benötigen Sie einige Zahlen und einige Schätzungen für Anwendungsfälle.
An Orten, an denen Sie die referenzielle Integrität und ACID-Konformität gewährleisten MÜSSEN, ist das Speichern von Bildern in der Datenbank erforderlich.
Sie können nicht transaktional garantieren, dass das Bild und die Metadaten zu diesem in der Datenbank gespeicherten Bild auf dieselbe Datei verweisen. Mit anderen Worten, es kann nicht garantiert werden, dass die Datei im Dateisystem immer nur zur gleichen Zeit und in derselben Transaktion wie die Metadaten geändert wird.
Wie bereits erwähnt, enthält SQL 2008 einen Dateistream-Typ, mit dem Sie einen Dateinamen oder eine Kennung als Zeiger in der Datenbank speichern und das Image automatisch in Ihrem Dateisystem speichern können. Dies ist ein großartiges Szenario.
Wenn Sie sich in einer älteren Datenbank befinden, würde ich sagen, wenn Sie diese als Blob-Daten speichern, werden Sie bei der Suche nach Funktionen wirklich nichts aus der Datenbank herausholen. Daher ist es wahrscheinlich am besten um eine Adresse in einem Dateisystem zu speichern und das Bild auf diese Weise zu speichern.
Auf diese Weise sparen Sie auch Speicherplatz in Ihrem Dateisystem, da Sie nur die genaue Menge an Speicherplatz oder sogar komprimierten Speicherplatz im Dateisystem sparen.
Sie können sich auch dafür entscheiden, mit einigen Strukturen oder Elementen zu speichern, mit denen Sie die Rohbilder in Ihrem Dateisystem ohne DB-Treffer durchsuchen oder die Dateien in großen Mengen auf ein anderes System, eine Festplatte, S3 oder ein anderes Szenario übertragen können - indem Sie den Speicherort in aktualisieren Ihr Programm, aber behalten Sie die Struktur, auch ohne großen Erfolg, wenn Sie versuchen, die Bilder aus Ihrer Datenbank zu entfernen, wenn Sie versuchen, den Speicherplatz zu erhöhen.
Wahrscheinlich können Sie damit auch ein Caching-Element, das auf häufig getroffenen Bild-URLs basiert, in Ihre Web-Engine / Ihr Web-Programm einfügen, sodass Sie sich auch dort sparen.
Kleine statische Bilder (nicht mehr als ein paar Megabyte), die nicht häufig bearbeitet werden, sollten in der Datenbank gespeichert werden. Diese Methode bietet mehrere Vorteile, darunter eine einfachere Portabilität (Bilder werden mit der Datenbank übertragen), eine einfachere Sicherung / Wiederherstellung (Bilder werden mit der Datenbank gesichert) und eine bessere Skalierbarkeit (ein Dateisystemordner mit Tausenden kleiner Miniaturbilddateien klingt nach einem Albtraum der Skalierbarkeit mir).
Das Bereitstellen von Bildern aus einer Datenbank ist einfach. Implementieren Sie einfach einen http-Handler, der das vom DB-Server zurückgegebene Byte-Array als Binärdatenstrom bereitstellt.
Hier ist ein interessantes Whitepaper zum Thema.
Zu BLOB oder nicht zu BLOB: Großer Objektspeicher in einer Datenbank oder einem Dateisystem
Die Antwort lautet "Es kommt darauf an." Sicherlich würde es vom Datenbankserver und seiner Herangehensweise an die Blob-Speicherung abhängen. Dies hängt auch von der Art der Daten ab, die in Blobs gespeichert werden, sowie davon, wie auf diese Daten zugegriffen werden soll.
Kleinere Dateien können mithilfe der Datenbank als Speichermechanismus effizient gespeichert und bereitgestellt werden. Größere Dateien werden wahrscheinlich am besten mit dem Dateisystem gespeichert, insbesondere wenn sie häufig geändert / aktualisiert werden. (Die Blob-Fragmentierung wird zu einem Problem in Bezug auf die Leistung.)
Hier ist ein zusätzlicher Punkt, den Sie beachten sollten. Einer der Gründe für die Verwendung einer Datenbank zum Speichern der Blobs ist die ACID-Konformität. Der Ansatz, den die Tester im Whitepaper (Option "Massenprotokolliert von SQL Server") verwendeten, der den SQL Server-Durchsatz verdoppelte, änderte jedoch effektiv das "D" in ACID in ein "d", da die Blob-Daten nicht protokolliert wurden Die ersten Schreibvorgänge für die Transaktion. Wenn die vollständige ACID-Konformität eine wichtige Voraussetzung für Ihr System ist, halbieren Sie daher die SQL Server-Durchsatzzahlen für Datenbankschreibvorgänge, wenn Sie Datei-E / A mit Datenbank-Blob-E / A vergleichen.
Eine Sache, die ich noch nicht erwähnt habe, die aber definitiv erwähnenswert ist, ist, dass es Probleme gibt, große Mengen von Bildern in den meisten Dateisystemen zu speichern. Wenn Sie beispielsweise den oben genannten Ansatz wählen und jede Bilddatei nach dem Primärschlüssel benennen, treten bei den meisten Dateisystemen Probleme auf, wenn Sie versuchen, alle Bilder in einem großen Verzeichnis abzulegen, sobald Sie eine sehr große Anzahl von Bildern erreicht haben ( zB in den Hunderttausenden oder Millionen).
Eine übliche Lösung besteht darin, sie in einen ausgeglichenen Baum von Unterverzeichnissen zu zerlegen.
Niemand hat erwähnt, dass die DB atomare Aktionen, Transaktionsintegrität und Parallelität garantiert. Selbst die referenzielle Integrität ist bei einem Dateisystem nicht möglich. Woher wissen Sie also, dass Ihre Dateinamen wirklich noch korrekt sind?
Wenn Sie Ihre Bilder in einem Dateisystem haben und jemand die Datei liest, während Sie eine neue Version schreiben oder sogar die Datei löschen - was passiert?
Wir verwenden Blobs, weil sie auch einfacher zu verwalten sind (Backup, Replikation, Übertragung). Sie arbeiten gut für uns.
Das Problem beim Speichern nur von Dateipfaden zu Bildern in einer Datenbank besteht darin, dass die Integrität der Datenbank nicht mehr erzwungen werden kann.
Wenn das tatsächliche Bild, auf das der Dateipfad zeigt, nicht mehr verfügbar ist, weist die Datenbank unabsichtlich einen Integritätsfehler auf.
Angesichts der Tatsache, dass es sich bei den Bildern um die tatsächlich gesuchten Daten handelt und dass sie einfacher in einer integrierten Datenbank verwaltet werden können (die Bilder verschwinden nicht plötzlich), anstatt mit einer Art Dateisystem verbunden zu sein (wenn auf das Dateisystem unabhängig zugegriffen wird), Die Bilder könnten plötzlich "verschwinden". Ich würde sie direkt als BLOB oder so speichern.
In einer Firma, in der ich früher gearbeitet habe, haben wir 155 Millionen Bilder in einer Oracle 8i (damals 9i) Datenbank gespeichert. 7,5 TB wert.
Normalerweise bin ich hartnäckig dagegen, den teuersten und am schwierigsten zu skalierenden Teil Ihrer Infrastruktur (die Datenbank) zu übernehmen und die gesamte Last in sie zu stecken. Auf der anderen Seite: Dies vereinfacht die Sicherungsstrategie erheblich, insbesondere wenn Sie mehrere Webserver haben und die Daten irgendwie synchronisieren müssen.
Wie die meisten anderen Dinge hängt es von der erwarteten Größe und dem Budget ab.
Wir haben ein Dokumentabbildungssystem implementiert, das alle Bilder in SQL2005-Blobfeldern speichert. Derzeit gibt es mehrere hundert GB, und wir sehen hervorragende Reaktionszeiten und geringe oder keine Leistungseinbußen. Darüber hinaus verfügen wir aus Gründen der Einhaltung gesetzlicher Vorschriften über eine Middleware-Schicht, die neu veröffentlichte Dokumente in einem optischen Jukebox-System archiviert, das sie als Standard-NTFS-Dateisystem verfügbar macht.
Wir waren sehr zufrieden mit den Ergebnissen, insbesondere in Bezug auf:
Annahme: Die Anwendung ist webfähig / webbasiert
Ich bin überrascht, dass niemand dies wirklich erwähnt hat ... delegieren Sie es an andere Spezialisten -> verwenden Sie einen Drittanbieter für Bild- / Datei-Hosting .
Speichern Sie Ihre Dateien auf einem kostenpflichtigen Onlinedienst wie
Ein weiterer StackOverflow-Thread spricht hier darüber .
In diesem Thread wird erklärt, warum Sie einen Hosting-Anbieter eines Drittanbieters verwenden sollten.
Es ist es so wert. Sie speichern es effizient. Keine Bandbreite, die von Ihren Servern auf Clientanforderungen usw. hochgeladen wird.
Wenn Sie nicht mit SQL Server 2008 arbeiten und gute Gründe für das Einfügen bestimmter Bilddateien in die Datenbank haben, können Sie den Ansatz "beides" verwenden und das Dateisystem als temporären Cache verwenden und die Datenbank als Master-Repository verwenden .
Beispielsweise kann Ihre Geschäftslogik vor dem Bereitstellen überprüfen, ob eine Image-Datei auf der Disc vorhanden ist, und diese bei Bedarf aus der Datenbank abrufen. Dies bietet Ihnen die Möglichkeit mehrerer Webserver und weniger Synchronisierungsprobleme.
Ich bin mir nicht sicher, wie sehr dies ein Beispiel aus der "realen Welt" ist, aber ich habe derzeit eine Anwendung, die Details für ein Sammelkartenspiel speichert, einschließlich der Bilder für die Karten. Zugegeben, die Anzahl der Datensätze für die Datenbank beträgt derzeit nur 2851 Datensätze. Angesichts der Tatsache, dass bestimmte Karten mehrfach freigegeben wurden und alternative Grafiken haben, war es tatsächlich effizienter, das "primäre Quadrat" der Grafiken und dann dynamisch zu scannen Generieren Sie auf Anfrage den Rand und verschiedene Effekte für die Karte.
Der ursprüngliche Ersteller dieser Bildbibliothek hat eine Datenzugriffsklasse erstellt, die das Bild basierend auf der Anforderung rendert und dies zum Anzeigen und für einzelne Karten recht schnell erledigt.
Dies erleichtert auch die Bereitstellung / Aktualisierung, wenn neue Karten freigegeben werden. Anstatt einen ganzen Ordner mit Bildern zu komprimieren und diese über die Pipe zu senden und sicherzustellen, dass die richtige Ordnerstruktur erstellt wird, aktualisiere ich einfach die Datenbank und lasse den Benutzer sie erneut herunterladen. Diese Größe beträgt derzeit bis zu 56 MB, was nicht besonders gut ist, aber ich arbeite an einer inkrementellen Update-Funktion für zukünftige Versionen. Darüber hinaus gibt es eine "No Images" -Version der Anwendung, mit der Benutzer über Einwahl die Anwendung ohne Verzögerung des Downloads abrufen können.
Diese Lösung hat bisher hervorragend funktioniert, da die Anwendung selbst als einzelne Instanz auf dem Desktop ausgerichtet ist. Es gibt eine Website, auf der alle diese Daten für den Online-Zugriff archiviert werden, aber ich würde in keiner Weise dieselbe Lösung dafür verwenden. Ich bin damit einverstanden, dass der Dateizugriff vorzuziehen ist, da er sich besser an die Häufigkeit und das Volumen der Anfragen an die Bilder anpassen lässt.
Hoffentlich ist das nicht zu viel Geschwätz, aber ich habe das Thema gesehen und wollte einige meiner Erkenntnisse aus einer relativ erfolgreichen kleinen / mittleren Anwendung liefern.
SQL Server 2008 bietet eine Lösung, die das Beste aus beiden Welten bietet: den Datentyp filestream .
Verwalten Sie es wie eine normale Tabelle und nutzen Sie die Leistung des Dateisystems.
Dies hängt von der Anzahl der zu speichernden Bilder und deren Größe ab. Ich habe in der Vergangenheit Datenbanken zum Speichern von Bildern verwendet und meine Erfahrungen waren ziemlich gut.
IMO, Vorteile der Verwendung der Datenbank zum Speichern von Bildern sind,
A. Sie benötigen keine FS-Struktur, um Ihre Bilder
zu speichern
. B. Datenbankindizes weisen eine bessere Leistung als FS-Bäume auf, wenn mehr Elemente gespeichert werden sollen. C. Intelligent abgestimmte Datenbanken leisten gute Arbeit beim Zwischenspeichern der Abfrageergebnisse.
D. Sicherungen sind einfach. Es funktioniert auch gut, wenn Sie die Replikation eingerichtet haben und Inhalte von einem Server in der Nähe des Benutzers bereitgestellt werden. In solchen Fällen ist keine explizite Synchronisation erforderlich.
Wenn Ihre Bilder klein werden (z. B. <64 KB) und die Speicher-Engine Ihrer Datenbank Inline-BLOBs (im Datensatz) unterstützt, wird die Leistung weiter verbessert, da keine Indirektion erforderlich ist (Referenzort wird erreicht).
Das Speichern von Bildern kann eine schlechte Idee sein, wenn Sie mit einer kleinen Anzahl großer Bilder arbeiten. Ein weiteres Problem beim Speichern von Bildern in der Datenbank besteht darin, dass Metadaten wie die Erstellung und Änderungsdaten von Ihrer Anwendung verarbeitet werden müssen.
Ich habe kürzlich eine PHP / MySQL-App erstellt, die PDFs / Word-Dateien in einer MySQL-Tabelle speichert (bis zu 40 MB pro Datei).
Vorteile:
Nachteile:
Ich würde meine Implementierung als Erfolg bezeichnen, sie kümmert sich um die Backup-Anforderungen und vereinfacht das Layout des Projekts. Die Leistung ist gut für die 20-30 Personen, die die App verwenden.
Nach meiner Erfahrung musste ich beide Situationen bewältigen: in der Datenbank gespeicherte Bilder und Bilder im Dateisystem mit in db gespeichertem Pfad.
Die erste Lösung, Bilder in der Datenbank, ist etwas "sauberer", da Ihre Datenzugriffsschicht nur mit Datenbankobjekten arbeiten muss. Dies ist jedoch nur dann gut, wenn Sie mit niedrigen Zahlen umgehen müssen.
Offensichtlich verschlechtert sich die Datenbankzugriffsleistung, wenn Sie mit großen binären Objekten arbeiten, und die Datenbankdimensionen werden stark zunehmen, was wiederum zu Leistungseinbußen führt ... und normalerweise ist der Datenbankspeicher viel teurer als der Dateisystemspeicher.
Wenn Sie jedoch große Binärobjekte im Dateisystem speichern, erhalten Sie Sicherungspläne, die sowohl die Datenbank als auch das Dateisystem berücksichtigen müssen. Dies kann für einige Systeme ein Problem sein.
Ein weiterer Grund für das Dateisystem ist, wenn Sie Ihre Bilddaten (oder Sounds, Videos usw.) für den Zugriff durch Dritte freigeben müssen: In diesen Tagen entwickle ich eine Web-App, die Bilder verwendet, auf die von "außen" zugegriffen werden muss "Meine Webfarm so, dass ein Datenbankzugriff zum Abrufen von Binärdaten einfach unmöglich ist. Manchmal gibt es auch Designüberlegungen, die Sie zu einer Wahl führen.
Berücksichtigen Sie bei dieser Auswahl auch, ob Sie beim Zugriff auf Binärobjekte mit Berechtigungen und Authentifizierung umgehen müssen: Diese Anforderungen können normalerweise einfacher gelöst werden, wenn Daten in db gespeichert werden.
Ich habe einmal an einer Bildverarbeitungsanwendung gearbeitet. Wir haben die hochgeladenen Bilder in einem Verzeichnis gespeichert, das ungefähr / images / [heutiges Datum] / [ID-Nummer] war. Wir haben aber auch die Metadaten (Exif-Daten) aus den Bildern extrahiert und diese zusammen mit einem Zeitstempel und dergleichen in der Datenbank gespeichert.
In einem früheren Projekt habe ich Bilder im Dateisystem gespeichert, und das verursachte viele Kopfschmerzen, da Backups, Replikationen und das Dateisystem nicht mehr mit der Datenbank synchronisiert waren.
In meinem neuesten Projekt speichere ich Bilder in der Datenbank und speichere sie im Dateisystem zwischen, und es funktioniert wirklich gut. Ich hatte bisher keine Probleme.
Zweitens die Empfehlung zu Dateipfaden. Ich habe an einigen Projekten gearbeitet, die für die Verwaltung umfangreicher Asset-Sammlungen erforderlich waren, und alle Versuche, Dinge direkt in der Datenbank zu speichern, führten langfristig zu Schmerzen und Frustrationen.
Der einzige echte "Profi", den ich mir vorstellen kann, um sie in der DB zu speichern, ist das Potenzial für einfache Einzelbild-Assets. Wenn keine zu verwendenden Dateipfade vorhanden sind und alle Bilder direkt aus der Datenbank gestreamt werden, besteht keine Gefahr, dass ein Benutzer Dateien findet, auf die er keinen Zugriff haben sollte.
Dies scheint jedoch besser mit einem Zwischenskript gelöst zu werden, das Daten aus einem über das Internet nicht zugänglichen Dateispeicher abruft. Der DB-Speicher ist also nicht WIRKLICH notwendig.
Das Wort auf der Straße ist, dass es keine sehr gute Idee ist, wenn Sie kein Datenbankanbieter sind, der zu beweisen versucht, dass Ihre Datenbank dies kann (sagen wir, Microsoft rühmt sich, dass Terraserver eine Milliarde Bilder in SQL Server speichert). Wenn die Alternative - Speichern von Bildern auf Dateiservern und Pfaden in der Datenbank - so viel einfacher ist, warum dann? Blob-Felder ähneln den Offroad-Fähigkeiten von SUVs - die meisten Leute nutzen sie nicht, diejenigen, die normalerweise in Schwierigkeiten geraten, und dann gibt es diejenigen, die dies tun, aber nur zum Spaß.
Das Speichern eines Bildes in der Datenbank bedeutet weiterhin, dass die Bilddaten irgendwo im Dateisystem landen, aber verdeckt sind, sodass Sie nicht direkt darauf zugreifen können.
+ ves:
-ves:
Beide Methoden sind üblich und werden praktiziert. Schauen Sie sich die Vor- und Nachteile an. In jedem Fall müssen Sie darüber nachdenken, wie Sie die Nachteile überwinden können. Das Speichern in einer Datenbank bedeutet normalerweise, die Datenbankparameter zu optimieren und eine Art Caching zu implementieren. Für die Verwendung des Dateisystems müssen Sie eine Möglichkeit finden, das Dateisystem + die Datenbank synchron zu halten.