Przechowywanie zdjęć w DB - Tak czy nie?


415

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:


350

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:

  • przechowywanie bazy danych jest zwykle droższe niż przechowywanie w systemie plików
  • możesz bardzo przyspieszyć dostęp do systemu plików dzięki standardowym produktom z półki
    • na przykład wiele serwerów WWW używa wywołania systemowego sendfile () systemu operacyjnego, aby asynchronicznie wysłać plik bezpośrednio z systemu plików do interfejsu sieciowego. Obrazy przechowywane w bazie danych nie korzystają z tej optymalizacji.
  • rzeczy takie jak serwery sieciowe itp. nie wymagają specjalnego kodowania ani przetwarzania, aby uzyskać dostęp do obrazów w systemie plików
  • bazy danych wygrywają tam, gdzie ważna jest integralność transakcyjna między obrazem a metadanymi.
    • Bardziej złożone jest zarządzanie integralnością między metadanymi db a danymi systemu plików
    • (w kontekście aplikacji internetowej) trudno jest zagwarantować, że dane zostały wypłukane na dysk w systemie plików

33
jakie produkty z półki są dostępne do „super-przyspieszania” systemu plików?
Andrei Rînea

22
Chociaż zarządzam tylko 3 TB plików, zdecydowanie się zgadzam. Bazy danych służą do danych strukturalnych, a nie obiektów blob.
derobert

7
@derobert: tak więc, jeśli nigdy nie użyjesz elementu danych w zapytaniu, jako warunku lub przy łączeniu, prawdopodobnie nie należy on do bazy danych. Z drugiej strony, jeśli masz ładną funkcję bazy danych, która pozwala wyszukiwać obrazy na podobieństwo ...
Nils Weinander,

14
jakie produkty z półki są dostępne do „super-przyspieszania” systemu plików?
ablmf

5
Re: Produkty „przyspieszające”: większość serwerów internetowych może teraz skorzystać z wywołania systemowego sendfile (), aby asynchronicznie dostarczać pliki statyczne do klienta. Przenosi do systemu operacyjnego zadanie przeniesienia pliku z dysku na interfejs sieciowy. System operacyjny może to zrobić znacznie wydajniej, działając w przestrzeni jądra. Wydaje mi się, że to duża wygrana dla systemu plików vs. db do przechowywania / udostępniania obrazów.
Alan Donnelly,

140

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.

  • Przechowujesz obrazy, które zmieniają się dynamicznie, powiedzą faktury i chciałeś otrzymać fakturę taką, jaka była 1 stycznia 2007 r.?
  • Rząd chce, abyś zachował 6 lat historii
  • Obrazy przechowywane w bazie danych nie wymagają innej strategii tworzenia kopii zapasowych. Obrazy przechowywane w systemie plików to robią
  • Łatwiej jest kontrolować dostęp do obrazów, jeśli znajdują się one w bazie danych. Bezczynni administratorzy mogą uzyskać dostęp do dowolnego folderu na dysku. Naprawdę zdeterminowany administrator musi węszyć w bazie danych, aby wyodrębnić obrazy

Z drugiej strony występują problemy

  • Wymagaj dodatkowego kodu, aby wyodrębnić i przesłać strumieniowo obrazy
  • Opóźnienie może być wolniejsze niż bezpośredni dostęp do pliku
  • Większe obciążenie serwera bazy danych

2
Brak oddzielnej strategii tworzenia kopii zapasowych może być dużym problemem, gdy piszesz aplikacje instalowane lokalnie (takie jak SharePoint). Podczas tworzenia kopii zapasowej programu SharePoint wszystko znajduje się w bazie danych, co bardzo ułatwia.
Eric Schoonover

44
Bezpieczeństwo przez zaciemnienie nie jest tak naprawdę strategią kontroli dostępu!
Jon Cage

5
Nie sądzę, by popierał bezpieczeństwo przez zaciemnianie - mówi, że umieszczanie obrazów w DB dodaje kolejną warstwę bezpieczeństwa. (Myślę ... @ Conrad, nie chcę wkładać słów do ust)
AJ.

Wybrałem przechowywanie obrazów w bazie danych ze względu na zaletę pojedynczej kopii zapasowej (lub bardziej ogólnie mówiąc, posiadanie wszystkich danych w jednym miejscu), ale wspomniane problemy są również prawdziwe, dlatego buforuję obrazy w systemie plików. To najlepsze z obu światów i jestem zaskoczony, że żadna z najlepszych odpowiedzi tutaj nie wspomina o tym.
Bart van Heukelom

