Dokumente als Blobs in einer Datenbank speichern - Irgendwelche Nachteile?

Question

Die Anforderungen für meine Dokumente-Management-System waren:

1. muss vor Diebstahl durch einfaches Kopieren von Verzeichnissen sicher sein, Dateien usw.
2. muss gegen traditionelle Virusinfektion (Infektion der physischen Datei) sicher
3. muss schnell sein muss abrufen
4. Das Repository nicht zu lässig (Verzeichnis) Surfen Benutzer sichtbar sein usw.

ich beschlossen haben, stor Alle Dokumente (und eingescannte Bilder) als Blobs in der Datenbank und bisher ist meine Erfahrung wunderbar und die Dokumentensuche ist blendend schnell - es erfüllt alle oben genannten Kriterien und es gibt sogar noch ein paar zusätzliche Vorteile, wie zum Beispiel Dokumente automatisch zu speichern zusammen mit der Entität, auf die es sich bezieht, leichtes und schnelles Suchen von Inhalten, Entfernen aller Arten von Benutzeraktivitäten rund um das Öffnen und Nennen von Dokumenten etc. etc.

Meine Frage ist - gibt es irgendwelche ernsten Risiken oder Dinge, die ich übersehen habe mit diesem Design und Implementierung?

EDIT Hinweis: DB ist PostgreSQL, behandelt BLOBS sehr gut und skaliert außergewöhnlich gut. Die Umgebung ist Multi-User.

Answer 1

Wenn Ihre Datenbank größer und größer wird, wird es schwieriger zu sichern. Das Wiederherstellen einer Sicherung einer Tabelle mit mehr als 100 GB Daten macht Sie nicht glücklich.

Eine andere Sache, die erhalten wird, ist, dass alle Tabellenverwaltungsfunktionen immer langsamer werden, während das Dataset wächst.
Aber das kann überwunden werden, indem Sie Ihre Datentabelle nur 2 Felder enthalten: ID und BLOB.

Das Abrufen von Daten (über den Primärschlüssel) wird wahrscheinlich erst dann zu einem Problem, wenn Sie die Datensicherung mit einer Sicherung abgeschlossen haben.

Answer 2

Diese article deckt die meisten Probleme ab. Wenn Sie SQL Server 2008 verwenden, überprüfen Sie die Verwendung des neuen FILESTREAM-Typs, wie von Paul Randal here beschrieben.

Answer 3

Der Hauptnachteil, den ich häufig über die Verwendung von Blobs höre, ist, dass das Dateisystem ab einer bestimmten Größe beim Speichern und Abrufen großer Dateien wesentlich effizienter ist. Es hört sich so an, als hätten Sie dies bereits in der Liste der Anforderungen berücksichtigt.

Es gibt eine good reference (PDF) here, die die Vor- und Nachteile von Blobs behandelt.

Answer 4

Entschuldigung - die Antwort, die ich anbot, basierte auf SQL Server, daher ist der Wartungsabschnitt nicht geeignet. Die Datei-E/A wird jedoch auf Hardware-Ebene ausgeführt, und jede Datenbank fügt zusätzliche Verarbeitungsschritte hinzu.

Die Datenbank verursacht zusätzlichen Aufwand beim Abrufen des Dokuments. Wenn sich die Datei auf der Festplatte befindet, sind Sie nur so langsam oder so schnell wie die E/A auf dem Server. Sie sollten sicherlich Ihre Meta in einer Datenbank verwalten, aber am Ende wollen Sie die UNC der Datei und zeigen Sie den Benutzer die Quelle und aus dem Weg.

Aus Sicht der Wartung und Administration beschränken Sie sich im Umgang mit MS SQL Server auf ein SAN. Lösungen wie Documentum verfolgen einen anderen Ansatz mit einfachem Speicher auf der Festplatte und ermöglichen Ihnen die Implementierung einer Speicherlösung, wie Sie es für richtig halten.

EDIT

