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ć?

[skowron-line]

Żeby za każdym razem sprawdzać czy katalog istnieje, przebierać po wszystkich plikach w tym katalogu, pobierać ich nazwy i dopiero wyświetlać?

Raczej nie. Problem zacznie się kiedy będzie ileś tak tyś odsłon. Bo jak to ma być 1000 odsłon dziennie to zero stresu.

[by_ikar]

Nie wiem szczerze mówiąc co tutaj ma ci obciążać, bo przecież i tak musisz sprawdzić przed wyświetleniem danych plików czy istnieją (chyba że ktoś tego nie robi i zakłada że jeżeli są wpisy w bazie to i są pliki). Sprawdzenie jeden raz czy katalog istnieje i wylistowanie zawartości poprzez chociażby directoryiterator powinno być całkiem dobrym rozwiązaniem.

[adbacz]

Jesli w bazie mamy tylko ścieżki do plików to sprawdzamy tylko czy plik istnieje, jeśli tak to go wyświetlamy, jeśli nie to nie. Tutaj jest troszkę inaczej, bo musimy sprawdzić czy istnieje katalog dla produktu. Później sprawdzić czy są jakieś pliki, pobierać wszystkie (np przez while i dir()), sprawdzać czy to obrazek i dopiero później wyświetlać. Troszeczkę więcej roboty niż zwykłe sprawdzanie czy plik istnieje, jeśli mamy do niego ścieżkę w bazie.

Dlatego też wolałem najpierw się upewnić, niż stosować coś co może obciążać serwer, a wiadomo, operacje na plikach są baaardzo wolne.

PS. Może źle zrozumiałeś by_ikar, ale nie chodzi mi tutaj o jednorazowe sprawdzenie czy katalog istnieje, ale sprawdzanie i listowanie plików (w tym przypadku obrazów) z katalogu za każdym razem, gdy użytkownik wejdzie na stronę z obrazkami danego produktu. Bo tylko w tedy będziemy je wyświetlać.

Ten post edytował adbacz 5.12.2011, 15:23:55

[by_ikar]

PS. Może źle zrozumiałeś by_ikar, ale nie chodzi mi tutaj o jednorazowe sprawdzenie czy katalog istnieje, ale sprawdzanie i listowanie plików (w tym przypadku obrazów) z katalogu za każdym razem, gdy użytkownik wejdzie na stronę z obrazkami danego produktu. Bo tylko w tedy będziemy je wyświetlać.

Tak, tak, dokładnie o to chodzi. Sprawdzasz ten katalog i jego zawartość tylko jeden raz przy jednym requeście, czyli pojedynczym wyświetleniu. directoryiterator jest jak znalazł dla twojego zastosowania, podajesz mu ścieżkę, a on jeżeli są pliki w danym katalogu, w sumie nawet określone pliki, to ci te pliki wylistuje.

Gorzej to się ma w przypadku kategorii i wyświetlenia wielu produktów, tutaj to już najlepiej mieć ścieżkę do miniatury danego produktu w bazie i podczas wyświetlania listy produktów nie sprawdzać każdorazowo istnienia miniaturki produktu, tylko powiedzmy sprawdzać to raz, czy ustawić sprawdzanie w cron'ie.

[adbacz]

No w sumie masz rację z tymi kategoriami. Niestety będzie ciężko z cron-em, ale tak sobie myślę, żeby obrazki przechowywać w folderze ponumerowane od jednego w górę, a w DB tylko dać możliwość ustawienia, który z obrazków ma być jako miniaturka. Albo nawet nie dawać, ale od razu, jak tylko wykryje zdjęcie o nazwe, np. 1.jpeg, to szukac jego miniaturki, jeśli nie znajdzie to utworzy i wyświetli, jeśli znajdzie to wyświetli. Miniaturki można nazywać 1_thumb.jpeg i w tedy nie będzie problemu. Mam rację?

[cudny]

ja ostatnio wpadłem na genialny pomysł.
Wiele rzeczy, które nie potrzebują relacji wkładam do xml (czyli bazy nie relacyjnej )
Robisz sobie plik xml, zabezpieczasz go .htaccess'em (deny from all) i wkładasz do niego wszystkie dane.
Fotki dajesz do jakiegoś katalogu zbiorczo numerując je powiedzmy po timestamp.
XML może wyglądać następująco:

