Przechowywanie obrazów w bazie danych MySQL

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.

Obrazy w mysql longblob

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.

Test wydajności podczas pobierania zdjęcia (1,2 MB) z Apache 40 jednoczesnych połączeń.

Konwencjonalne statyczne zdjęcie z dysku	Zdjęcie dynamicznie pobierane z MySQL	Wniosek
Transactions: 431 hits Availability: 100.00 % Elapsed time: 59.67 secs Data transferred: 526.66 MB Response time: 3.77 secs Transaction rate: 7.22 trans/sec Throughput: 8.83 MB/sec Concurrency: 27.20 Successful transactions: 431 Failed transactions: 0 Longest transaction: 26.72 Shortest transaction: 0.83	Transactions: 427 hits Availability: 100.00 % Elapsed time: 59.93 secs Data transferred: 521.77 MB Response time: 3.65 secs Transaction rate: 7.12 trans/sec Throughput: 8.71 MB/sec Concurrency: 26.02 Successful transactions: 427 Failed transactions: 0 Longest transaction: 13.42 Shortest transaction: 0.25	Wydajność na porównywalnym poziomie aczkolwiek zwykłe pliki oczywiście prowadzą.
Wykorzystanie procesora	Wykorzystanie procesora	Wyraźnie widoczna różnica w wykorzystaniu procesora