To Do or Not To Do: przechowuj obrazy w bazie danych [duplikat]

Plusy umieszczania obrazów w bazie danych.

1. Transakcje. Kiedy zapisujesz obiekt blob, możesz go zatwierdzić tak jak każdy inny fragment danych bazy danych. Oznacza to, że możesz zatwierdzić obiekt blob wraz z dowolnymi powiązanymi metadanymi i mieć pewność, że są one zsynchronizowane. Jeśli zabraknie miejsca na dysku? Bez zobowiązań. Plik nie został przesłany w całości? Bez zobowiązań. Głupi błąd aplikacji? Bez zobowiązań. Jeśli zachowanie spójności obrazów i powiązanych z nimi metadanych jest dla Ciebie ważne aplikacji, a następnie transakcje, które może dostarczyć DB, mogą być dobrodziejstwem.

2. Jeden system do zarządzania. Potrzebujesz wykonać kopię zapasową metadanych i blobów? Zrób kopię zapasową bazy danych. Trzeba je replikować? Replikuj bazę danych. Potrzebujesz odzyskać dane po częściowej awarii systemu? Przeładuj DB i przewróć dzienniki do przodu. Wszystkie zalety, które DBs wnoszą do danych w ogóle (mapowanie woluminów, Kontrola pamięci masowej, kopie zapasowe, replikacja, odzyskiwanie itp.) aplikuj na swoje plamy. Większa spójność, łatwiejsze zarządzanie.

3. Ochrona. Bazy danych mają bardzo drobnoziarniste funkcje bezpieczeństwa, które można wykorzystać. Schematy, role użytkowników, nawet takie rzeczy jak "widoki tylko do odczytu", aby zapewnić bezpieczny dostęp do podzbioru danych. Wszystkie te funkcje działają również ze stołami z blobami.

4. Scentralizowane zarządzanie. Związane z #2, ale w zasadzie DBAs (jakby nie mieli wystarczającej mocy) mogą zarządzać jedną rzeczą: bazą danych. Nowoczesne bazy danych (szczególnie te większe) działają bardzo dobrze z dużymi instalacjami na kilku maszynach. Jedno źródło zarządzania upraszcza procedury, upraszcza transfer wiedzy.

5. Większość nowoczesnych baz danych dobrze radzi sobie z blobami. Dzięki pierwszorzędnej obsłudze obiektów blob w warstwie danych możesz łatwo przesyłać strumieniowo obiekty BLOB z bazy danych do klienta. Chociaż istnieją operacje, które możesz wykonać, które "wciągną" całą blob na raz, jeśli nie potrzebujesz tego obiektu, nie używaj go. Zbadaj interfejs SQL dla DB i dźwigni jego funkcje. Nie ma powodu, aby traktować je jak" wielkie struny", które są traktowane monolitycznie i zamieniać swoje plamy w wielkie, pożerające pamięć, rozbijające pamięć podręczną bomby.

6. Podobnie jak można skonfigurować dedykowane serwery plików dla obrazów, można skonfigurować dedykowane serwery blob w bazie danych. Daj im dedykowane woluminy dysków, dedykowane Schematy, dedykowane pamięci podręczne itp. Wszystkie Twoje dane w DB nie są takie same lub zachowują się tak samo, nie ma powodu, aby je skonfigurować tak samo. Dobre bazy danych mają dobry poziom kontroli.

Podstawowa nit dotycząca serwowania blob z DB jest zapewnienie, że warstwa HTTP faktycznie wykorzystuje cały protokół HTTP do wykonania usługi.

Wiele naiwnych implementacji po prostu chwyta Bloba i zrzuca je hurtowo do gniazda. Ale HTTP ma kilka ważnych funkcji dobrze nadaje się do strumieniowania obrazów, itp. W szczególności buforowanie nagłówków, Etagów i transferu chunked, aby umożliwić klientom żądanie "kawałków" z blob.

Upewnij się, że usługa HTTP prawidłowo honoruje wszystkie te żądania, a Twój DB może być bardzo dobrym obywatelem sieci. Buforując pliki w systemie plików do serwowania przez serwer HTTP, zyskujesz niektóre z tych zalet "za darmo" (ponieważ dobry serwer i tak zrobi to dla" statycznych " zasobów), ale upewnij się, że jeśli to zrobisz, że honorujesz takie rzeczy, jak daty modyfikacji itp. do zdjęć.