[XML] pobierz, plaintext 
<root>
<images type="white">
<img value="45678945678" ext="jpg" name="image_1"/>
<img value="45678946539" ext="png" name="image_2" />
</images>
<images type="red">
<img value="45678945671" ext="jpg" name="image_3" />
<img value="45678946532" ext="gif" name="image_4" />
</images>
</root>
[XML] pobierz, plaintext 

robisz sobie dwa katalogi:

images/min
images/large

do min zapisujesz miniatruki do large oryginały.
oczywiście value to unikalna nazwa obrazka i musi być identyczna dla katalogu min i large.
kasując obrazek kasujesz z min, large i xml
w razie gdy chcesz poszukac obrazka po id to wykorzystujesz xpatch, a do parsowania używasz simpleXML lub DOM


Ten post edytował cudny 6.12.2011, 10:44:48

[by_ikar]

No w sumie masz rację z tymi kategoriami. Niestety będzie ciężko z cron-em, ale tak sobie myślę, żeby obrazki przechowywać w folderze ponumerowane od jednego w górę, a w DB tylko dać możliwość ustawienia, który z obrazków ma być jako miniaturka. Albo nawet nie dawać, ale od razu, jak tylko wykryje zdjęcie o nazwe, np. 1.jpeg, to szukac jego miniaturki, jeśli nie znajdzie to utworzy i wyświetli, jeśli znajdzie to wyświetli. Miniaturki można nazywać 1_thumb.jpeg i w tedy nie będzie problemu. Mam rację?

Dla kategorii możesz nawet inaczej zrobić. Obrazek zamiast w img, wyświetlić jako tło, dodatkowo ten obrazek trzymać w jakimś div'ie który będzie miał również tło - obrazka oznaczającego brak miniaturki. Wówczas kiedy zdarzy się przypadek że obrazek dla danego produktu nie istnieje, to żeby nie sprawdzać 40-60 razy na jeden request czy jakieś pliki istnieją, zwyczajnie wyświetli się obrazek oznaczający brak miniaturki. A do katalogu w którym masz obrazki, mógłbyś wrzucić jakiś skrypt, do którego przekierowywałbyś cały ruch, dla nie istniejących plików/katalogów. Wówczas skrypt będzie wywoływany tylko wtedy kiedy jakiś plik nie będzie istniał, tym samym mógłbyś tam wrzucić jakieś logowanie, które powiadamiało by cię o braku obrazka, czy nawet pełen automat, który by sprawdził czy faktycznie obrazka nie ma i powiedzmy usunął z konkretnego wpisu w bazie miniaturę produktu. Trochę mogłem poplątać, ale wydaje mi się takie rozwiązanie całkiem ciekawe, w efekcie czego nie będziemy się martwić o brak miniatur produktów, lub braku dostępu do miniatury produktu (skasowana, zmienione uprawnienia etc).

BTW przetrzymywanie informacji o plikach w pliku xml IMO mija się z celem. Już lepiej to trzymać w bazie, niż parsować każdorazowo wiele plików xml (np dla kategorii gdzie jest wiele produktów), lub parsowanie ogromnego pliku xml w którym byłby wszystkie adresy do obrazków. Może się wydawać ciekawe, ale według mnie takie nie jest.

PS. jeżeli za bardzo zamieszałem z tymi kategoriami, to mogę wytłumaczyć na przykładach swoją drogą chyba nawet sam skorzystam z tego pomysłu bo jest na prawdę ciekawy

[cudny]

BTW przetrzymywanie informacji o plikach w pliku xml IMO mija się z celem. Już lepiej to trzymać w bazie, niż parsować każdorazowo wiele plików xml (np dla kategorii gdzie jest wiele produktów), lub parsowanie ogromnego pliku xml w którym byłby wszystkie adresy do obrazków. Może się wydawać ciekawe, ale według mnie takie nie jest.

