[PHP, AJAX] Prośba o poradę

[Inco]

Wiesz co Kul, próbujesz być złośliwy, a jesteś żałosny, tak jak twój "nowatorskie" pomysł. EOT

[Kul]

czyli twierdzisz ze ten moj test to zlosliwosc?

ostatni post to byl zart, nie bylo tam nic zlosliwego (przperaszam jesli poczules sie urazony), swoja droga tak "nowatorskie" rozwiazania sa stosowane na szeroka skale od bardzo dawna i nie w skrypcikach typu katalog stron. (np. Typo3)

[slawek22]

Patrz, nawet jak mozesz dotknac testu wydajnosci na zywych danych nadal twierdzisz ze w tym przypadku like nie jest wydajniejsze

select [...] LIKE "%.474.%" LIMIT 50 czas: 0.057673931121826

select [...] page_category.c_id = 474 AND pages.p_id = page_category.p_id LIMIT 50 czas:0.038800954818726

Jakim cudem coś co się wykonuje dłużej ma lepszą wydajność? Z resztą ten test jest źle przeprowadzony, dla każdej kwerendy powinieneś powtórzyć przynajmniej kilkaset razy dla losowych danych i przy wyłączonym qcache.

Wyłącz cache lokalnie, zrób pętlę 1000x dla każdego zapytania, wylosuj losowy id przy każdej iteracji i możemy porównać wyniki.

swoja droga tak "nowatorskie" rozwiazania sa stosowane na szeroka skale od bardzo dawna i nie w skrypcikach typu katalog stron. (np. Typo3)

w skryptach forów zamiast prawdziwych parserów FSM stosowane jest takie "nowatorskie" rozwiązanie jak pseudo-parser na regexach czy strpos. Co nie znaczy, że to jest lepsze - to nawet nie znaczy, że to jest parser.

[Kul]

jak mozesz to juz sam odswiez sobie strone 1000x i zobaczysz ze w 99% przypadkow like bedzie wydajniejsze jesli mialo by byc zastosowane w katalogu do wyswietlania stron kategorii. zapytania po to generowane sa dynamicznie zebys nie mial zadnych watpliwosci

Zanim znowu cos powiesz, poczytaj o typo3.

[slawek22]

jak mozesz to juz sam odswiez sobie strone 1000x i zobaczysz ze w 99% przypadkow like bedzie wydajniejsze jesli mialo by byc zastosowane w katalogu do wyswietlania stron kategorii. zapytania po to generowane sa dynamicznie zebys nie mial zadnych watpliwosci

Czyli do mierzenia wydajności podchodzisz równie nowatorsko jak do projektowania BD

[Kul]

Można powiedzieć ze liczyłem iż student drugiego roku odkryje pewna analogie w tych wynikach

[slawek22]

Zawsze jest wolniej dla limit 50, z resztą robisz like na polu INT a nie CHAR, to jeszcze dodatkowo - co do poprawności testu i wyników.

Można powiedzieć ze liczyłem iż student drugiego roku odkryje pewna analogie w tych wynikach

Analogia nie ma tu nic do rzeczy. To, że coś się wykona szybciej jeśli to uruchomisz raz na godzinę nie znaczy, że będzie tak samo jeśli to będziesz uruchamiał 10 razy na sekundę.

[Kul]

wolniej jest jesli bys chcial wyswietlac 100 stron jednoczesnie na liscie danej kategorii (do wydaje mi sie duzo za duzo), nie wiedzialem rowniez ze w polu int zmiesciem ciag "11.567.789"

[slawek22]

Skąd mam wiedzieć co zmieściłeś w int, nawet na polu int możesz sobie zrobić like "whatever" a sądząc po "jakości" benchmarku...

Poza tym, zauważ, że do pierwszej kwerendy musisz "dosztukować" kwerendę WHERE IN i trochę kodu PHP, żeby wyciągnąć info o kategoriach druga (ta lepsza która ci się nie podoba) podaje od razu to info bo masz join (bardzo kiepsko napisany, ale jest). Więc kolejny przykład na to, że ten benchmark można o kant d*y potłuc bo te kwerendy są różne, dotyczą nawet różnej ilości tabel. W pierwszym wypadku brakuje ci "drugiej części", tzn. kwerendy wyciągającej brakujące dane i kodu PHP (to jest ten magiczny join na php o którym pisałem, coraz lepiej )

