Więc używam aplikacji, która mocno przechowuje obrazy w DB. Jakie masz na to poglądy? Jestem raczej typem do przechowywania lokalizacji w systemie plików, niż do przechowywania bezpośrednio w bazie danych.
Jak myślisz, jakie są zalety / wady?
Odpowiedzi:
Jestem odpowiedzialny za niektóre aplikacje, które zarządzają wieloma TB zdjęć. Odkryliśmy, że przechowywanie ścieżek plików w bazie danych jest najlepsze.
Istnieje kilka problemów:
Jak w przypadku większości problemów, nie jest to tak proste, jak się wydaje. Są przypadki, w których sensowne byłoby przechowywanie obrazów w bazie danych.
Z drugiej strony występują problemy
Magazyn plików Inżynierowie z Facebooka świetnie o tym rozmawiali. Jednym z nich było poznanie praktycznego limitu plików w katalogu.
To może być trochę długa szansa, ale jeśli używasz (lub planujesz użyć) SQL Server 2008, polecam przyjrzeć się nowemu typowi danych FileStream .
FileStream rozwiązuje większość problemów związanych z przechowywaniem plików w bazie danych:
Jednak „przezroczyste szyfrowanie danych” w języku SQL nie szyfruje obiektów FileStream, więc jeśli jest to rozważane, lepiej jest przechowywać je jako varbinary.
Z artykułu MSDN:
Instrukcje Transact-SQL mogą wstawiać, aktualizować, wyszukiwać, wyszukiwać i tworzyć kopie zapasowe danych FILESTREAM. Interfejsy systemu plików Win32 zapewniają strumieniowy dostęp do danych.
FILESTREAM używa pamięci podręcznej systemu NT do buforowania danych pliku. Pomaga to zredukować wpływ danych FILESTREAM na wydajność aparatu bazy danych. Pula buforów SQL Server nie jest używana; dlatego ta pamięć jest dostępna do przetwarzania zapytań.
Ścieżki do plików w DB to zdecydowanie najlepsza droga - słyszałem historię po historii od klientów z TB obrazów, że stało się koszmarem próbującym przechowywać dowolną znaczną liczbę obrazów w DB - sama wydajność jest zbyt duża.
Z mojego doświadczenia wynika, że czasami najprostszym rozwiązaniem jest nazywanie obrazów zgodnie z kluczem podstawowym . Łatwo jest więc znaleźć obraz należący do określonego rekordu i odwrotnie. Ale jednocześnie nie przechowujesz nic na temat obrazu w bazie danych.
Sztuka polega na tym, aby nie zostać fanatykiem.
Należy tutaj zauważyć, że nikt w obozie pro file system nie wymienił konkretnego systemu plików. Czy to oznacza, że wszystko, od FAT16 po ZFS, łatwo pokonuje każdą bazę danych?
Nie.
Prawda jest taka, że wiele baz danych pokonuje wiele systemów plików, nawet jeśli mówimy tylko o surowej prędkości.
Prawidłowym działaniem jest podjęcie właściwej decyzji dla konkretnego scenariusza, a do tego potrzebne będą pewne liczby i szacunkowe przypadki użycia.
W miejscach, w których MUSISZ zagwarantować spójność referencyjną i zgodność z ACID, wymagane jest przechowywanie obrazów w bazie danych.
Nie można zagwarantować transakcyjnie, że obraz i metadane dotyczące tego obrazu przechowywane w bazie danych odnoszą się do tego samego pliku. Innymi słowy, nie można zagwarantować, że plik w systemie plików zostanie zmieniony tylko w tym samym czasie i w tej samej transakcji, co metadane.
Jak inni powiedzieli, SQL 2008 jest wyposażony w typ Filestream, który pozwala przechowywać nazwę pliku lub identyfikator jako wskaźnik w db i automatycznie zapisuje obraz w systemie plików, co jest świetnym scenariuszem.
Jeśli korzystasz ze starszej bazy danych, powiedziałbym, że jeśli przechowujesz ją jako dane obiektów blob, to tak naprawdę nie zamierzasz niczego wyciągać z bazy danych w celu wyszukiwania funkcji, więc prawdopodobnie jest to najlepsze do przechowywania adresu w systemie plików i przechowywania obrazu w ten sposób.
W ten sposób oszczędzasz również miejsce w systemie plików, ponieważ zaoszczędzisz tylko dokładną ilość miejsca, a nawet kompaktowe miejsce w systemie plików.
Możesz także zdecydować się na zapisywanie z pewną strukturą lub elementami, które pozwalają przeglądać nieprzetworzone obrazy w systemie plików bez żadnych trafień bazy danych lub przenieść pliki zbiorczo do innego systemu, dysku twardego, S3 lub innego scenariusza - aktualizując lokalizację w twój program, ale zachowaj strukturę, znowu bez większego trafienia, próbując wyciągnąć obrazy z bazy danych podczas próby zwiększenia pamięci.
Prawdopodobnie pozwoliłoby to również na wrzucenie elementu buforującego, opartego na często trafianych adresach URL obrazu do twojego silnika / programu internetowego, więc też tam się oszczędzasz.
Małe obrazy statyczne (nie więcej niż kilka megapikseli), które nie są często edytowane, powinny być przechowywane w bazie danych. Ta metoda ma kilka zalet, w tym łatwiejsze przenoszenie (obrazy są przesyłane z bazą danych), łatwiejsze tworzenie kopii zapasowych / przywracanie (kopie zapasowe zdjęć z bazą danych) oraz lepszą skalowalność (folder systemu plików z tysiącami małych plików miniatur brzmi jak koszmar skalowalności mnie).
Podawanie obrazów z bazy danych jest łatwe, wystarczy zaimplementować moduł obsługi http, który obsługuje tablicę bajtów zwróconą z serwera DB jako strumień binarny.
Oto ciekawa biała księga na ten temat.
Do BLOB lub nie do BLOB: Przechowywanie dużych obiektów w bazie danych lub systemie plików
Odpowiedź brzmi: „To zależy”. Z pewnością zależałoby to od serwera bazy danych i jego podejścia do przechowywania obiektów blob. Zależy to również od rodzaju danych przechowywanych w obiektach blob, a także od sposobu dostępu do tych danych.
Pliki o mniejszych rozmiarach mogą być skutecznie przechowywane i dostarczane przy użyciu bazy danych jako mechanizmu przechowywania. Większe pliki byłyby prawdopodobnie najlepiej przechowywane w systemie plików, zwłaszcza jeśli będą często modyfikowane / aktualizowane. (fragmentacja obiektów blob staje się problemem w odniesieniu do wydajności).
Oto dodatkowy punkt, o którym należy pamiętać. Jednym z powodów poparcia użycia bazy danych do przechowywania obiektów blob jest zgodność z ACID. Jednak podejście zastosowane przez testerów w białej księdze (opcja Bulk Logged SQL Server), które podwoiło przepustowość SQL Servera, skutecznie zmieniło „D” w ACID na „d”, ponieważ dane obiektu blob nie zostały zarejestrowane za pomocą wstępne zapisy dla transakcji. Dlatego też, jeśli pełna zgodność ACID jest ważnym wymaganiem dla twojego systemu, zmniejsz o połowę wydajność SQL Server dla operacji zapisu w bazie danych podczas porównywania I / O pliku z I / O obiektu blob bazy danych.
Jedną z rzeczy, o których nikt jeszcze nie wspominał, ale na pewno warto zauważyć, są problemy związane z przechowywaniem dużych ilości obrazów w większości systemów plików. Na przykład, jeśli zastosujesz podejście wspomniane powyżej i nadasz nazwę każdemu plikowi obrazu po kluczu podstawowym, w większości systemów plików wystąpią problemy, jeśli spróbujesz umieścić wszystkie obrazy w jednym dużym katalogu po osiągnięciu bardzo dużej liczby obrazów ( np. w setkach tysięcy lub milionach).
Raz powszechnym rozwiązaniem tego problemu jest umieszczenie ich w zbalansowanym drzewie podkatalogów.
Nikt nie wspomniał, że DB gwarantuje działania atomowe, integralność transakcyjną i zajmuje się współbieżnością. Nawet integralność referencyjna jest poza oknem w systemie plików - więc skąd wiesz, że twoje nazwy plików są nadal prawidłowe?
Jeśli masz swoje obrazy w systemie plików i ktoś czyta plik podczas pisania nowej wersji lub nawet usuwania pliku - co się stanie?
Używamy obiektów blob, ponieważ są również łatwiejsze do zarządzania (tworzenie kopii zapasowych, replikacja, przesyłanie). Pracują dla nas dobrze.
Problem z przechowywaniem tylko ścieżek plików do obrazów w bazie danych polega na tym, że nie można już wymuszać integralności bazy danych.
Jeśli rzeczywisty obraz wskazywany przez ścieżkę pliku stanie się niedostępny, baza danych nieświadomie ma błąd integralności.
Biorąc pod uwagę, że obrazy są rzeczywistymi poszukiwanymi danymi i że można nimi łatwiej zarządzać (obrazy nie znikną nagle) w jednej zintegrowanej bazie danych, zamiast konieczności łączenia się z jakimś systemem plików (jeśli dostęp do systemu plików jest niezależny, obrazy MOGĄ nagle „zniknąć”), wybrałbym przechowywanie ich bezpośrednio jako BLOBa lub coś w tym rodzaju.
W firmie, w której kiedyś pracowałem, w bazie danych Oracle 8i (wówczas 9i) zapisaliśmy 155 milionów obrazów. Wartość 7,5 TB
Zwykle jestem zdecydowanie przeciwny zabraniu najdroższej i najtrudniejszej do skalowania części infrastruktury (bazy danych) i włożeniu w nią całego obciążenia. Z drugiej strony: znacznie upraszcza strategię tworzenia kopii zapasowych, zwłaszcza gdy masz wiele serwerów WWW i potrzebujesz synchronizacji danych.
Jak większość innych rzeczy, zależy to od oczekiwanego rozmiaru i budżetu.
Wdrożyliśmy system obrazowania dokumentów, który przechowuje wszystkie jego obrazy w polach obiektów blob SQL2005. Obecnie jest ich kilkaset GB i widzimy doskonałe czasy reakcji oraz niewielki lub żaden spadek wydajności. Ponadto, zgodnie z regulacjami fr, mamy warstwę oprogramowania pośredniego, która archiwizuje nowo przesłane dokumenty do optycznego systemu szafy grającej, który udostępnia je jako standardowy system plików NTFS.
Jesteśmy bardzo zadowoleni z wyników, szczególnie w odniesieniu do:
Założenie: Aplikacja obsługuje sieć / sieć
Dziwi mnie, że nikt tak naprawdę o tym nie wspomniał ... przekaż to innym, którzy są specjalistami -> użyj zewnętrznego dostawcy hostingu obrazów / plików .
Przechowuj swoje pliki w płatnej usłudze online, takiej jak
Kolejne wątki StackOverflow mówią o tym tutaj .
Ten wątek wyjaśnia, dlaczego powinieneś używać zewnętrznego dostawcy hostingu.
To jest tego warte. Przechowują to skutecznie. Brak pasma przesyłania z twoich serwerów na żądania klientów itp.
Jeśli nie korzystasz z programu SQL Server 2008 i masz solidne powody, by umieszczać określone pliki obrazów w bazie danych, możesz zastosować podejście „oba” i użyć systemu plików jako tymczasowej pamięci podręcznej i użyć bazy danych jako głównego repozytorium .
Na przykład logika biznesowa może sprawdzić, czy plik obrazu istnieje na dysku, przed jego podaniem, w razie potrzeby pobierając go z bazy danych. Dzięki temu zyskujesz możliwość obsługi wielu serwerów WWW i mniej problemów z synchronizacją.
Nie jestem pewien, jak bardzo jest to przykład z „prawdziwego świata”, ale obecnie mam tam aplikację, która przechowuje szczegóły gry karcianej, w tym obrazy kart. Przyznano, że do tej pory w bazie danych było tylko 2851 rekordów, ale biorąc pod uwagę fakt, że niektóre karty zostały wydane wiele razy i mają alternatywną grafikę, w rzeczywistości bardziej efektywne było skanowanie „głównego kwadratu” grafiki, a następnie dynamicznie na żądanie wygeneruj obramowanie i różne efekty dla karty.
Pierwotny twórca tej biblioteki obrazów stworzył klasę dostępu do danych, która renderuje obraz na podstawie żądania, i robi to dość szybko do przeglądania i pojedynczej karty.
Ułatwia to także wdrażanie / aktualizacje po wydaniu nowych kart, zamiast spakować cały folder obrazów i wysłać je w dół potoku i upewnić się, że utworzono odpowiednią strukturę folderów, po prostu aktualizuję bazę danych i każę użytkownikowi pobrać ją ponownie. To obecnie rozmiar do 56 MB, co nie jest świetne, ale pracuję nad funkcją aktualizacji przyrostowych dla przyszłych wydań. Ponadto istnieje wersja aplikacji „bez obrazów”, która pozwala osobom korzystającym z połączenia modemowego na uzyskanie aplikacji bez opóźnienia pobierania.
To rozwiązanie działało do tej pory świetnie, ponieważ sama aplikacja jest ukierunkowana jako pojedyncze wystąpienie na pulpicie. Istnieje strona internetowa, na której wszystkie te dane są archiwizowane w celu uzyskania dostępu online, ale w żadnym wypadku nie użyłbym tego samego rozwiązania. Zgadzam się, że dostęp do plików byłby preferowany, ponieważ lepiej skalowałby się do częstotliwości i liczby żądań dotyczących obrazów.
Mam nadzieję, że nie jest to zbyt wiele bełkotu, ale widziałem ten temat i chciałem przekazać moje spostrzeżenia ze stosunkowo udanej aplikacji na małą / średnią skalę.
SQL Server 2008 oferuje rozwiązanie, które ma to, co najlepsze z obu światów: typ danych strumienia danych .
Zarządzaj nim jak zwykłą tabelą i uzyskaj wydajność systemu plików.
To zależy od liczby zdjęć, które zamierzasz przechowywać, a także od ich rozmiarów. W przeszłości korzystałem z baz danych do przechowywania zdjęć i moje doświadczenie było dość dobre.
IMO, plusy używania bazy danych do przechowywania zdjęć to:
A. Nie potrzebujesz struktury FS do przechowywania zdjęć
B. Indeksy baz danych działają lepiej niż drzewa FS, gdy ma być przechowywana większa liczba elementów
C. Inteligentnie dostrojona baza danych dobrze sprawdza się w buforowaniu wyników zapytań
D. Kopie zapasowe są proste. Działa również dobrze, jeśli masz skonfigurowaną replikację, a zawartość jest dostarczana z serwera w pobliżu użytkownika. W takich przypadkach wyraźna synchronizacja nie jest wymagana.
Jeśli twoje obrazy będą małe (powiedzmy <64k), a silnik pamięci twojego db obsługuje wbudowane (w zapisie) BLOBy, poprawia to wydajność, ponieważ nie jest wymagana żadna pośrednia (osiągana jest lokalizacja odniesienia).
Przechowywanie zdjęć może być złym pomysłem, gdy masz do czynienia z niewielką liczbą zdjęć o dużych rozmiarach. Innym problemem związanym z przechowywaniem obrazów w db jest to, że w metadanych takich jak tworzenie daty modyfikacji muszą być obsługiwane przez aplikację.
Niedawno stworzyłem aplikację PHP / MySQL, która przechowuje pliki PDF / Word w tabeli MySQL (do tej pory nawet 40 MB na plik).
Plusy:
Cons:
Nazwałbym moją implementację sukcesem, dba o wymagania dotyczące kopii zapasowych i upraszcza układ projektu. Wydajność jest dobra dla 20-30 osób korzystających z aplikacji.
Z mojego doświadczenia musiałem zarządzać obydwoma sytuacjami: obrazy przechowywane w bazie danych i obrazy w systemie plików ze ścieżką przechowywaną w db.
Pierwsze rozwiązanie, obrazy w bazie danych, jest nieco „czystsze”, ponieważ warstwa dostępu do danych będzie musiała zajmować się tylko obiektami bazy danych; ale jest to dobre tylko wtedy, gdy masz do czynienia z niskimi liczbami.
Oczywiście wydajność dostępu do bazy danych, gdy masz do czynienia z dużymi obiektami binarnymi, zmniejsza się, a wymiary bazy danych znacznie wzrosną, powodując ponownie spadek wydajności ... i zwykle przestrzeń bazy danych jest znacznie droższa niż przestrzeń systemu plików.
Z drugiej strony posiadanie dużych obiektów binarnych przechowywanych w systemie plików spowoduje, że będziesz mieć plany tworzenia kopii zapasowych, które muszą uwzględniać zarówno bazę danych, jak i system plików, co może stanowić problem w niektórych systemach.
Kolejnym powodem, dla którego warto wybrać system plików, jest konieczność udostępniania danych zdjęć (lub dźwięków, wideo itp.) Osobom trzecim: w tej chwili opracowuję aplikację internetową, która korzysta z obrazów dostępnych z zewnątrz „moja farma internetowa w taki sposób, że dostęp do bazy danych w celu pobierania danych binarnych jest po prostu niemożliwy. Czasami więc istnieją również względy projektowe, które doprowadzą cię do wyboru.
Podejmując ten wybór, należy również wziąć pod uwagę, czy podczas uzyskiwania dostępu do obiektów binarnych trzeba mieć do czynienia z uprawnieniami i uwierzytelnianiem: te wymagania można normalnie rozwiązać w łatwiejszy sposób, gdy dane są przechowywane w db.
Kiedyś pracowałam nad aplikacją do przetwarzania obrazu. Przesłane obrazy zapisaliśmy w katalogu podobnym do / images / [dzisiejsza data] / [numer identyfikacyjny]. Ale wyodrębniliśmy również metadane (dane exif) z obrazów i zapisaliśmy je w bazie danych wraz ze znacznikiem czasu i tym podobne.
W poprzednim projekcie zapisywałem obrazy w systemie plików, co spowodowało wiele problemów z kopiami zapasowymi, replikacją i brakiem synchronizacji systemu plików z bazą danych.
W moim najnowszym projekcie przechowuję obrazy w bazie danych i buforuję je w systemie plików, i działa naprawdę dobrze. Do tej pory nie miałem problemów.
Po drugie zalecenie dotyczące ścieżek plików. Pracowałem nad kilkoma projektami, które wymagały zarządzania dużymi zbiorami zasobów, a wszelkie próby przechowywania rzeczy bezpośrednio w DB spowodowały długofalowy ból i frustrację.
Jedynym prawdziwym „pro”, jaki mogę wymyślić w zakresie przechowywania ich w bazie danych, jest możliwość łatwego dostępu do indywidualnych zasobów obrazu. Jeśli nie ma ścieżek do użycia, a wszystkie obrazy są przesyłane strumieniowo bezpośrednio z bazy danych, użytkownik nie może znaleźć plików, do których nie powinien mieć dostępu.
Wydaje się jednak, że lepiej byłoby to rozwiązać za pomocą skryptu pośredniczącego pobierającego dane z magazynu plików niedostępnego w Internecie. Dlatego pamięć DB nie jest NAPRAWDĘ konieczna.
Słowo na ulicy jest takie, że jeśli nie jesteś dostawcą bazy danych, który próbuje udowodnić, że twoja baza danych może to zrobić (powiedzmy, że Microsoft przechwala się Terraserverem przechowującym bajillionowe obrazy w SQL Server), nie jest to zbyt dobry pomysł. Skoro alternatywa - przechowywanie obrazów na serwerach plików i ścieżkach w bazie danych jest o wiele łatwiejsze, po co zawracać sobie głowę? Pola kropelek przypominają możliwości terenowych SUV-ów - większość ludzi ich nie używa, ci, którzy zwykle mają kłopoty, a potem są tacy, którzy robią to, ale tylko dla zabawy.
Przechowywanie obrazu w bazie danych nadal oznacza, że dane obrazu kończą się gdzieś w systemie plików, ale są ukryte, więc nie można uzyskać do nich bezpośredniego dostępu.
+ ves:
-ves:
Obie metody są powszechne i praktykowane. Zobacz zalety i wady. Tak czy inaczej, będziesz musiał pomyśleć o tym, jak pokonać wady. Przechowywanie w bazie danych zwykle oznacza modyfikację parametrów bazy danych i wdrożenie pewnego rodzaju buforowania. Korzystanie z systemu plików wymaga znalezienia sposobu na synchronizację systemu plików i bazy danych.