Strategia obsługi bazy danych SQL Server zawierającej zbyt wiele plików (BLOB)?

Scenariusz:
baza danych SQL Server 2005 obsługująca aplikację ASP.NET (na osobnych serwerach WWW).

Baza danych:
DB zawiera około 5 GB „normalnych” danych i około 15 GB „plików” (np. 200 tys. Plików PDF zapisanych jako obraz (BLOB), tego typu rzeczy). Więcej plików jest przesyłanych przez użytkowników i szybko zużywają więcej miejsca na dysku (DB może wzrosnąć do 50 GB w ciągu najbliższych kilku miesięcy, głównie plików).

Obawy:
Przechowywanie tak wielu plików w bazie danych już powoduje problemy (np .: duży całkowity rozmiar bazy danych utrudnia sporadyczne tworzenie kopii zapasowych i wdrażanie całej bazy danych).

Obawiamy się, że będzie więcej problemów . (np .: problemy z wydajnością - być może spowodowane niemożnością utrzymania całego DB w pamięci RAM?)

Pytanie:
Jakie techniczne rozwiązanie zaproponowałbyś dla tego problemu? Czy przechowywać pliki w systemie plików? Podziel bazę danych na dwie części i masz większą, wolniejszą dla plików?

Dalsze szczegóły, jeśli są potrzebne:
Te pliki nie są bardzo ważne i nie potrzebują bardzo krótkich czasów dostępu - wystarczy kilka sekund, a obecnie może być ich kilkanaście. Inne „normalne” dane w bazie danych zawierają informacje potrzebne wiele razy na sekundę.

Opiekuję się bardzo podobną bazą danych, obecnie 3 TB i rosnącą 5 GB dziennie.

• Filestream (2008+) nie rozwiązuje problemu z kopią zapasową / przywracaniem.
• Filestream działa lepiej niż pamięć LOB dla plików> 1 MB, tak twierdzi test Paula Randala . Jest zależny od obciążenia przy 256 KB-1 MB i ogólnie gorzej przy <256 KB.
• Dużym plusem Filestream w niektórych środowiskach jest to, że omija pulę buforów i zamiast tego używa pamięci podręcznej systemu Windows.
• Jeśli umieścisz pliki w systemie plików, stracisz zgodność transakcyjną z rekordem bazy danych. Dodałeś także narzut związany z tworzeniem kopii zapasowych milionów pojedynczych plików, co może być kłopotliwe.

Zważ argumenty za i przeciw dla Filestream i sprawdź, czy to pasuje do twojego przypadku. W naszym przypadku wybraliśmy inną trasę i zdecydowaliśmy się na partycjonowanie bazy danych, abyśmy mogli skorzystać z częściowej dostępności / częściowego przywracania .

Jedną z opcji, która nie była dla nas dostępna, może być oznaczenie starszych / archiwizowanych grup plików jako tylko do odczytu. Grupy plików tylko do odczytu można następnie rzadko tworzyć kopie zapasowe.

Jeśli utknąłeś w 2005 Standard (partycjonowanie jest funkcją edycji Enterprise) i masz opcję tylko do odczytu dla historii, możesz rozwiązać ten staroświecki sposób.

• Podziel swój stół. Możesz rozważyć trasę aktywną / historyczną lub datę, np. Tabelę miesięcznie.
• Umieść dane historyczne w grupie plików tylko do odczytu i wykonaj kopię zapasową tylko podczas archiwizacji dalszych danych. Upewnij się, że użytkownicy rozumieją, że skraca to tylko czas tworzenia kopii zapasowej. Przywracanie może trochę potrwać, jeśli nie masz funkcji częściowej dostępności.
• Utwórz podzielony na partycje widok na tabele.

Ostatnią opcją (którą rozważamy w przypadku naszego blobbera 3 TB) jest przeniesienie danych pliku do bazy danych dokumentów lub magazynu w chmurze (np. AmazonS3 , Azure BLOB Storage ). Wprowadza to problem spójności transakcyjnej, o którym wspomniałem wcześniej, ale odciąża te bardzo drogie serwery SQL.

wypróbuj funkcję FILESTREAM na serwerze SQL,

FILESTREAM integruje aparat bazy danych SQL Server z systemem plików NTFS, przechowując dane varbinary (max) binarnych dużych obiektów (BLOB) jako pliki w systemie plików

fajne artykuły na ten temat

1. Wprowadzenie do SQL Server FileStream
2. Do BLOB lub nie do BLOB: Przechowywanie dużych obiektów w bazie danych lub systemie plików
3. FILESTREAM Storage w SQL Server 2008