To tak samo jakbyś testował 2 karty graficzne, na jednej uruchomił kierki, na drugiej World Of Warcraft a na końcu stwierdził, że ta pierwsza jest lepsza bo w kierkach osiąga więcej FPS.

Co do samej kwerendy... nie wydaje ci się to dziwne, że wydajność spada w miarę wzrostu klauzuli limit. Właśnie dlatego, że like jest niewydajne. Dane nieposortowane i z początku łatwo wyciągnąć, porównujesz do chwili zapełnienia buforu. Potem czas rośnie, bo trzeba porównywać każdy wiersz bez użycia indeksu. W dobrze zaprojektowanej bazie masz indeks na identyfikatorze kategorii w INT i to jest operacja o takiej samej złożoności obojętnie czy wyświetlasz pierwszą czy ostatnią stronę wyników z danej kategorii. Nawet ten kiepski benchmark to pokazuje

Jeśli będziesz chciał np. wyciągnąć dane z końca listy to ten twój like może dojść do kilkudziesięciu ms lub nawet kilku sekund w przypadkach ekstremalnych, bo na początku trzeba będzie tę listę zbudować przez proste porównanie a nie korzystając z indeksów (w odróżnieniu od poprawnie skonstruowanej bazy, gdzie wydajność jest stała i wynosi w przybliżeniu tyle samo dla limit 10 i limit 1000).

Tyle odnośnie analizy wydajności. Przy większej bazie tym twoim super sposobem po prostu serwer ubijesz Jasne, że to fajnie wygląda jak się wyciągnie 10 wyników z początku listy. Tak samo super jest wyciągać 10 pierwszych wierszy z pliku. Jak już to ktoś tutaj stwierdził - lepiej pisz skrypty na plikach, bo tak do baz danych podchodzisz. 10 pierwszych wierszy wyciągniesz dużo szybciej niż to zrobi ta kwerenda z like jak je zapiszesz do 'linki.txt'

Nie zastanawiałeś się czemu np. dla pewnych kwerend like limit 10 zwraca 9-15 ms, a w miarę wzrostu limitu mniej niż 0.01.

[Kul]

Sławek, żebyś już nie miał żadnych wątpliwości - bez użycia tabeli relacyjnej, niezaleznie od wielkosci bazy, ani pozycji pobieranych wierszy, wydajniej niz w przypadku uzycia wiazanego inta, poraz ostatni i specjalnie dla Ciebie - https://like-test.home.pl/index2.php

/E

Skąd mam wiedzieć co zmieściłeś w int, nawet na polu int możesz sobie zrobić like "whatever" a sądząc po "jakości" benchmarku...

slowem znowu się pomyliłeś

Poza tym, zauważ, że do pierwszej kwerendy musisz "dosztukować" kwerendę WHERE IN i trochę kodu PHP, żeby wyciągnąć info o kategoriach druga;)

po co mi "info" o kategoriach na liscie stron w danej kategorii?

(ta lepsza która ci się nie podoba) podaje od razu to info bo masz join (bardzo kiepsko napisany, ale jest).

masz bardzo ciekawy sposób interpretacji zapytan wyswietla jedynie liste stron w danej kategorii i pod tym względem te zapytania się niczym od siebie nie roznia

Więc kolejny przykład na to, że ten benchmark można o kant d*y potłuc bo te kwerendy są różne, dotyczą nawet różnej ilości tabel.

zdecydowanie różnej ilości tabel, i o to własnie chodzi aby porównać te dwa rozwiązania, gratuluje spostrzegawczości

W pierwszym wypadku brakuje ci "drugiej części", tzn. kwerendy wyciągającej brakujące dane i kodu PHP (to jest ten magiczny join na php o którym pisałem, coraz lepiej )

powtarzasz się, jw.