Czy przypadkiem używasz biblioteki ImageResizing.Net do obsługi buforowania obrazu dysku SQL->? To najbardziej zaawansowana, skalowalna i niezawodna pamięć podręczna dysków, jaką można uzyskać ...
Lilith River,


56

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:

  1. Obiekty BLOB są faktycznie przechowywane jako pliki w folderze.
  2. Plamy można uzyskać za pomocą albo połączenia z bazą danych lub całego systemu plików.
  3. Kopie zapasowe są zintegrowane.
  4. Migracja „po prostu działa”.

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ń.


+1 dla FileStream. W rzeczywistości przechowuje obiekty BLOB jako pliki na dysku, ale zarządza nimi transakcyjnie.
John Gietzen

Ponadto SQL Server pozwala obiektom BLOB FileStream na dostęp bezpośrednio z dysku, dzięki czemu można uniknąć wiązania połączenia DB
John Gietzen

Mimo to dodano opóźnienie między bazą danych a serwerem WWW ... I serwer internetowy będzie musiał załadować go do pamięci, aby przesyłać strumieniowo do klienta, zamiast móc przesyłać strumieniowo z dysku, chyba że korzystasz z buforowania dysku.
Lilith River,

39

Ś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.


35

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.


Naprawdę bardzo ładnie. Użytkownicy mogą teraz z łatwością zwiększać nazwę pliku, aby uzyskać dostęp do innych plików ...
Marijn Huizendveld

6
@Marijn: Dzieje się tak tylko wtedy, gdy udostępniasz obrazy światu.
Seun Osewa

Zrobiliśmy coś bardzo podobnego z naszymi dokumentami obrazowymi (nasz klucz podstawowy to klucz złożony z trzech elementów), ale dodaliśmy datę i godzinę skanowania dokumentu, abyśmy mogli mieć wiele wersji w tym samym katalogu.
Andrew Neely,

@Osewa, jak to jest? Tak, aby uzyskać bezpośredni dostęp do pliku, użytkownik końcowy będzie potrzebował dostępu do folderu. Możesz mieć proces obsługi pliku przez FTP na żądanie, a zabezpieczenia byłyby na równi z serwerem SQL.
Andrew Neely,

31

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.


6
Nie widzę nikogo, kto twierdzi, że system plików jest szybszy niż DB w 100% przypadków (przeczytaj odpowiedź Marka Harrisona). To trochę słomka. Prawdopodobnie są sytuacje, w których lepiej nie zapinać pasów, ale ogólnie rzecz biorąc , zapinanie pasów jest dobrym pomysłem.
Calvin

30

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.


7
Właściwie nie, możesz. Tak długo, jak pliki obrazów nigdy nie są usuwane, zmieniane ani nadpisywane po utworzeniu, wszystkie pliki obrazów są synchronizowane przed próbą zatwierdzenia transakcji, nie ma uszkodzenia systemu plików, możesz być pewien, że pliki obrazów i metadane są zsynchronizowane. Sądzę, że w przypadku niektórych aplikacji jest ich zbyt wiele.
Seun Osewa,

Chciałbym pójść jeszcze dalej i powiedzieć, że dzięki systemowi plików Journaling i dodatkowej logice programu można osiągnąć zgodność z ACID. Kroki to zapisanie rekordu db, zapisanie pliku. Jeśli plik zostanie zatwierdzony, zatwierdz transakcję db.
Andrew Neely,

28

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.


27

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.


Argumentowałbym, że baza danych jest lepsza dla plików, które są często edytowane, ponieważ spójność może w tym przypadku stanowić problem.
Seun Osewa,

26

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.


25

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.


Można by tak sądzić, ale w rzeczywistości problemy są niewielkie; Mam aplikację z milionami plików w jednym katalogu, do której dostęp mają setki użytkowników, bez problemu. To nie jest mądre, ale działa. Największym problemem jest to, że jeśli używasz Eksploratora do przeglądania katalogu, oglądasz latarkę na zawsze.
SqlACID

1
Lepiej jest użyć systemu plików, który nie ma problemu z dużymi katalogami
Seun Osewa

