Udostępnianie obrazów z serwera SQL vs. system plików vs. S3 itp

Moja aplikacja (klasyczne asp yay!) Ma około 2,1 miliona obrazów @ 25 GB, a to tylko 90 dni danych i chciałbym przejść na minimum 365. Muszę je kontrolować i rozważam wszystkie opcje. Co sądzisz o zaletach i wadach następujących praktyk:

• Zalety programu SQL Server: łatwe tworzenie kopii zapasowych Wady: wydajność?
• Zalety systemu plików: Szybkość Wady: Redundancja, tworzenie kopii zapasowych jest powolne (obecnie badam tworzenie syntetycznych pełnych kopii zapasowych, które mogłyby to poprawić)
• S3 i podobne Zalety: Przepustowość została przeniesiona z mojego centrum danych do Amazon, praktycznie nieograniczona przestrzeń dyskowa. Minusy: koszt, analiza kosztów jest trudna (szacowanie 80% mojej przepustowości to obrazy do celów zwrotu z inwestycji), trudne / kosztowne dla dostawców usług, jeśli to konieczne

Czy ktoś jeszcze poradził sobie z wyzwaniem dotyczącym wielu milionów obrazów i jak sobie z tym poradziłeś?

Nie mamy milionów obrazów, ale mamy setki tysięcy, i stosujemy podejście hybrydowe - mysql dla metadanych, obrazy przechowywane na lokalnym dysku do tworzenia kopii zapasowych i przesyłane do Amazon s3, gdzie są podawane użytkownikom. Nie mieliśmy problemów z Amazonem i dostępnością. Przeprowadzka do chmury jest w naszych planach, wystarczy znaleźć czas.

Ta dyskusja może być pomocna w podejmowaniu decyzji:
http://ask.metafilter.com/59635/Millions-of-images

Poszedłbym z metadanymi na serwerze SQL i plikami w systemie plików (lub s3 lub cloudfront). Ale najlepsza odpowiedź zależy od niektórych innych wzorców użytkowania:

• czy obrazy często się zmieniają
• czy możesz podawać obrazy bezpośrednio z systemu plików (to znaczy img src="..."), czy potrzebujesz ich do kontroli dostępu. Jeśli to drugie, to rozwiązanie bazy danych jest najlepsze
• czy przez większość czasu wyświetlasz niewielką liczbę zdjęć (ostatnie 10%), czy też dystrybucja jest stosunkowo powszechna?

Tworzenie kopii zapasowych milionów zdjęć będzie skomplikowane bez względu na to, jak je uporządkujesz - to tylko dużo danych. Chciałbym znaleźć dobre studium przypadku dotyczące tworzenia kopii zapasowych obiektów blob na serwerze SQL, zanim zdecydowałem się na to rozwiązanie. (Oto artykuł, który może się przydać: http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part-4.htm )

Jeśli zdecydujesz się na przechowywanie ich w systemie plików, możesz przeczytać o tym pytaniu ServerFault w przypadku niektórych czynności, a nie: Przechowywanie miliona obrazów w systemie plików .

Zignoruj ​​osoby, które mówią: „ Nie przechowuj obrazów / danych binarnych w bazie danych ”, ponieważ opierają swoje odpowiedzi na starych informacjach (zakładając, że będziesz przechowywać dane w kolumnie typu VarBinary). Wydajność związana z używaniem programu SQL Server do przechowywania obrazów można teraz ograniczyć, stosując typ danych FILESTREAM w programie SQL Server 2008. Zasadniczo typ danych FILESTREAM umożliwia połączenie łatwości przechowywania danych w bazie danych z wydajnością uzyskiwaną dzięki udostępnianiu pliki ze składnicy plików NTFS.

Aby zacytować SQL Mag :

„Nowa obsługa FILESTREAM w SQL Server 2008 łączy zalety uzyskiwania dostępu do obiektów LOB bezpośrednio z systemu plików NTFS z integralnością referencyjną i łatwością dostępu oferowaną przez silnik relacyjnej bazy danych SQL Server”.

Aby uzyskać więcej informacji, przeczytaj ten blog autorstwa Ravi S.Maniam w witrynie MSDN .

Chociaż nie radzę sobie z wyzwaniem związanym z wieloma milionami obrazów, użyłbym Amazon CloudFront. Wszystkie pliki są przechowywane w segmencie S3, ale są serwerami za pośrednictwem systemu dostarczania treści Amazon. Nie użyłbym S3 sam.

Moim drugim wyborem byłby system plików. Prosty i łatwy, jedynym problemem jest to, że jeśli wszystkie te pliki znajdą się w jednym katalogu, wszystko się zawiesi, mocno.

Dla mnie SQL nie byłby opcją dla takiego systemu. Nie tylko naliczane są opłaty za transfer przepustowości, ale także opłaty za przetwarzanie zapytania - będzie to bardzo zależało od hostingu, ale zakładam, że korzystasz z dedykowanego serwera lub przynajmniej vps, gdzie zostaniesz obciążony na cykle. Spowolni wtedy całą witrynę, jeśli używa tej samej bazy danych, co serwer obrazów. Jeśli nie, to dodajesz całą tę złożoność konieczności zarządzania dwoma połączeniami z bazą danych.

Bazy danych są zaprojektowane pod kątem danych transakcyjnych / spójności i bezpieczeństwa.

Pliki multimedialne (obrazy, audio, wideo) są zwykle tworzone i być może usuwane, ale bardzo rzadko aktualizowane. Ogólnie rzecz biorąc, nie ma potrzeby utrzymywania ich transakcyjnie spójnych z innymi danymi, a baza danych nie przyniesie tam żadnej realnej korzyści. Treść tekstowa może być inną sprawą.

Tak długo, jak nie masz problemu z koncepcją ciągnięcia pliku bezpośrednio przez kogoś, kto ma adres URL pliku, system plików jest w porządku. Jeśli prowadziłeś coś w rodzaju biblioteki zdjęć, w której spodziewasz się naładować przed pobraniem pliku, prawdopodobnie jest to inna sprawa. Oznacza to, że gdy użytkownik zapłaci, może otrzymać adres URL specyficzny dla tego użytkownika lub ważny tylko przez krótki czas, a aplikacja obsługuje wiele lub tymczasowe adresy URL wskazujące na ten sam obraz. Może to nadal być obsługiwane przez aplikację i system plików, ale w końcu serwujesz media za pośrednictwem aplikacji, a nie jako zwykłe pobieranie plików (co w większości wykluczałoby jakiekolwiek zalety S3) i istnieje mniejsza różnica między DB a systemem plików .