Na przykład ktoś żąda spaceshuttle.jpg, obraz stworzony 1 stycznia, 2009. To kończy się w pamięci podręcznej w systemie plików w dniu żądania, powiedzmy, 1 lutego 2009. Później obraz jest czyszczony z pamięci podręcznej (Polityka FIFO, czy cokolwiek), a ktoś, później, 1 marca 2009, prosi o to ponownie. Cóż, teraz ma Mar 1, 2009 "Data utworzenia", mimo że cały czas jego Data utworzenia była naprawdę Jan 1. Widać więc, że zwłaszcza jeśli pamięć podręczna często się zmienia, klienci, którzy mogą używać nagłówków If-Modified, mogą uzyskać więcej danych, niż faktycznie potrzebują, ponieważ serwer myśli, że zasób się zmienił, podczas gdy w rzeczywistości nie.

Jeśli data utworzenia pamięci podręcznej jest zsynchronizowana z rzeczywistą datą utworzenia, może to być mniejszy problem.

Ale chodzi o to, że trzeba przemyśleć cały problem, aby być "dobrym obywatelem sieci" i zaoszczędzić Tobie i Twoim klientom potencjalnie trochę przepustowości itp.

Właśnie przejrzałem to wszystko dla projektu Java obsługującego filmy z DB i wszystko działa jak należy.

Rozumiem, że większość specjalistów od baz danych będzie trzymać kciuki i syczeć na Ciebie, jeśli przechowujesz obrazy w bazie danych (lub nawet o tym wspomnieć). Tak, korzystanie z bazy danych jako repozytorium dużych bloków danych binarnych dowolnego rodzaju ma zdecydowanie wpływ na wydajność i pamięć (obrazy są najczęściej spotykanymi bitami danych, których nie można znormalizować). Istnieją jednak z pewnością okoliczności, w których przechowywanie obrazów w bazie danych jest nie tylko dozwolone, ale .

Na przykład, w mojej starej pracy mieliśmy aplikację, w której użytkownicy dołączali obrazy do kilku różnych punktów raportu, które pisali, i te obrazy musiały być wydrukowane, gdy to było zrobione. Raporty te zostały przeniesione za pomocą replikacji SQL Server, a próba zarządzania tymi obrazami i ścieżkami plików w wielu systemach i serwerach z dowolną niezawodnością spowodowałaby ogromny ból głowy. Przechowywanie ich w bazie danych dało nam wszystkie to "za darmo", a narzędzie do raportowania nie musiało wychodzić do systemu plików, aby odzyskać obraz.

Moją ogólną radą byłoby, aby nie ograniczać się do jednego lub drugiego podejścia - idź z techniką, która pasuje do sytuacji. Systemy plików są bardzo dobre w przechowywaniu plików, a bazy danych są bardzo dobre w dostarczaniu kawałków wielkości bite danych na żądanie. Z drugiej strony, jeden z produktów mojej firmy ma wymóg przechowywania całego stanu aplikacji w bazie danych, co oznacza, że załączniki plików również tam trafiają. Z naszym serwerem DB (SQL Server 2005) jeszcze nie uruchomiłem do obserwowalnych problemów z wydajnością nawet w przypadku dużych klientów i baz danych.

Microsoft SQL 2008 daje najlepsze z obu światów z funkcją FileStream-może warto sprawdzić. http://technet.microsoft.com/en-us/library/bb933993.aspx

Jedną z zalet przechowywania obrazów w bazie danych jest to, że są one przenośne w różnych systemach i niezależne od układu systemu plików.

Najprostszym / najbardziej wydajnym / najbardziej skalowalnym rozwiązaniem jest przechowywanie obrazów w systemie plików. Jeśli chodzi o bezpieczeństwo, umieść je w miejscu niedostępnym dla serwera sieci Web i napisz skrypt, który zajmuje się bezpieczeństwem i serwuje pliki.

