Ile zapytań SQL to dużo Opcje

[athabus]

Hej - na początku zaznaczę, że nie jestem zawodowym programistom, a raczej takim amatorej-hobbystom, który czasami wykorzystuje php do pracy zawodowej (siedzę w e-commerce, więc czasami przydają się takie umiętności do napisania jakichś rozwiązań automatyzujących pracę czy generujące różne treści pod seo itp).

Obecnie wdrażamy nowy sklep i jestem mocno zaskoczony ilością zapytań jakie takie skrypty generują do bazy danych. Pomijam już fakt, że firma, która nam wdraża obecnie skrypt zrobiła jakiś master fackup, to jednak przyjrzałem się gołemu skryptowi (Prestashop), który np. mając 10 produktów w koszyku i odświeżeniu potrafi wygenerować +250 zapytań. Oczywiście wiem z czego to wynika - takie skryptu muszą być maksymalnie elastyczne i przez to wszystko przechowują w bazach danych od statusów po wersje językowe, ale jednak rodzi się pytanie ile to jest racjonalna ilość zapytań.
Mam w swojej historii taki skrypt sklepu napisany jeszcze w Symfony 1.0, na którym działa w miarę duży jak na polskie warunki sklep i analogiczna strona wywołuje 6-10 zapytań - fakt było to rozwiązanie w 100% dedykowane, bo w tamtych czasach nie było jeszcze dobrych platform sklepowych, więc większość tabel atomowych ze statusami itp. siedzi w cachu pliku konfiguracyjnego itd.

Teraz pytanie czy te ilości zapytań w produktach OpenSource (np. Magento, Prestashop czy nawet Wordpress) to jest niechlujna architektura / brak optymalizacji czy po prostu dzisiejsze (rozbudowane) skrypty tak mają, bo stawia się na elastyczność kosztem optymalizacji?

[Crozin]

Nie da się odpowiedzieć na to pytanie. Chyba, że "to zależy" Cię satysfakcjonuje. Nie mniej jednak 250+ wydaje się być faktycznie dużą liczbą zapytań. Przede wszystkim sprawdź czy nie dochodzi tam do jakiejś formy 1 + n SELECT queries. Jednak bez zobaczenia tych zapytań, wiedzy n/t tego co mają one zwrócić i po co nie da się odpowiedzieć pełniej.

PS. Zapytania SQL są policzalne, czyli... "liczba", nie "ilość".

[athabus]

Temat raczej z kategorii ogólnych - obiecałem sobie jak najmniej zaglądać pod maskę bo w końcu po to zlecam, żeby tego nie robić sam.
W gołej preście sprawa jest dość oczywista - po prostu działa to na zasadzie ordynarnego ActiveRecord bez żadnej optymalizacji na zasadzie np.
-> select produkt
->select nazwa produktu z bazy tłumaczeń where id = 1
->select status produktu from tlumaczenia statusow
-> select dostepna ilosc from ilosci

i tak w pętelce dla każdego produktu, który np. jest w koszyku.

W moim przypadku akurat problem jest głębszy, bo chłopakom z 250 zapytań zrobiło się 1000 ;-) Ja mniej więcej wiem dlaczego, bo widać to w profilerze Presty (prawdopodobnie koszyk jest kilka razy przeliczany - albo im się gdzieś powieliło odwołanie, albo jakiś moduł to robi), ale dokładnego błędu nie będę za nich szukał. Te zapytania rzędu 250 nie są dla mnie większym problemem, bo i tak muszę działać na dedyku, a te kilka tysięcy osób, które przewija się dziennie przez sklep to dla dedyka nie jest specjalne obciążenie. Temat jak piszę z kategorii ogólnej - nie chodzi mi tu o naprawienie konkretnego błędu.

Bardziej chodzi mi o to, czy to teraz taki standard programistyczny w aplikacjach OS (dla szerokiego grona) aby była maksymalna elastyczność kosztem braku optymalizacji czy też nie. W Wordpresie widać np. podobny schemat. Dodasz kilka dodatków i niby prosty skrypt blogowy potrafi wygenerować całkiem spore obciążenie.

[viking]

To raczej nie szerszy problem tylko brak wiedzy albo chęci do optymalizacji. Po co nad tym siedzieć, wymyślać, zakładać indeksy, może jakieś procedury napisać jak można wrzucić do pętli selecta na 1000 produktów i niech leci. A widziałem już sklepy który generowały ponad 5 tyś zapytań (i chodziły jak kupa na dedyku ale to szczegół). I owszem, czasami może się zdarzyć że automatyczne tworzenie kwerend da taki efekt ale wtedy trzeba przysiąść i pomyśleć co z tym zrobić żeby było lepiej.

[prz3kus]

To raczej nie szerszy problem tylko brak wiedzy albo chęci do optymalizacji. Po co nad tym siedzieć, wymyślać, zakładać indeksy, może jakieś procedury napisać jak można wrzucić do pętli selecta na 1000 produktów i niech leci. A widziałem już sklepy który generowały ponad 5 tyś zapytań (i chodziły jak kupa na dedyku ale to szczegół). I owszem, czasami może się zdarzyć że automatyczne tworzenie kwerend da taki efekt ale wtedy trzeba przysiąść i pomyśleć co z tym zrobić żeby było lepiej.

