Strategie zum Umgang mit einer SQL Server-Datenbank mit zu vielen Dateien (BLOBs)?

Szenario:
SQL Server 2005-Datenbank, die eine ASP.NET-Anwendung (auf einem separaten Webserver) bedient.

Datenbank: Die Datenbank
enthält ungefähr 5 GB "normale" Daten und ungefähr 15 GB "Dateien" (z. B. ein als Bild gespeichertes 200-KB-PDF (BLOB), so etwas). Weitere Dateien werden von Benutzern hochgeladen und verbrauchen schnell mehr Speicherplatz (die Datenbank könnte in den nächsten Monaten auf 50 GB anwachsen, hauptsächlich Dateien).

Bedenken: Das
Speichern so vieler Dateien in der Datenbank verursacht bereits Probleme (z. B.: Die große Gesamtgröße der Datenbank erschwert gelegentliche Sicherungen und Bereitstellungen der gesamten Datenbank.).

Und wir befürchten, dass es weitere Probleme geben wird . (zB: Leistungsprobleme - möglicherweise dadurch verursacht, dass nicht die gesamte Datenbank im RAM gehalten werden kann?)

Frage:
Welche technische Lösung würden Sie für dieses Problem vorschlagen? Dateien im Dateisystem speichern? Teilen Sie die Datenbank in zwei Teile und haben Sie eine größere, langsamere für Dateien?

Weitere Details, falls erforderlich:
Diese Dateien sind nicht besonders wichtig und benötigen keine sehr schnellen Zugriffszeiten. Ein paar Sekunden wären in Ordnung, und derzeit gibt es möglicherweise höchstens ein Dutzend Auswahlen pro Stunde. Die anderen "normalen" Daten in der Datenbank enthalten Informationen, die mehrmals pro Sekunde benötigt werden.

Ich kümmere mich um eine sehr ähnliche Datenbank, derzeit 3 ​​TB und 5 GB pro Tag.

• Filestream (2008+) löst die Herausforderung zum Sichern / Wiederherstellen nicht.
• Filestream bietet eine bessere Leistung als LOB-Speicher für Dateien> 1 MB, so Paul Randals Tests . Es ist arbeitslastabhängig bei 256 KB-1 MB und im Allgemeinen schlechter bei <256 KB.
• Ein großes Plus für Filestream in einigen Umgebungen ist, dass es den Pufferpool umgeht und stattdessen den Windows-Systemcache verwendet.
• Wenn Sie die Dateien in einem Dateisystem ablegen, verlieren Sie die Transaktionskonsistenz mit dem Datenbankdatensatz. Sie haben auch den Aufwand für das Sichern von Millionen einzelner Dateien hinzugefügt, was problematisch sein kann.

Wägen Sie die Vor- und Nachteile von Filestream ab und prüfen Sie, ob es in Ihren Fall passt. In unserem Fall haben wir einen anderen Weg eingeschlagen und uns für die Partitionierung der Datenbank entschieden, damit wir die teilweise Verfügbarkeit / stückweise Wiederherstellung nutzen können .

Eine Option, die uns möglicherweise nicht zur Verfügung stand, besteht darin, ältere / archivierte Dateigruppen als schreibgeschützt zu markieren. Die schreibgeschützten Dateigruppen können dann selten gesichert werden.

Wenn Sie sich an 2005 Standard halten (Partitionierung ist eine Enterprise Edition-Funktion) und die Option haben, für den Verlauf schreibgeschützt zu sein, können Sie dies auf die altmodische Weise angehen.

• Teilen Sie Ihren Tisch. Sie können die aktive / historische Route oder das Datum berücksichtigen, z. B. Tabelle pro Monat.
• Legen Sie die historischen Daten in einer schreibgeschützten Dateigruppe ab und sichern Sie sie nur, wenn Sie weitere Daten archivieren. Stellen Sie sicher, dass Ihre Benutzer verstehen, dass dies nur die Sicherungszeit verkürzt. Die Wiederherstellung kann eine Weile dauern, wenn Sie nicht über die Teilverfügbarkeitsfunktion verfügen.
• Erstellen Sie eine partitionierte Ansicht über die Tabellen.

Eine letzte Option (die wir für unseren 3-TB-Blobber in Betracht ziehen) besteht darin, die Dateidaten in eine Dokumentendatenbank oder einen Cloud-Speicher (z. B. AmazonS3 , Azure BLOB-Speicher ) zu verschieben. Dies führt zwar zu dem zuvor erwähnten Problem der Transaktionskonsistenz, entlastet jedoch diese sehr teuren SQL Server.

Probieren Sie die FILESTREAM- Funktion in SQL Server aus.

FILESTREAM integriert das SQL Server-Datenbankmodul in ein NTFS-Dateisystem, indem varbinary (max) BLOB-Daten (Binary Large Object) als Dateien im Dateisystem gespeichert werden

schöne Artikel darüber

1. Eine Einführung in SQL Server FileStream
2. Zu BLOB oder nicht zu BLOB: Großer Objektspeicher in einer Datenbank oder einem Dateisystem
3. FILESTREAM-Speicher in SQL Server 2008