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.
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ą. |
| Wyraźnie widoczna różnica w wykorzystaniu procesora |