8
Miałem aplikację z milionami plików w jednym katalogu (serwer z systemem RHEL 4) - nawet lista zawartości katalogu (przesyłanie potoków do pliku) zajęła kilka dni i utworzyłem plik wyjściowy o wielkości 100 MB. Teraz są w bazie danych, mam jeden plik, który mogę łatwo przenieść lub wykonać kopię zapasową.
Richard

1
@ Seun Osewa: każdy system plików ma ograniczenia ... a jeśli znasz taki, który nie ma problemów z przechowywaniem milionów wpisów w tym samym katalogu, daj mi znać!
Guillaume,

1
@ Seun Osewa: baza danych ma teraz pojemność do 28 GB, z rekordami 5,4 mln. Skończyłem z partycjonowaniem tabeli bazy danych, więc muszę utworzyć kilka kopii zapasowych o wielkości około 5 GB. Przenoszenie poszczególnych obrazów na Amazon S3 teraz, więc muszę tylko przechowywać nazwę pliku w DB (i Amazon może robić kopie zapasowe )
Richard,

22

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.


Jakie jest prawdopodobieństwo posiadania dwóch jednoczesnych aktualizacji konkretnego obrazu?
Arafangion

1
nie potrzebujesz równoczesnych aktualizacji, aby mieć problemy - może to być odczyt i zapis. W naszym przypadku prawie na pewno się to wydarzy.
Draemon

20

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.


17

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


5
Absolutnie. Najwyraźniej baza danych jest teraz znacznie większa. Posiadanie danych w bazie danych oznacza, że ​​replikacja bazy danych w różnych witrynach jest znacznie łatwiejsza.
graham.reeds

Widziałem demonstrację Oracle, w której mógłby faktycznie zamontować system plików w bazie danych lub coś w tym rodzaju. Czy wiesz, czy to właśnie zrobiłeś? (Przepraszam, nie mam pojęcia o Oracle, więc może mówię śmieci).
Stu Thompson

Nie sądzę - to było przechowywanie obrazów w bazie danych jako baza danych. Baza danych została agresywnie dostrojona - pamiętam wiele dyskusji na temat wielkości obrazów zmieniających się w miarę dodawania i usuwania pól. Wszystko było wyrównane do granic.
graham.reeds

14

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.


13

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:

  1. Łatwość replikacji i tworzenia kopii zapasowych
  2. Możliwość łatwego wdrożenia systemu wersjonowania dokumentów

11

Jeśli jest to aplikacja internetowa, przechowywanie obrazów w sieci dostarczającej pamięć masową innej firmy, takiej jak Amazon S3 lub platforma Nirvanix, może być korzystne.


11

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.


10

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ą.


+1 Pozwala to również przechowywać oryginalny obraz, dostarczając wersję buforowaną / zoptymalizowaną, umożliwiając później zmianę rozmiaru / kompresji
Deebster,

7

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ę.


W przypadku replikacji przechowywanie obrazów w bazie danych jest zdecydowanie lepsze od IMO.
Sygnał dźwiękowy


7

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ę.


7

Niedawno stworzyłem aplikację PHP / MySQL, która przechowuje pliki PDF / Word w tabeli MySQL (do tej pory nawet 40 MB na plik).

Plusy:

  • Przesłane pliki są replikowane na serwer kopii zapasowych wraz ze wszystkim innym, nie jest wymagana osobna strategia tworzenia kopii zapasowych (spokój).
  • Konfiguracja serwera WWW jest nieco prostsza, ponieważ nie muszę mieć folderu upload / folder i informować wszystkich moich aplikacji, gdzie to jest.
  • Transakcje używam do edycji w celu poprawy integralności danych - nie muszę się martwić o osierocone i brakujące pliki

Cons:

  • mysqldump zajmuje teraz dużo czasu, ponieważ w jednej z tabel znajduje się 500 MB danych pliku.
  • Ogólnie niezbyt wydajna pamięć / procesor w porównaniu do systemu plików

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.


6

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.


4

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.


4

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.


3

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.


3

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.


3

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:

  • integralność bazy danych
  • jest łatwy w zarządzaniu, ponieważ nie musisz martwić się o synchronizację systemu plików podczas dodawania lub usuwania obrazu

-ves:

  • obniżenie wydajności - przeszukiwanie bazy danych jest zwykle wolniejsze niż przeszukiwanie systemu plików
  • nie możesz edytować obrazu bezpośrednio (przycinanie, zmiana rozmiaru)

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.