Wszytstko spoko, jenak mi się zdaje, że poczęści odkąd programiści stsują bibliotek do obsługi bazy typu Doctrine, Propel leniwość w pisaniu generuje znacznie więcej zapytań. W końcu po co pisac jedno zapytanie natywnie skoro możemy napisac trzy zapyta obiektowo i sie mniej babramy

[Pyton_000]

Tak, też się zacząłem ostatnio zastanawiać nad zasadnością używania ORM do mniej prostych zapytań.

[destroyerr]

Wszytstko spoko, jenak mi się zdaje, że poczęści odkąd programiści stsują bibliotek do obsługi bazy typu Doctrine, Propel leniwość w pisaniu generuje znacznie więcej zapytań. W końcu po co pisac jedno zapytanie natywnie skoro możemy napisac trzy zapyta obiektowo i sie mniej babramy biggrin.gif

Można zapisać trzy zapytania bez ORMa i jedno zapytanie z ORMem, albo programista zwraca uwagę na liczbę zapytań i w razie potrzeby zmniejsza, albo tego nie robi. Z ORMem czy bez nie ma to znaczenia.

[Tomplus]

Ja jestem z tych którzy zwraca uwagę na ilość zapytań, szczególnie że często mam do czynienia z projektami robionymi na hostingach, a te przy większym ruchu powinny mieć jak najmniej zapytań z bazą danych.

Zwracam uwagę, ale szczerze mówiąc, nigdy ich nie liczyłem. Dzisiaj przy projekcie sklepu który działa od 3 lat, sprawdziłem ilość zapytań i okazuje się że jest od 9-18 zapytań, zależności od czynności na stronie.

Co do Presto, Wordpress i w ogóle OpenSource (i nie tylko) to myślę że kwestią jest to że takie projekty mają wielu twórców i każdy element jest osobnym narzędziem które nie jest nieodzowne gdy inne się wyłączy lub usunie. Każdy element układanki łączy się z bazą i w ten sposób nie koliduje z innymi, mimo że następny element korzysta z tych samych danych.

[robertpiaty]

Przy ORMach trzeba pamiętać też o takim zjawisku jak "leniwe dociąganie danych". Wystarczy że pobieramy 1000 rekordów i w pętli przy ich wyświetlaniu zrobimy leniwe pobranie danych i mamy dodatkowych 1000 zapytań Warto też sprawdzić jakie ORM generuje zapytanie. Czasami trzeba wymusić żeby to było jedno zapytanie (mam tu na myśli Yii1 i together http://www.yiiframework.com/doc/guide/1.1/...base.arr#sec-3)

[athabus]

Tak ORM na pewno się przykładają do tego problemu. Dla przykładu Doctrine, czasami potrafi niezbyt intuicyjnie zadziałać z przypadku niektórych relacji i np. pobierać dodatkowe obiekty bez potrzeby - twórcy Doctrine wyjaśniali dlaczego tka się dzieje i jak unikać itp., ale jednak sam się na to kiedyś naciąłem.
Obecnie piszę projekt który korzysta ze sporej liczby relacji w bazie (w sumie nic aż taki wielkiego, tylko relacje dosyć złożone i zagnieżdżone) i w ORM czasami trzeba się trochę nagimnastykować, żeby trywialna rzecz nie powodowała 50 zapytań - ale z drugiej strony jest to tylko kwestia nakładu pracy i chęci wgryzienia się w temat i da się różnymi mechanizmami liczbę zapytań ograniczyć. Z drugiej strony przyznam, że ostatnio sam się trochę w tej kwestii wyluzowałem i jak dana akcja w całokształcie generuje te kikadziesiąt zapytań z czego np połowa w to jakieś proste selecty w pętli, który nie obciążają zbytnio zasobów, to sobie odpuszczam, bo szkoda mi godziny czasu na rzeźbienie. Co innego gdy te zapytania zaczynają się realnie przekładać na obciążenie. No ale ja piszę zazwyczaj aplikacje wewnętrzne, albo pod relatywnie mały ruch więc mogę sobie na takie niedbalstwo pozwolić.

W gotowych rozwiązaniach niestety coraz częściej łatwo się wkopać w niezłą kupę i np. doinstalować niepozorną wtyczkę od WP, która w połączeniu z większą bazą artykułów potrafi nieźle dać się serwerowi we znaki, a autor nawet się nie zająknie w opisie o tej kwestii. Może po prostu to wynika z tego, że do programowania wchodzi młode pokolenie, które wychowało się na smartfonach o mocy obliczeniowej większej niż serwery hostingowe kiedyś ;-) Jednak jak ja zaczynałem naukę PHP to zasoby były droższe i bardziej się je szanowało. Teraz większym kosztem jest dodatkowy dzień pracy programisty niż roczny koszt utrzymania przyzwoitego vps zamiast hostingu współdzielonego.