Wydajność - Dużo folderów, dużo zdjęć., Wyświetlanie zdjęć z danego katalogu, a nie po adresach z DB. Opcje

[adbacz]

Witam i z góry przepraszam za tytuł tematu, ale nie wiedziałem jak to opisać.

Piszę pewien katalog i akurat jestem na poziomie pisania systemu uploadu i downloadu plików. Wpadłem na pewien pomysł. Mianowicie, zamiast zmuszać użytkownika do wpisywania pełnych adresów do zdjęć danego produktu i zapisywać to w DB, zrobić w folderze głównym folder o nazwie takiej samej jak ID danego produktu, i podczas wyświetlania tego produktu, sprawdzać, czy istnieje taki katalog i w nim zdjęcia, i stamtąd pobierać nazwy i wyświetlać zdjęcia.

Np. mamy kategorię ProductOne i dla tej kategorii tworzymy główny katalog o tej samej nazwie w katalogu upload. Podczas gdy będzie dodawany nowy produkt do tego katalogu i zdjęcia do niego, zostanie utworzony nowy katalog o nazwe ID produktu, np. upload/productone/155, i w tym katalogu zamieszczać wszystkie zdjęcia. A gdy ktoś będzie odwiedzał naszą stronę, będziemy sprawdzać czy katalog o ID produktu istnieje i będziemy pobierać wszystkie obrazki jakie tam są, i wyświetlać je.

Wg mnie, dość dobry patent na to, aby w jakimś stopniu zapobiec zapełnianiu sie przestrzeni dyskowej niepotrzebnymi plikami, które nie będą wykorzystywane. Ale teraz pytanie, czy to nie będzie zbyt obciążające dla serwera? Żeby za każdym razem sprawdzać czy katalog istnieje, przebierać po wszystkich plikach w tym katalogu, pobierać ich nazwy i dopiero wyświetlać?

[cudny]

Oczywiście masz do tego prawo.



Tym razem to ja się z tobą nie zgodzę. Wystarczy dodatkowa kolumna z auto inkrementacją. Chyba że chodziło ci zupełnie o coś innego.



Otworzenie pliku może i tak, w przypadku jego dodatkowego parsowania, a już w przypadku kategorii gdzie możesz mieć różne produkty, a już nie wspomnę o wyszukiwarce, gdzie produkty są już całkowicie różne. To wylistowanie 40 produktów i 40 razy parsować xml'em 40 różnych plików w poszukiwaniu istnienia miniatury produktu jest IMO przerostem treści nad formą. Już nie mówiąc o tym że wydajnościowo to jest bardzo kiepskie rozwiązanie.



Ten request i tak wykonać musisz, żeby pobrać opis produktu, jego nazwę, cenę. Dodatkowy join do tabeli z miniaturkami i pobierasz te dane w jednym requęście. Przy niewielkim, lub nawet nie zauważalnie zwiększonym obciążeniu. W przypadku xml musisz to robić 40 razy, dla 40 produktów. 40 razy sprawdzasz czy masz prawa odczytu, 40 razy tworzysz nową instancje obiektu prasującego xml. Niestety, liczby źle wróżą xml'owi.



Tak, może być bez sensu, zależy jak na to patrzeć, dlatego podałem drugą opcję, która zarówno nie sprawdza 40 razy czy plik istnieje i wykonuje odpowiednie czynności w przypadku jego nie istnienia.



Porównanie akurat do androida tutaj ma się nijak. Zauważ że z androida w jednym momencie jedna osoba korzysta. Z takiego allegro, gdzie masz listowanych 40 aukcji na stronie, korzysta kilka milionów ludzi dziennie. A dodatkowo w androidzie to sobie trzymasz te dane tak na prawdę gdzie chcesz, to już zależy od ciebie, i nie masz z góry narzuconego schematu. Bo możesz zarówno w xml, jak i w sqlite trzymać.

Może i pójście na łatwiznę, tyle że to nie jest tworzone dla sztuki podziwiania wykorzystanych mechanizmów, ale do eksploatowania i między innymi zarabiania. A nie zarobisz nic lub niewiele, jeżeli większość twoich dochodów pochłonie nieoptymalna aplikacja.

