Przechowuj zdjęcia profilów użytkowników na dysku lub w bazie danych?

Question

Buduję aplikację mvc asp.net, w której użytkownicy mogą dołączać obraz do swojego profilu, ale także w innych obszarach systemu, takich jak gadżet przesyłania wiadomości na pulpicie, który wyświetla najnowsze wiadomości itp.

Gdy użytkownik przesyła je zastanawiam się, czy lepiej byłoby przechowywać je w bazie danych lub na dysku.

databse zalety

• łatwe do tworzenia kopii zapasowych całej bazy danych i zachować zawartość profil/obrazy z powiązanych tabel profil/użytkownika

• kiedy zbudować usług internetowych później w dół toru, mogą po prostu wyciągnij wszystkie dane związane z profiile z jednego miejsca (bazy danych)

Systemu plików zalety

• wczytywania plików z dysku jest prawdopodobnie szybciej

• jakieś inne zalety?

Gdzie inne witryny przechowują tego rodzaju informacje. Czy mam rację, troszcząc się nieco o wydajność bazy danych dla czegoś takiego?

Być może istnieje sposób buforowania obrazów wyciągniętych z bazy danych przez pewien okres czasu?

Alternatywnie, co z pomysłem przechowywania tych obrazów w bazie danych, ale kopiowaniem ich na dysk tak, aby serwer WWW mógł je tam załadować? Wydaje się, że zapewnia to zarówno tworzenie kopii zapasowej, jak i wygodę Db, przy jednoczesnym zapewnieniu przewagi szybkości plików na dysku.

infrastruktura

• Witryna zostanie wdrożony do IIS na serwerze Windows 2003 uruchomionym systemie plików NTFS.
• Baza będzie SQL Server 2008

Podsumowanie

Reading wokół na wiele pokrewnych wątków tutaj na SO, wiele osób jest teraz trendy w kierunku typu SQL Server FILESTREAM. Jednak z tego, co mogłem zebrać (może się mylę), nie ma wiele korzyści, gdy pliki są dość małe. Jednak program Filestreaming znacznie poprawia wydajność, gdy pliki mają wiele MB lub więcej.

Ponieważ moje zdjęcia profilowe mają zazwyczaj około ~ 5kb, postanowiłem po prostu zostawić je w magazynie plików w bazie danych jako varbinary (max).

W środowisku ASP.NET MVC widziałem problem z wydajnością zwracający FileContentResults dla obrazów wyciągniętych z bazy danych w ten sposób. Więc zakończyłem buforowanie pliku na dysku, gdy zostanie odczytany, jeśli lokalizacja tego pliku nie zostanie znaleziona w mojej pamięci podręcznej aplikacji.

Sądzę, że wybrałem hybrydę;

• przechowywanie bazy danych, aby pieczenia zapasowych danych łatwiejszych i pliki związane są bezpośrednio do profili
• Cień kopiowanie na dysk, aby umożliwić lepsze buforowania

W dowolnym momencie można usunąć folder pamięci podręcznej na dysku , a ponieważ obrazy są ponownie zgłaszane, zostaną one ponownie skopiowane przy pierwszym trafieniu i dostarczone z tamtejszej skrzynki.

Answer 1

W rzeczywistości dane magazynu danych można wyszukiwać w bazie danych może być rzeczywiście szybciej w zależności od liczby obrazów, które masz, chyba że używasz wysoce zoptymalizowany silnik systemu plików. Bazy danych są zaprojektowane do szybkiego wyszukiwania i używają dużo ciekawszych technik niż system plików.

reiserfs (przestarzały) naprawdę rewelacyjny dla wyszukiwań, zfs, xfs i NTFS mają fantastyczne algorytmy mieszania, linux ext4 również wygląda obiecująco.

Hity w systemie nie będą się różnić pod względem odczytywania bloków. Pytanie brzmi, co jest szybszym wyszukiwaniem zapytania, które zwraca nazwę pliku (może być hash?), Z którego z kolei uzyskuje się dostęp za pomocą oddzielnego otwartego, pliku close pliku? lub po prostu wyrzucasz kropelkę?

Jest kilka rzeczy do rozważenia, w tym trafienie w sieci, przetwarzanie trafienia, dystrybucja itp. Jeśli przechowujesz dane w bazie danych, możesz je przenieść. Z drugiej strony, jeśli przechowujesz obrazy w usłudze dostarczania treści, która może być WAY szybsza, ponieważ nie robisz żadnych trafień w sieci na yrouself.

Pomyśl o tym i pamiętam trochę benchmarkingu nigdy nikogo skrzywdzić :-) więc przetestować go z typowej wielkości zbioru danych i uwzględniać takie rzeczy jak jednoczesnych zapytań itp

Answer 2

Przechowuj Odniesienia do plików na bazę danych i przechowuje pliki na dysku.

Takie podejście jest bardziej elastyczne i łatwiejsze do skalowania.

Możesz mieć jedną bazę danych i kilka serwerów obsługujących zawartość statyczną. O wiele trudniej będzie mieć kilka baz danych wykonujących tę pracę.

Flickr działa w ten sposób.

Mam nadzieję, że to pomaga.