Co do samej kwerendy... nie wydaje ci się to dziwne, że wydajność spada w miarę wzrostu klauzuli limit. Właśnie dlatego, że like jest niewydajne.

like jest mniej wydajne, zdecydowanie, ale nie w tym przypadku.

W dobrze zaprojektowanej bazie masz indeks na identyfikatorze kategorii w INT i to jest operacja o takiej samej złożoności obojętnie czy wyświetlasz pierwszą czy ostatnią stronę wyników z danej kategorii. Nawet ten kiepski benchmark to pokazuje

w dobrze zaprojektowanej bazie nie musisz zaprzęgać niepotrzebnych zasobow do wyciągania danych, np. 300 000 powiazan strona – kategoria, efekty masz w tescie

Jeśli będziesz chciał np. wyciągnąć dane z końca listy to ten twój like może dojść do kilkudziesięciu ms lub nawet kilku sekund w przypadkach ekstremalnych

zdecydowanie wiecej tych ekstremalnych przypadkow masz jeśli uzywasz tabeli wiążącej -> test, te kilka sekund to chyba na podstawie gwiazd wywróżyłeś

Zanim napiszesz co wiesz, spojrz na cala aplikacje, i pomysl które rozwiązanie będzie wygodniejsze, krótsze i a nawet wydajniejsze (jeśli już w przyszłości chcesz miec katalog wiekszy jak onet). Pomysl o tej dodatkowej tabeli, 300 000 - 1 000 000 rekordów, pomyśl o zasobach które musisz angażować przy zapytaniach, o zasobach ktore bedziesz zuzywal, pomyśl ile zapytań więcej będziesz musiał napisać, pomyśl o wielkości bazy danych, pomyśl o przeniesieniu katalogu na inny serwer? Pomyślałeś o tym? Pomyślałeś o tym że like mozna zoptymalizować a Twoja tabela relacyjna może się tylko rozrastać?

[slawek22]

Kategorie na fulltext to już przesada. Wyklucza to użycie jakiegokolwiek innego engine'u niż myisam, który jest może szybki, ale podatny na uszkodzenia i nie radzi sobie z utrzymaniem spójności danych.

masz bardzo ciekawy sposób interpretacji zapytan wink.gif wyswietla jedynie liste stron w danej kategorii

Jednak w katalogach czasami wyświetla się listę stron z wszystkich kategorii (albo z kilku). Posortowane. Wiesz co się dzieje przy takim zapytaniu i sortowaniu danych. Sortowanie na dysku. Z kolei inty można posortować bezpośrednio w pamięci. To zapytanie ma taką samą charakterystykę jak robienie katalogu na plikach. Niby jest ok jak wyciągasz pierwszych 10 rekordów, jednak jeśli chcesz z tym cokolwiek zrobić (posortować, podzielić na podstrony, etc.) to się zaczynają problemy nie do przeskoczenia.

w dobrze zaprojektowanej bazie nie musisz zaprzęgać niepotrzebnych zasobow do wyciągania danych, np. 300 000 powiazan strona – kategoria, efekty masz w tescie

Właśnie w dobrze zaprojektowanej bazie chodzi o to, żeby używać takich powiązań. Po to masz klucze główne, obce, constrains. Takie powiązania są bardzo szybkie (w poprawnie zaprojektowanej bazie), bo szybka obsługa tych powiązań to główne zadanie RDBMS.

To automatycznie sprawia, że dane są poprawne, tzn. nie odwołujesz się do nieistniejącej kategorii a wszelkie potrzebne dane możesz wyciągnąć zapytaniami SQL a nie jakimiś dziwnymi konstrukcjami w PHP.

Z resztą stąd się wzięła nazwa: "relacyjne bazy danych". Od relacji a nie od trzymania wszystkiego w jednej tabeli

Ten sposób jest dużo wolniejszy jak będę miał czas to umieszczę kod który to potwierdzi, nawet już nie mówię o sortowaniu pól tekstowych i o tym jak to jest mega niewydajne szczególnie przy tak kiepsko zaprojektowanej tabeli na like