Ale temat nie o tym. XML odpada w przedbiegach w takim przykładzie jaki podałeś. Używać możesz, działać działa, ale czy jest wydajne to jest kwestia o którą się pyta autor tematu. A xml nigdy nie było dość szybkie.

W ani jednym przypadku nie masz racji.
O jakim ty parsowaniu piszesz ?
Pobierasz sobie XML do dooma i jedziesz wykorzystując plik strumieniowo.
W rzeczywistości nie pobierasz całkowicie całego pliku.
Jeśli chodzi o autoinkrementacje to do czego to miało by służyć w przypadku kolejności ?
Tabela:
id|nazwa|kod|kolejnosc

i co ? jeśli chcesz mieć produkty wyświetlane w/g własnych potrzeb kolejności to co .... za każdą zmiana kolejności zmieniasz każdy rekord w tabeli.
Autoincrement to zupełnie inna bajka.

Co do trzymania danych w bazie, a w xml to powiedz no mi jak ładnie rozwiążesz drzewko kategorii w bazie danych (IMG:style_emoticons/default/biggrin.gif)
Widzę, że jeszcze nie przyszło ci pracować z XML lub nie robiłeś żadnego sklepu jeszcze.
id|parent_id|nazwa
i co ? żeby pobrać drzewo kategorii musisz rekurencyjnie dawać zapytanie do bazy - w rezultacie nawet kilka tysięcy zapytań w ułamku sekundy.
Co do parsowania XML to nie parsujesz go tylko raz wyszukasz element, do którego będziesz się odwoływał i lecisz potem rekurencją po danych pięknie wyłożonych na talerz.
Zrób sobie aplikacje ze złożonym drzewem kategorii i dawaj pięknie sobie zapytania do bazy - powodzenia.
XML jest doskonałym narzędziem do szybkiego dostępu do danych.
A baza danych... pięknie ułatwia życie i nigdy XML jej nie zastąpi, ale jeśli chodzi o trzymanie prostych danych to dokładnie do tego xml jest stworzony !

Co do parsowania xml (IMG:style_emoticons/default/biggrin.gif) chyba nie do końca rozumiesz jak go używać.
xpatch lub zwykłe wyrażenia regularne.
Myślisz, że baza danych to co to jest ?
To są pliki parsowane po wyrażeniach regularnych, w przypadku mysql napisana w c++

Zachęcam do zapoznania się z dokumentacją narzędzi służących do parsowania xml

Co do wyszukiwania produktów z xml (IMG:style_emoticons/default/wink.gif) nikt nie każe ci opisów produktów trzymać w xml

Podsumowanie.
Wybór bazy danych zależny jest tylko i wyłącznie od tego jakie dane będą trzymane i wykorzystywane.
Nie wiem po co trzymać dane do obrazków w db skoro spokojnie możesz do tego użyć najprostszego narzędzia czyli xml
A jeszcze jedno co do operacji na plikach (IMG:style_emoticons/default/biggrin.gif)
file_exists() to nie jest operacja na plikach (IMG:style_emoticons/default/biggrin.gif) to tylko sprawdza czy coś o podanej ścieżce istnieje.
Mówiąc, że to zwolni aplikację to tak jakby dzielenie plików php na klasy miało też ją spowolnić - przecież też trzeba sprawdzić czy plik istnieje (IMG:style_emoticons/default/biggrin.gif)


OoO (IMG:style_emoticons/default/biggrin.gif) jeszcze to zauważyłem (IMG:style_emoticons/default/biggrin.gif)

W przypadku kiedy miniaturka będzie istnieć: uploads/images/product1/233/1_thumb.png wówczas zakryje default_thumb.jpg który znajduje się w div'ie pod spodem. Kiedy nie ma miniaturki, zwyczajnie wyświetli się tylko tło div'a.

Poco niby zaczytywać niepotrzebne obrazki ? Klient będzie czekał na ich załadowanie ?

Ten post edytował cudny 6.12.2011, 14:50:19