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ę.
Odpowiedzi:
Opiekuję się bardzo podobną bazą danych, obecnie 3 TB i rosnącą 5 GB dziennie.
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.
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.
źródło
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
źródło