Przechowywanie obrazów w bazie danych MySQL

Z Podręcznik Administratora by OPZ SGU
Wersja z dnia 21:30, 20 lut 2010 autorstwa Adminka23 (dyskusja | edycje)
(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.

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