Niestety nie zgadzam się z tobą w żadnym wypadku !
Bazy nie relacyjne zmniejszają obciążenie serwera, a pliki XML można sobie otwierać strumieniowo więc wydajnościowo wypadają pięknie.
Nie masz tam widoków jak w mysql, że możesz sobie posortować po nazwie czy coś, ale za to kolejność dodanych danych do xml jest zachowywana, a w mysql już nie
Możesz sobie w bazie dać kolumnę kolejność ale przy zmianie jednego rekordu zmieniasz wszystkie pozostałe
Jeśli chodzi o XML, w którym przechowujesz dane dotyczące w tym wypadku obrazków to będzie to znacznie lepsze rozwiązanie niż każdorazowy request do bazy danych.
Korzystanie w każdym wypadku z mysql moim zdaniem jest ZŁEM !
Bez sensu wykorzystywać bazę do tak prostych czynności jak zapis zwykłych informacji nie powiązanych z niczym innym.
Myślisz, że aplikacje wymagające zawrotnych prędkości (powiedzmy aplikacje na androida) to z jakich baz korzystają ?
Nie jestem zwolennikiem trzymania wszystkiego w bazie danych !

Moim zdaniem to pójście na łatwiznę.

[by_ikar]

Niestety nie zgadzam się z tobą w żadnym wypadku !

Oczywiście masz do tego prawo.

Nie masz tam widoków jak w mysql, że możesz sobie posortować po nazwie czy coś, ale za to kolejność dodanych danych do xml jest zachowywana, a w mysql już nie

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.

Bazy nie relacyjne zmniejszają obciążenie serwera, a pliki XML można sobie otwierać strumieniowo więc wydajnościowo wypadają pięknie.

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.

Jeśli chodzi o XML, w którym przechowujesz dane dotyczące w tym wypadku obrazków to będzie to znacznie lepsze rozwiązanie niż każdorazowy request do bazy danych.

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.

Bez sensu wykorzystywać bazę do tak prostych czynności jak zapis zwykłych informacji nie powiązanych z niczym innym.

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.

Myślisz, że aplikacje wymagające zawrotnych prędkości (powiedzmy aplikacje na androida) to z jakich baz korzystają ?
Nie jestem zwolennikiem trzymania wszystkiego w bazie danych !

Moim zdaniem to pójście na łatwiznę.

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.

[adbacz]

Ogólnie rzecz biorąc to nie widzę sensu zaprzegać dodatkowo do tego jeszcze XML. Oczywiście możnaby, ale po co? Przy dobrym rozlokowaniu katalogów, dobrze przemyślanych nazwach katalogów i plików, czy to oryginały czy miniaturki, nie będzie trzeba dodatkowo zaprzęgać nawet bazy danych.

Załóżmy, że mamy rozkład katalogów (tutaj nazwy katalogów produktów są alfanumeryczne, w rzeczywistości będą numeryczne):

Kod

uploads/images/productcat1/155
uploads/images/productcat1/233
uploads/images/productcat2/432
uploads/images/productcat2/5553

Gdzie:
uploads = Wiadomo...
images = Wiadomo...
productcat1 = ID kategorii produktów
155, 5553, 233 = ID produktu

I w tedy wszystkie obrazki będziemy trzymać w jednym katalogu (a nie w dwóch, osobno dla miniaturek i oryg. jak pisałeś), i bedziemy ustawiać dla nich nazwy od jednego w górę, gdzie jeden, to będzie zawsze obrazek na miniaturkę i bedziemy sprawdzać tylko czy istnieje plik w katalogu i nazwie takiej:

Kod

uploads/images/product1/233/1_thumb.png

Oczywiście, może się zdarzyć też tak, że nawet katalogu produktu lub katalogu kategorii produktów nie będzie. Ale to nam nie będzie w niczym przeszkadzało podczas listowania produktów z danej kategorii. My, ścieżkę do tego katalogu będziemy sprawdzać tylko i wyłącznie jedną, bo będziemy ją sklejać na poczekaniu. Ja już mam ID kategorii produktów porobione, dlatego u mnie powstałaby ścieżka jedna, dla jednego produktu, i w tedy tylko funkcją file_exists() bym sprawdzał czy obrazek istnieje.

Wg mnie, dużo więcej obciążałoby serwer odpytywanie katalogu i sprawdzanie czy sa pliki, i jeśli są to je wylistować i wyświetlić w produkcie, niż listy kategorii.

