it-swarm.dev

Czy lepiej jest przechowywać obrazy w BLOB-ie czy tylko w adresie URL?

Możliwy duplikat:
Pliki - w bazie danych czy nie?

Zastanawiałem się, czy jest jakiś dobry powód, aby nadal używać pól obiektów blob w bazie danych. Kilka lat temu pracowałem z DB z kilkoma obrazami, DB było bardzo wolne i nie widziałem żadnego dobrego powodu, aby przechowywać obrazy w DB, więc wyjąłem obrazy i zapisałem nazwy plików zamiast.

Czy to był sprytny ruch? Co byś zrobił na moim miejscu?

38
eiefai

Jak można stwierdzić na podstawie innych odpowiedzi, jest to duże „To zależy”. Niektóre inne czynniki mogą występować, jeśli płacisz za hosting, czy pobierają więcej opłat za przechowywanie plików lub bazy danych. Przechowywanie plików jest zwykle tańsze, szczególnie w przypadku usług w chmurze.

Jeśli jesteś hostem samoobsługowym i używasz programu SQL Server, nadchodząca wersja o nazwie kodowej Denali będzie przedłużyć FILESTREAM , aby umożliwić dostęp zarówno przez TSQL, jak i system plików. Zapewni to również synchronizację. Możesz uzyskać dostęp, aktualizować, usuwać z każdej strony, a wszystko to uporządkuje.

Przeprowadź badania i dowiedz się, co jest dla Ciebie ważne, i wybierz kierunek na podstawie tego wyboru.

Powodem korzystania z BLOB jest po prostu łatwość zarządzania - masz dokładnie jedną metodę, aby wykonać kopię zapasową i przywrócić bazę danych, możesz łatwo tworzyć przyrostowe kopie zapasowe, nie ma ryzyka, że ​​obraz i jego metadane przechowywane w tabelach DB kiedykolwiek się zsynchronizują , masz również jeden interfejs programowania do uruchamiania zapytań lub ładowania/zapisywania obrazów, więc nie musisz zapewniać dostępu do systemu plików klientom zdalnym i wiesz, że te same GRANT będą miały zastosowanie do obrazów i powiązanych z nimi danych. Dodatkowo masz jedną metodę zarządzania pamięcią masową (np. W Oracle możesz umieścić wszystko w ASM i używać Oracle jako swojej LVM do wszystkiego).

Inną aplikacją jest mieszanie danych relacyjnych z serializowanymi obiektami (BLOB może być dowolnym plikiem binarnym, nie musi to być obraz). Lub możesz uruchomić zapytanie względem danych relacji i bajtów x-y w BLOB, który może być na przykład nagłówkiem pliku. Aplikacje są w rzeczywistości nieograniczone.

Jeśli dostęp do BLOB był wolniejszy niż dostęp do systemu plików, istnieje duże prawdopodobieństwo, że baza danych została źle skonfigurowana.

17
Gaius

Nie używam obiektów blob - głównie z perspektywy tworzenia kopii zapasowych i przywracania, ponieważ nie chcę, aby dane obiektów blob spowalniały tworzenie kopii zapasowych.

Jednak nie przechowuję pełnego adresu URL ... Przechowuję ścieżkę pliku poniżej określonego punktu i buduję ścieżkę, ponieważ mam więcej niż jeden sposób, w jaki ludzie i programy uzyskują dostęp do moich plików (FTP, HTTP, katalog lokalny, Katalogi montowane przez NFS).

... oczywiście mam do czynienia z większymi i większymi obrazami niż większość ludzi ... jeden z moich zestawów danych otrzymuje około 700 GB zdjęć (skompresowanych) dziennie. Ale nawet miniatury tych zdjęć wciąż przechowuję na zewnątrz.

13
Joe

Jestem wielkim fanem przechowywania „referencyjnej” kopii obrazu w bazie danych - z punktu widzenia zarządzania/odzyskiwania po awarii jest to naprawdę sposób na latanie.

Teraz możesz nadal robić wiele rzeczy, aby wyświetlać obraz poza systemem plików dla większości aplikacji, więc nie wywierasz tak dużej presji na sam serwer bazy danych, aby robił rzeczy, których tak naprawdę nie chce.

8
Wyatt Barnett

Jeśli pracujesz z Linuksem, przechowywanie obrazów w systemie plików, a nie w bazie danych, ma znacznie lepszą wydajność, patrz ten fragment książki Brada Edigera Advanced Rails .

8
j.p.

Nie jestem fanem przechowywania obrazów w bazie danych. W małej aplikacji z kilkoma użytkownikami wydaje się to łatwym rozwiązaniem, ale wraz z rozpoczęciem skalowania utrudnia to działanie.

Preferuję przechowywanie obrazów w folderze na serwerze internetowym, ale utrzymywanie ścieżki w łatwo dostępnej konfiguracji, aby w razie potrzeby móc szybko przenieść je na ich własny, zoptymalizowany serwer obrazów. Później może chciałbym przenieść je gdzie indziej (pomyśl S3 lub Akamai) w ten sam sposób. Wszystko to jest o wiele bardziej skomplikowane, jeśli muszę zmienić kod, który spodziewał się odczytać je z bazy danych.

5
phred

Czy to był sprytny ruch?

Jeśli był to sprytny ruch, czy nie, zależy to od konkretnego przypadku:

Jeśli lokalizacja pliku ma bezpośredni wpływ na dowolną strukturę adresu URL lub jeśli przechowujesz pełne adresy plików w bazie danych (złe), mogę powiedzieć, że był to zły ruch, ponieważ będziesz miał problemy w przypadku, gdy ktoś przeniesie lub zmieni nazwę katalogu.

Ale tak jak Ale jeśli twoja aplikacja jest zbudowana w taki sposób, że musisz po prostu wskazać katalog plików, a logika dostępu do plików jest dynamiczna, wykonałeś sprytny ruch z następujących powodów:

  • Dzięki przechowywaniu bazy danych, jeśli trzeba obsłużyć wiele obrazów na żądanie, zwiększysz czas odpowiedzi aplikacji, ponieważ pliki będą wysyłane synchronicznie do sieci. Ponadto dodasz trochę więcej przetwarzania do swojego serwera.

  • Przechowywanie plików jest zwykle tańsze niż przechowywanie bazy danych.

  • W przypadku przechowywania plików (chyba że istnieją ograniczenia w dostępie do obrazów: tylko określony użytkownik może uzyskać dostęp do danej grupy obrazów), nie ma potrzeby przetwarzania w celu uzyskania dostępu do obrazów lub innego rodzaju plików.

  • W przypadku przechowywania danych nie można uzyskać dostępu do plików za pomocą FTP (dość oczywiste, ale warto pamiętać).

  • Przechowywanie plików bazy danych spowolni i/lub zaśmieci okresowe kopie zapasowe bazy danych.

Co byś zrobił na moim miejscu?

Zatrzymałbym tę decyzję, chyba że pojawi się przeciwny czynnik dominujący.

Mam nadzieję, że to pomaga.

4
marcio