Przechowywanie obrazów w bazie danych MySQL - Historia wersji

Adminka23 o 13:30, 20 lut 2010

2010-02-20T13:30:28Z

← poprzednia wersja		Wersja z 21:30, 20 lut 2010
Linia 3:		Linia 3:
	W Internecie znaleźć można fanatyków tego rozwiązania jak i osoby podchodzące do niego sceptycznie bądź krytycznie.		W Internecie znaleźć można fanatyków tego rozwiązania jak i osoby podchodzące do niego sceptycznie bądź krytycznie.

			[[Plik:Obrazy w bazie mysql.png\|200px\|thumb\|right\|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.		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.

Adminka23 o 18:36, 11 paź 2009

2009-10-11T18:36:35Z

← poprzednia wersja		Wersja z 02:36, 12 paź 2009
Linia 42:		Linia 42:
	{\| class="wikitable"		{\| class="wikitable"
	\|-		\|-
	!Konwencjonalne statyczne zdjęcie z dysku		!bgcolor="red"\|Konwencjonalne statyczne zdjęcie z dysku
	!Zdjęcie dynamicznie pobierane z MySQL		!bgcolor="green"\|Zdjęcie dynamicznie pobierane z MySQL
	! Wniosek		!bgcolor="gray"\| Wniosek
	\|-		\|-
	\|~~Konwencjonalne statyczne zdjęcie~~		\|
	\|~~Zdjęcie dynamicznie pobierane z MySQL~~		\|
	\|		\|
	\|-		\|-
Linia 75:		Linia 75:
	Shortest transaction: 0.83		Shortest transaction: 0.83

	\|bgcolor="~~gray~~"\|		\|bgcolor="green"\|
	Transactions: 427 hits		Transactions: 427 hits

Linia 101:		Linia 101:


	\| Wydajność na porównywalnym poziomie aczkolwiek zwykłe pliki oczywiście prowadzą.		\|bgcolor="gray"\| Wydajność na porównywalnym poziomie aczkolwiek zwykłe pliki oczywiście prowadzą.
	\|-		\|-
	\|		\|
Linia 108:		Linia 108:
	\|		\|
	[[Plik:Plik_dynamiczny_z_mysql.png\|300px\|thumb\|Wykorzystanie procesora]]		[[Plik:Plik_dynamiczny_z_mysql.png\|300px\|thumb\|Wykorzystanie procesora]]
	\|Wyraźnie widoczna różnica w wykorzystaniu procesora		\|bgcolor="gray"\|Wyraźnie widoczna różnica w wykorzystaniu procesora
	\|}		\|}

Adminka23 o 18:33, 11 paź 2009

2009-10-11T18:33:10Z

← poprzednia wersja		Wersja z 02:33, 12 paź 2009
Linia 33:		Linia 33:
	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.		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.		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ń. ==

			{\| class="wikitable"
			\|-
			!Konwencjonalne statyczne zdjęcie z dysku
			!Zdjęcie dynamicznie pobierane z MySQL
			! Wniosek
			\|-
			\|Konwencjonalne statyczne zdjęcie
			\|Zdjęcie dynamicznie pobierane z MySQL
			\|
			\|-
			\|bgcolor="red"\|
			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

			\|bgcolor="gray"\|
			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ą.
			\|-
			\|

			[[Plik:Zwykly_plik_statyczny.png\|300px\|thumb\|Wykorzystanie procesora]]
			\|
			[[Plik:Plik_dynamiczny_z_mysql.png\|300px\|thumb\|Wykorzystanie procesora]]
			\|Wyraźnie widoczna różnica w wykorzystaniu procesora
			\|}

Adminka23: na dokoćzenie...

2009-10-11T16:44:06Z

na dokoćzenie...

Nowa strona

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.