Lassen Sie mich meine Aussage klären - mit SQL Server Sie nur begrenzte Möglichkeiten haben, wenn Sie die physische Speicherkapazität des Behälters nicht überschreiten. Dies ist in der Tat eine der großen Schwächen von Sharepoint, dass Sie nicht einfach jede Art von Netzwerkspeicher anhängen können.

Answer 5

Es hängt vom Datenbanktyp ab. Oracle oder SQL Server? Beachten Sie einen Nachteil - Wiederherstellung eines einzelnen Dokuments.

Answer 6

Aus meiner Erfahrung einige Probleme waren:

1. Geschwindigkeit vs Dateien auf dem Dateisystem.

2. Caching. IMO der Web-Server wird einen besseren Job der Zwischenspeicherung statischen Inhalten. Die DB wird eine gute Arbeit zu tun, aber wenn die DB auch Übergabe aller Arten von anderen Abfragen, nicht erwarten, dass diese großen Dokumente für lange im Cache bleiben. Sie müssen im Wesentlichen die Dateien zweimal übertragen. Einmal von der DB zum Webserver und dann zum Webserver Client.

3. Speicherbeschränkungen. Bei meinem letzten Job hatten wir eine 40MB PDF in der Datenbank und bekamen immer Java OutOfMemoryErrors in der Logdatei. Wir haben schließlich festgestellt, dass die gesamte 80MB-Datei nicht nur einmal in den Heapspeicher eingelesen wurde, sondern ZWEIMAL dank einer Einstellung in Hibernate ORM (wenn ein Objekt veränderbar ist, erstellt es eine Kopie zur Bearbeitung im Speicher). Sobald die PDF-Datei zurück an den Benutzer gestreamt wurde, wurde der Heap aufgeräumt, aber es war ein großer Erfolg, 80 MB gleichzeitig aus dem Heap zu saugen, nur um ein Dokument zu streamen. Kenne deinen Code und wie Speicher verwendet wird!

Ihr Web-Server sollte in der Lage sein, die meisten Ihrer Sicherheitsprobleme zu handhaben, aber wenn Dokumente klein sind und die DB nicht bereits unter einer großen Last, dann ich nicht wirklich ein großes Problem sehe mit mit sie in der DB.

Answer 7

Ich habe gerade angefangen, SQL Server 2008 FILESTREAMing für BLOBs zu erforschen und sind über eine riesige Einschränkung (IMO) gelaufen - es funktioniert nur mit integrierter Sicherheit. Wenn Sie die Windows-Authentifizierung nicht zum Herstellen einer Verbindung zum DB-Server verwenden, können Sie die BLOBs nicht lesen/schreiben. Viele Anwendungsumgebungen können die Windows-Authentifizierung nicht verwenden. Sicher nicht in heterogenen Umgebungen.

Eine bessere Lösung zum Speichern von BLOBs muss vorhanden sein. Was sind die besten Praktiken?

Answer 8

Von dem, was ich erfahren habe Speichern von Inhaltsdateien als Blobs, in SQL Server und Oracle, funktioniert OK mit einer kleinen Datenbank und mit einer geringen Anzahl von angemeldeten Benutzern. ECM-System trennen sie und verwenden separate Dienste für das Streaming von Inhalten. Abhängig von der Größe der Dateien können die Serverressourcen durch das gleichzeitige Abrufen großer Dateien beeinträchtigt werden. Das Archivieren von Datenbanken mit großen Dateigruppen wird aufgrund der Wiederherstellungszeit und der Unfähigkeit, Dokumente vom Archiv abzurufen, problematisch.

Wenn es sich bei diesen Dateien um Unternehmensdatensätze handelt und dies die autorisierende Kopie der Datensätze ist, haben Sie möglicherweise Compliance- und Aufbewahrungsmanagementprobleme, insbesondere wenn Sie die Dateien archivieren. Auch die Suche und die Versionskontrolle können zu einem großen Problem werden, das voran geht.

Vielleicht möchten Sie ein ECM-System mit einer bestimmten API untersuchen, anstatt das Rad neu zu erfinden.