A jeśli nie będzie danego katalogu, to co za problem dopisać prostą funkcję, która nam ten katalog docelowy stworzy podczas dodawania zdjęcia? Nie widze w tym nic trudnego, katalog produktów to nie będzie tylko i wyłącznie tworzenie nowych katalogów na serwerze i upload zdjęć, więc można sobie pozwolić na takie coś.

Ten post edytował adbacz 6.12.2011, 13:00:38

[by_ikar]

W przypadku kategorii, użyjesz wówczas 40 razy file_exists, jeżeli tyle produktów wyświetlasz w danej kategorii. Moje drugie rozwiązanie właściwie nie wykorzystuje żadnego skryptu. Bo przykładowo, listujesz sobie produkty i każdy produkt ma taki kod miniaturki:

[HTML] pobierz, plaintext 
<style>
 
.produkt_thumbs { width: 50px; height: 50px; background-image: url(path/to/default_thumb.jpg); display: block; }
 
</style>
 
<div class="produkt_thumbs">
    <a href="/path/to/produkt" class="produkt_thumbs" style="background-image: url(uploads/images/product1/233/1_thumb.png);"></a>
</div>
[HTML] pobierz, plaintext 

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.

Możesz nawet dodatkowo umieścić w katalogu uploads/images skrypt, przekierować na niego cały ruch, pomijając tylko istniejące pliki/katalogi. W efekcie czego będziesz mógł sobie wykonać jakąś dodatkową akcję, możesz sobie to gdzieś logować, że brakuje miniatury, lub nawet nic nie robić, i nie męcząc apache zapychaniem logów poprzez błędne wywołania. Przykład:

htaccess umieszczony w katalogu uploads/images:

Kod

Options -Indexes

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule>

I przykładowy skrypt, który w sumie nic nie zrobi, umieszczony w katalogu uploads/images:

[PHP] pobierz, plaintext 
<?php
 
exit;
 
// lub logowanie gdzieś informacji, parsowanie url'a i zapisywanie w których produktach brakuje miniatur, 
// lub cokolwiek ci przyjdzie do głowy
[PHP] pobierz, plaintext 

Dzięki takiemu zabiegowi, masz z głowy sprawdzanie czy plik istnieje, nie musisz parsować plików xml, nie musisz pobierać tych danych z bazy, te dane nie muszą istnieć nawet w ogóle i możesz w odpowiedni sposób reagować na ich brak.

W przypadku wyświetlenia zdjęć dla konkretnego produktu:

[PHP] pobierz, plaintext 
<?php
 
$files = array();
$productImages = 'upload/images/'.$productCat.'/'.$productId.'';
 
if(is_readable($productImages))
{
    $dir = new DirectoryIterator($productImages);
 
    foreach($dir as $fileinfo)
    {
        if(!$fileinfo->isDot())
        {
            $files[] = $fileinfo->getFilename();
        }
    }
}
 
if(!empty($files))
{
    //kod html galeri
}
[PHP] pobierz, plaintext 

Lub możesz zamiast wcześniej sprawdzać poprzez is_readable, objąć directoryiterator w blok try i robić z tym co ci się podoba. Bez zbytecznych wodotrysków