[Kul]

tak zebys wiedzial, bo pewnie Ci umkneło

Moja koncepcja wyglada tak

strona > s_id, s_name, s_url, s_cid [c_id,c_id,c_id]

kategorie > c_id, c_name, c_master

kategorie i podkategorie skompresowalem do jednej tabeli, a z tabeli powiazan zrezygnowalem zeby jeszcze bardziej odchudzic projekt jako że i tak w prosty sposob moge sobie powiazac te dane.

Kategorie na fulltext to już przesada. Wyklucza to użycie jakiegokolwiek innego engine'u niż myisam, który jest może szybki, ale podatny na uszkodzenia

nie może a napewno.

Jednak w katalogach czasami wyświetla się listę stron z wszystkich kategorii (albo z kilku).

SELECT * FROM pages LIMIT 10

Wiesz co się dzieje przy takim zapytaniu i sortowaniu danych.

strzelam ze nastepuje sortowanie

To zapytanie ma taką samą charakterystykę jak robienie katalogu na plikach.

dobre :)

Niby jest ok jak wyciągasz pierwszych 10 rekordów, jednak jeśli chcesz z tym cokolwiek zrobić (posortować, podzielić na podstrony, etc.) to się zaczynają problemy nie do przeskoczenia

dla Ciebie pewnie tak

To automatycznie sprawia, że dane są poprawne, tzn. nie odwołujesz się do nieistniejącej

automatycznie nic sie nie dzieje, musisz sie odwolac jeszcze do tabeli category (czyli lacznie juz trzy)

szczególnie przy tak kiepsko zaprojektowanej tabeli na like

podziwiam Twoje umiejętności wróżbiarskie:>

widzisz Sławek, podstawowy problem polega na tym ze Ty nie wiesz o czym piszesz(juz tym bardziej nie masz wizji projektu), a Twoja wiedza jest bardzo ograniczona (jesli dla Ciebie problemem nie do przeskoczenia jest posortowanie 10 linijek odczytanych z pliku) i pewnie stad bierze sie u Ciebie tak ogromna potrzeba rozbudowy prostych zagadnien.

pozdro, tym razem naprawde juz ostatni raz.

[slawek22]

Dlatego napisałem, że myisam jest może szybki bo np. nie obsługuje row-level locking i jak uaktualniasz dane to masz W LOCK na całą tabelę, jak czytasz to masz R LOCK więc kwerendy czekają w kolejce bo albo kilka wątków czyta albo jeden pisze. Z tego powodu myisam słabo się skaluje na procesorach wielordzeniowych jeśli często zapisujesz do bazy.

SELECT * FROM pages LIMIT 10

Ty masz do wszystkiego takie "proste" podejście. Może czasem chcę wyświetlić najlepsze strony, może z wybranych kategorii, może wpisy uaktualnione ostatnio, darmowy cncat z 2000 roku to ma. Stwarzasz wrażenie, że ty byś wszystko chciał na plikach zrobić. Jakakolwiek funkcjonalność to u ciebie wybranie 10 pierwszych wierszy (i zachwyt jak to szybko działa:D). Do tego faktycznie LIKE i char najlepiej się nadaje, najlepiej jeszcze jak to 10 wierszy jest z początku bo masz full table scan

automatycznie nic sie nie dzieje, musisz sie odwolac jeszcze do tabeli category (czyli lacznie juz trzy)

innoDB ma constraints, które automatycznie dbają o spójność danych, jeśli tylko umiesz projektować tabele i wiesz co to jest. Na myisam i polu char nie da się tego zrobić, więc się nie dziwię, że o tym nie wiesz.

jesli dla Ciebie problemem nie do przeskoczenia jest posortowanie 10 linijek odczytanych z pliku

Myślałem, że chcesz pisać katalog, który może mieć więcej niż kilkadziesiąt k wpisów. Jeśli nie to faktycznie - pomijając sensowność przedsięwzięcia - jakąkolwiek strukturę bazy byś zastosował - będzie ok

Z resztą znasz jakiś skrypt katalogu z kategoriami na like?