Zakładając, że twój serwer web/app i serwer DB są różnymi maszynami, wykonasz kilka trafień, umieszczając obrazy w DB: (1) opóźnienie sieci między dwoma maszynami, (2) napowietrzne połączenie DB, (3) zużywanie dodatkowego Połączenie DB dla każdego obsługiwanego obrazu. Byłbym bardziej zaniepokojony ostatnim punktem: jeśli Twoja strona obsługuje wiele obrazów, twoje serwery internetowe będą zużywać wiele połączeń DB i mogą wyczerpać Twoje pule połączeń.

Jeśli Twoja aplikacja działa na wielu serwerach, przechowywałbym referencyjną kopię twoich obrazów w bazie danych, a następnie buforowałbym je na żądanie na systemach plików. Robienie tego jest o wiele mniej podatnym na błędy bólem w dupie niż próba synchronizacji systemów plików z boku.

Jeśli Twoja aplikacja jest na jednym serwerze, to tak, trzymaj się systemu plików i niech baza danych utrzyma ścieżkę do danych.

Większość baz danych SQL nie jest oczywiście zaprojektowana z myślą o serwowaniu obrazów, ale istnieje pewna wygoda związana z ich umieszczaniem w bazie danych.

Na przykład, jeśli masz już uruchomioną bazę danych i skonfigurowaną replikację. Od razu masz magazyn obrazów HA zamiast próbować replikacji systemu plików opartych na rsync lub nfs. Ponadto posiadanie kilku procesów internetowych (lub projektowanie jakiejś nowej usługi) do zapisu plików na dysk zwiększa złożoność trochę. To tylko bardziej ruchome części.

Przynajmniej zalecałbym przechowywanie danych meta o obrazie (takich jak uprawnienia, kto jest jego właścicielem, itp.) i rzeczywistych danych rozdzielonych na różne tabele, aby można było dość łatwo przełączyć się do innego magazynu danych w dół linii. To w połączeniu z jakimś rodzajem CDN lub buforowania powinno dać całkiem dobrą wydajność do pewnego punktu, więc przypuszczam, że zależy to od tego, jak skalowalna ta aplikacja musi być i jak ty zrównoważyć to z łatwością wdrożenia.

Nie musisz przechowywać adresu URL (jeśli uważasz, że jest to niebezpieczne). Możesz po prostu zapisać unikalny identyfikator, który odwołuje się do obrazu w innym miejscu.

Przechowywanie danych jest zwykle droższe i kosztowne w utrzymaniu niż system plików - dlatego nie przechowywałbym wielu obrazów w bazie danych.

Odzyskiwanie po awarii nie jest zabawne, gdy masz terabajty danych obrazu przechowywanych w bazie danych. Lepiej znaleźć lepszy sposób dystrybucji danych, aby były bardziej niezawodne itp... Oczywiście wszystkie napowietrzne (wymienione powyżej) są mnożone podczas replikacji i tak dalej...

Po prostu nie rób tego!

To naprawdę wygląda na pocałunek (keep it simple stupid) problem. Systemy plików są łatwe do obsługi przechowywania plików graficznych, ale nie jest to łatwe do zrobienia w bazie danych i łatwe do bałagan danych. Po co brać hit wydajności i wszystkie trudności w sql i renderowania, kiedy można po prostu martwić się o bezpieczeństwo plików? Możesz również obsługiwać systemy mieszane z NFS lub CIFS. Systemy plików to Dojrzałe technologie. Znacznie prostsze, bardziej wytrzymałe.

Zapisałem obrazy w bazie danych dla aplikacji demonstracyjnej. Powodem, dla którego to zrobiłem, było bezpieczeństwo - usunięcie rekordu, którego nie powinienem był, nie było dużym problemem, ale usunięcie pliku, którego nie powinienem był, mogło być problemem!

Gdyby wydajność stała się problemem, zbadałbym, czy nieuczciwe usuwanie plików jest realną możliwością, czy nie.

Jeśli są to obrazy, które są regularnie wyciągane z bazy danych, zawsze starałbym się użyć systemu plików.

Gdyby były to obrazki, które trzeba od czasu do czasu wyciągać, a zapisywanie ich w bazie ułatwia życie, to nie mam z tym żadnego problemu.

• Baza Danych
• system plików dla plików