[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
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 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 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
file_exists() to nie jest operacja na plikach 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


OoO jeszcze to zauważyłem

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

[by_ikar]

Co do trzymania danych w bazie, a w xml to powiedz no mi jak ładnie rozwiążesz drzewko kategorii w bazie danych
Widzę, że jeszcze nie przyszło ci pracować z XML lub nie robiłeś żadnego sklepu jeszcze.

Super że po godzinach pracy zajmujesz się wróżbiarstwem, tyle że twoja kryształowa kula, lub fusy, są trefne. Bo przyszło mi pracować, może nie tyle co tobie, ale pracować pracowałem. Chwała bogu że mamy xml, dzięki czemu możemy mieć drzewiaste kategorię w sklepie. Zaraz, czy najpopularniejsze skrypty dostępne w sieci nie trzymają tego drzewka w bazie?

i co ? żeby pobrać drzewo kategorii musisz rekurencyjnie dawać zapytanie do bazy - w rezultacie nawet kilka tysięcy zapytań w ułamku sekundy.

Możesz domniemać że nie pracowałem z xml lub pracowałem mało, w twoim przypadku jest odwrotnie, dużo pracowałeś z xml, mało lub wcale z bazą danych.

XML jest doskonałym narzędziem do szybkiego dostępu do danych.

skomentuje to tylko tak ->

Co do parsowania xml 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++

Wiem co to jest, tyle że w przypadku bazy, te dane parsuje odpalony demon, te dane możesz trzymać w pamięci ram, dzięki czemu możesz mieć mega szybki dostęp. A xml to niby jak powstaje? To wszystko musi być parsowane przecież..

Kod

file_exists() to nie jest operacja na plikach biggrin.gif to tylko sprawdza czy coś o podanej ścieżce istnieje.

Racja, to nie jest operacja na plikach, to jest operacja w bazie danych a nie sprawdza coś, tylko konkretną rzecz - plik.

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

Każde dodatkowe sprawdzenie czy plik istnieje, czy posiadasz prawa odczytu - to wszystko kosztuje nie tyle co pamięć, co czas potrzebny dla dysku na odczyt.

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

Zawsze może poczekać aż się skrypt przeładuje żeby odczytać 40 plików xml

Mam prośbę, do kogoś postronnego który mógłby użytkownikowi @cudny wytłumaczyć różnicę w koszcie pobrania danych jednym zapytaniem do bazy, a różnicę kosztu odczytania 40 plików xml i przetworzenia danych zawartych w tych plikach..

Posłuchaj, przecież tutaj nawet nie potrzeba wiedzy w danym temacie żeby odrzucić twoje rozwiązanie. 40 plików xml, to jest 40 odczytów, 40 instrukcji warunkowych sprawdzających czy plik istnieje, czy masz dostęp, oraz 40 instrukcji warunkowych sprawdzających czy w danym xml'u coś w ogóle jest. Jak ten złożony łańcuch instrukcji ma się do instrukcji tylko 40 instrukcji warunkowych, które sprawdzają czy tablica danych pobrana 1 zapytaniem z bazy, zawiera w odpowiednim rekordzie, odpowiednią wartość dla pola miniatury? xml wygląda przy takiej bazie danych wówczas jak żółw kuternoga, kiedy w tym samym czasie baza danych nawet zadyszki nie złapie kilkukrotnie okrążając zmulonego xml'a.

Nikt przy zdrowych zmysłach w skrypcie nie użyłby xml'a nawet do konfiguracji, bez uprzedniego cachowania jego zawartości. A ty tutaj namawiasz do przetworzenia 40 takich plików. Faktycznie genialne, jeżeli chce się zabić serwer.

PS. mam prośbę do ciebie @cudny, weź przygotuj jakieś demko swojego rozwiązania online, niech ten skrypt otwiera 4 plików xml, z zapisem o jakim wcześniej wspomniałeś. Wrzuć dodatkowo jakieś memory_get_usage/peag_usage i przy okazji czas wykonywania skryptu. Może podczas sprawdzania twojego rozwiązania, dojdziesz do wniosku że twój pomysł z wydajnością ma niewiele wspólnego..

Ten post edytował by_ikar 6.12.2011, 15:19:32

[cudny]

Nie pisze tu o otwieraniu 40 plików tylko trzymaniu informacji w jednym pliku - bez opisów tylko dowiązania do plików, co do mojej pracy na bd do bardzo kolego się mylisz. Pracowałem na początku tylko na bd do puki nie zrozumiałem jak działa XML.

Racja, to nie jest operacja na plikach, to jest operacja w bazie danych wink.gif a nie sprawdza coś, tylko konkretną rzecz - plik.

file_exists(); sprawdza czy ścieżka jest poprawna - a niby co ? otwiera plik ? nie ! sprawdza poprawność ścieżki.

A teraz, bardzo cię proszę - wmówisz mi, że wykonanie tysiąca zapytań rekurencyjnie do bd to najlepsza metoda generowania drzewa kategorii ?

XML jest doskonałym narzędziem do szybkiego dostępu do danych.
skomentuje to tylko tak -> smile.gif

To lepiej nie komentuj

A xml to niby jak powstaje? To wszystko musi być parsowane przecież..

Ale nie tak jak myślisz, że od razu masz 10 megowy plik w pamięci ram

I nic nie napisałem o wyższości XML nad bazami danych !
XML w przypadku szybkiego dostępu do danych, które wiesz gdzie się znajdują jest doskonały - poruszasz się już po gotowym drzewie.

A co do największych sklepów i jak one trzymają drzewa kategorii
Zauważ, że w allegro nie masz możliwości wyświetlenia całego drzewa kategorii - czemu - tutaj jednak użyję tej kryształowej kuli bo to tylko moje domniemania - ale super by było kilkadziesiąt tysięcy zapytań wykonać w ciągu ułamka sekundy :D
Co nie zmienia faktu, że do takiej ilości danych XML faktycznie się nie nada, ale to też tylko dane z kuli kryształowej bo nie wiem czy ktoś testował coś takiego, bo po co ?

Dalsza część wniosków:

Wykorzystując do trzymania danych bez potrzeby relacji i wykorzystywania widoków nadal uważam, że nie warto obciążać zbędnie bazy danych.
Wydajność aplikacji przeważnie polepsza się redukując ilość zapytań i ilość pobieranych wyników.

[by_ikar]

Nie pisze tu o otwieraniu 40 plików tylko trzymaniu informacji w jednym pliku - bez opisów tylko dowiązania do plików, co do mojej pracy na bd do bardzo kolego się mylisz. Pracowałem na początku tylko na bd do puki nie zrozumiałem jak działa XML.

Wyobrażasz sobie 1 plik, przetrzymujący informację o kilku sety fotkach? Nawet jeżeli to będzie w cache, otwieranie za każdym razem tak dużego cache i alokowanie zbędnej pamięci, jest bardzo dużym przerostem formy nad treścią.

A teraz, bardzo cię proszę - wmówisz mi, że wykonanie tysiąca zapytań rekurencyjnie do bd to najlepsza metoda generowania drzewa kategorii ?

są strony które mają dynamiczne drzewo kategorii, miejscami dość mocno zagnieżdżone (chomikuj.pl?) i gdzie trzymają dane? Wątpią aby trzymali je w xml'u. Mało jest takich szalonych ludzi, póki co zaliczasz się do tego niewielkiego kręgu.

Wykorzystując do trzymania danych bez potrzeby relacji i wykorzystywania widoków nadal uważam, że nie warto obciążać zbędnie bazy danych.

Dlatego też podałem drugi przykład, który nie dotyczy zarówno sprawdzania katalogów, plików, nie szuka danych w bazie, nie wczytuje pliku xml, właściwie jest banalnie prosty i w swojej prostocie szybki.

Zauważ, że w allegro nie masz możliwości wyświetlenia całego drzewa kategorii - czemu - tutaj jednak użyję tej kryształowej kuli bo to tylko moje domniemania - ale super by było kilkadziesiąt tysięcy zapytań wykonać w ciągu ułamka sekundy

Nie masz, bo byłby to raz że narzut wydajnościowy, a dwa to by były duże ilości danych i odebranie tych danych przez użytkownika trwało by stanowczo za długo. W przypadku xml'a wyświetlenie również całego drzewa kategorii, dało by taki sam efekt - duża ilość danych. Dodatkowo po co wyświetlać wszystkie kategorię i robić bardzo długie drzewo kategorii? Jesteś pierwsza osobą którą spotykam, która tak namiętnie, aż prawie całkowicie bezsensownie, wykorzystuje xml'a do rzeczy, do których nie powinien zostać wykorzystany ze względu na to jaki generuje narzut na wydajność.

Ten post edytował by_ikar 6.12.2011, 16:07:12

[cudny]

ehh... nie mogę się niestety zgodzić, że za przeproszeniem takie pierdółki jak trzymanie nazwy i id fotki, ba nawet kilku tysięcy fotek jest bezsensem dla pliku xml.
Zobacz, otwierasz sobie xml w dom i znajdujesz po id - dom wspiera unikalne id i sam je nadaje - dany katalog (w tym wypadku będzie to kawałek drzewka).
Po co zaprzęgać do tego bazę danych ? całe drzewo masz już gotowe do wyświetlenia - nie musisz nic parsować.
Jedziesz rekurencyjnie po gotowych danych.
Jasną rzeczą jest, że wyszukiwanie i parsowanie całego xml (wtedy trzeba zaczytać go całego do cash) jest bezsensem ale.. pobranie gotowego wyniku już nie
Ważną rzeczą jest do czego xml się wykorzystuje i jeśli jest możliwość trzymania danych, które zwrócą ci gotowe dane bez wykorzystywania bazy to ja jestem za.
Galerię tworzę sobie zawsze na xml, bo po co do tego używać bazy skoro i tak musisz potem te dane zapisać do tablicy.
xml nie zapisujesz tylko od razu wypluwasz.
A co do drzewa kategorii... Zaraz dam subskrypcje na ten temat i sprawdzę jak zachowa się wyświetlenie drzewa przy kilkudziesięciu tysiącach kategorii z bazy i z xml - nigdy tego nie testowałem bo... zawsze używałem bazy i pobierałem ajaxowo daną kategorię
Wyniki wrzucę tutaj. Zżera mnie wręcz ciekawość

Zauważ jednak to że jeśli faktycznie ktoś się porusza po tym drzewie bardzo często to ilość requestów jest spora, a w przypadku gotowego drzewka pobierasz dane raz i javascript zalatwia reszte, tym bardziej, że xml można od razu wrzucić na public i wykorzystywać usera do parsowania xml

[by_ikar]

Galerię tworzę sobie zawsze na xml, bo po co do tego używać bazy skoro i tak musisz potem te dane zapisać do tablicy.

Nie sądziłem że baza, a właściwie funkcje/obiekty które operują na tej bazie, zwracają dane w innej postaci niż tablice, lub obiekt który w większości przypadków implementuje interfejs ArrayAccess, dzięki czemu dostęp do danych jest taki sam jak w przypadku tablicy.

Po co zaprzęgać do tego bazę danych ? całe drzewo masz już gotowe do wyświetlenia - nie musisz nic parsować.

Po co? Właśnie po to że pozostałe dane i tak lecą z bazy. Dołożenie do tej bazy jakiegoś joina, to jest minimalny narzut wydajnościowy. I jest od razu pod ręką, a sama baza może nie jest aż tak funkcjonalna pod względem drzewa co xml, ale jest wystarczająca praktycznie w większości przypadków, gdzie nawet książki opisują przykłady właśnie na bazie danych - szerokim łukiem omijając mulastego xml'a.

Wrzuć wynik, zmierz go kilka razy, zarówno dla czasu wykonywania jak i użytej pamięci. I najlepiej udostępnij pliki na których pracowałeś

[thek]

Cudny: Po pierwsze, jeśli uważasz, że drzewiastej struktury nie można wrzucić do bazy i odpytywać inaczej niż rekurencyjnie to się z deczka mylisz. Co zabawniejsze... mogę ją pobrać jednym zapytaniem Jedyne utrudnienia są przy edycji (dodawanie, edycja. usuwanie) węzłów i na to trzeba kilku zapytań, ale ile razy to robisz? Zazwyczaj te operacje są tylko sporadycznie po postawieniu serwisu. Właśnie kilka dni temu to robiłem w oparciu o bazę danych. W zasadzie w chwili obecnej całą strukturę kategorii wrzucam do bazy i zapisuję w cache'u, a w razie edycji ten cache aktualizuję. Baza więc ma niemal zerowe obciążenie z tego powodu bo przez 99% czasu używam cache'u. Właściwie to dostosowałem do własnych celów jsTree, którego kod odwalił za mnie 90% roboty.
Po drugie to jeśli się bawisz już plikami xml, to chyba zdajesz sobie sprawę, jak upierdliwe jest edytowanie czy modyfikacja struktury zazwyczaj. Ja już nawet nie mówię o poszukiwaniu elementu o nieznanej do końca ścieżce. XPath to świetna rzecz, ale w porównaniu do SQL i tak wypada blado. Cokolwiek ciutkę bardziej złożonego i jest problem. Już nawet nie mówię, że poprzez pliki XML można serwer wywalić. Poczytaj o ataku "one million laught" czy preparowaniu xml o złośliwej strukturze. To są rzeczy o których się niewiele mówi, ale są równie zabójcze dla serwisów jak sql-injection.

[Niktoś]

Już nawet nie mówię, że poprzez pliki XML można serwer wywalić. Poczytaj o ataku "one million laught" czy preparowaniu xml o złośliwej strukturze. To są rzeczy o których się niewiele mówi, ale są równie zabójcze dla serwisów jak sql-injection.

Czyżby cały IIS był do bani-przecież tam cały konfig jest na xml'u.