Przechowywanie obrazów w bazie danych MySQL

Z Podręcznik Administratora by OPZ SGU
Wersja z dnia 00:44, 12 paź 2009 autorstwa Adminka23 (dyskusja | edycje) (na dokoćzenie...)
(różn.) ← poprzednia wersja | przejdź do aktualnej wersji (różn.) | następna wersja → (różn.)
Przejdź do nawigacji Przejdź do wyszukiwania

Od pewnego czasu otrzymywałem zapytania z prośbą mającą na celu ustalenie wszystkich za i przeciw w kontekście trzymania zdjęć w bazie danych zamiast tradycyjnych plików.

W Internecie znaleźć można fanatyków tego rozwiązania jak i osoby podchodzące do niego sceptycznie bądź krytycznie.


Testy zamierzam przeprowadzić na podstawie dwóch płaszczyzn pomiaru, pierwszym będzie platforma testowa a drugim nowo otwarty projekt realizowany w oparciu o zdjęcia z serwera MySQL. Po wdrożeniu serwisu do produkcji udostępniony zostanie pełny raport.


Co przemawia ZA utrzymywaniem zdjęć w bazie danych ?

  • Serwis wykonany w powyższej technologii charakteryzuje się automatycznym wzrostem bezpieczeństwa +40%.

Wszystko to dzięki możliwości całkowitego wykluczenia zapisu w ścieżce domowej projektu. (nie ma konieczności nadawania folderom uprawnień zapisu)

  • Najwyższy możliwy poziom kontroli przepływu informacji / dostępu.

Plik PHP odpowiadający za pobieranie z bazy danych zdjęcia i wyświetlaniu może być dowolnie modyfikowany względem uprawnień odczytu. Dostajemy narzędzie pozwalające na ograniczenie dostępności do zdjęcia przykładowo "tylko osobom zalogowanym". Osoby niezalogowane mogą otrzymać obrazek informujący o konieczności logowania.

Dotychczasowo następujący poziom bezpieczeństwa można było uzyskać korzystając z odpowiedników fopen i przepisywaniu treści oryginalnego pliku (położonego ścieżkę wyżej niż katalog główny strony, jednym słowem miejscem niedostępnym z poziomu przeglądarki) do dynamicznie generowanego pliku na potrzebę użytkownika.

  • Brak konieczności dublowania wpisów bazy danych

Przy tradycyjnej metodzie każde zdjęcie (w rozumieniu jako wpis w bazie danych, zawierające autora, podpis, uprawnienia) musi być powiązane z istniejącym na dysku twardym plikiem. Każdy nieudany zapis, odczyt, migracja danych mógł prowadzić do niespójności między bazą a plikami znajdującymi się fizycznie na dysku. Często wykrywanie takich konfliktów wymagało wykorzystania autorskiego oprogramowania pisanego specjalnie pod dany serwis oraz strukturę.

  • Łatwa migracja danych

Migracja zdjęć z jednego serwera na drugi wymaga jedynie wykonania pełnego zrzutu tabeli. Nie musimy martwić się o poprawność ścieżek dostępu i wspomniane na początku uprawnienia.

  • Skalowalność (bezkonfliktowość w klastrowaniu)

MySQL można dowolnie skalować względem dostępności oraz rozłożenia obciążenia. Nie ma konieczności bezpośredniego montowania (folderów NFS / dysków iSCSI) macierzy ze zdjęciami podczas przykładowego klastrowania Apache. Na okrojonych węzłach "nodach" odpowiadających za udostępnianie zdjęć (img.xxx.xx / img2.xxx.xxx) wystarczy udzielić dostęp do serwera MySQL. Resztę konfiguracji można dowolnie powielać między węzłami.