Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Zasady pisania na forum Pro

Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.

2 Stron V  < 1 2  
Reply to this topicStart new topic
> Profilowanie aplikacji
Krolik
post 3.10.2007, 11:52:58
Post #21





Grupa: Zarejestrowani
Postów: 53
Pomógł: 0
Dołączył: 16.11.2004

Ostrzeżenie: (0%)
-----


Właśnie - bardzo często problemem jest wydajność bazy danych, nie samego PHP.
Wydajność bazy można poprawić na co najmniej 2 sposoby:
1. dobrze indeksować dane (większość programistów ma z tym problemy)
2. buforować dane w pamięci

Odnośnie punktu 1 - co byście powiedzieli, gdyby istniało narzędzie, które automatycznie dobiera właściwe indeksy
na podstawie logu zapytań? Istnieje takie coś w Oracle i DB/2, a co gdyby było też coś opensource, np. dla MySQL?
A może takie coś istnieje, ale nie znalazłem?


--------------------
Projekty: PLAY, optymalizator baz danych
Go to the top of the page
+Quote Post
NuLL
post 3.10.2007, 12:04:13
Post #22





Grupa: Zarejestrowani
Postów: 2 262
Pomógł: 21
Dołączył: 3.05.2004
Skąd: Sopot, Krakow, W-wa

Ostrzeżenie: (0%)
-----


Krolik - mowisz o wybieraniu sposobu indeksownia typu B-Tree itp ? W MySQLu moze byc problem z czyms takim gdyz np MyISAM obsluguje tylko B-Tree wiec duzego wyboru nie ma.


--------------------
Javascript, Coffeescript, Node.js, Mongo, CouchDb, chmury, workery & inne bajery - zycie jest zbyt krotkie aby miec nudna prace :)
Go to the top of the page
+Quote Post
Krolik
post 3.10.2007, 12:34:11
Post #23





Grupa: Zarejestrowani
Postów: 53
Pomógł: 0
Dołączył: 16.11.2004

Ostrzeżenie: (0%)
-----


Nie, mam na myśli generalnie dobór indeksów a nie tylko typu. Zauważ, że indeksy można zakładać na różnych tabelach i różnych kolumnach. W praktyce liczba możliwości nawet w niewielkiej bazie jest przeogromna, a większość ludzi robi to "na czuja", wcale nie podpierając tego fachowa wiedzą.


--------------------
Projekty: PLAY, optymalizator baz danych
Go to the top of the page
+Quote Post
zimi
post 3.10.2007, 20:51:55
Post #24





Grupa: Zarejestrowani
Postów: 233
Pomógł: 9
Dołączył: 3.06.2007

Ostrzeżenie: (0%)
-----


nie bardzo to widzę...
musiałaby to być złożona klasa która jest klasą abstrakcji bazy...
i musiałaby manipulować zapytaniami bo z tego co wiem jeżeli mamy założony jakiś indeks na kilku kolumnach to liczy się kolejność ich wymienienia w zapytaniu w klauzuli WHERE
wprowadzenie zatem ich w jednym zapytaniu w pewnej kolejności a w drugim odwrotnie... zmuszałoby klasę do tworzenia innego indeksu albo manipulowania zapytaniem... to raczej będzie prowadziło do wielu trudnych do wykrycia błędów
zasadniczo to języki programowania są zrobione po to aby człowiek myślał i kazał wykonywać coś komputerowi
optymalizacja jest zajęciem typowym dla fachowców to człowiek musi wymyślić którędy będzie najlepiej... komputer nie wymyśli algorytmów
pisać klasy pomocnicze powinno się robić raczej do przyspieszenia rozwoju aplikacji, zmniejszajać ilość powtarzalnych czynności
tworzenie różnorodnych indeksów w celu maksymalnego wykorzystania zasobów jest raczej pracą twórczą niż odtwórczą...
Go to the top of the page
+Quote Post
Krolik
post 4.10.2007, 10:53:07
Post #25





Grupa: Zarejestrowani
Postów: 53
Pomógł: 0
Dołączył: 16.11.2004

Ostrzeżenie: (0%)
-----


Zimi, nie pytałem, czy to się da zrobić, tylko czy coś takiego byłoby potrzebne. Sądząc po tym, co napisałeś o optymalizacji zapytań - utwierdza mnie w przekonaniu, że jest potrzebne.

Mianowicie mijasz się z prawdą twierdząc, że indeksowanie wymaga zmiany zapytań. Kolejność w WHERE może być dowolna i nie ma nic do kolejności indeksów. Systemy RDBMS, nawet te najbardziej prymitywne, traktują WHERE jako ZBIÓR warunków i kolejność występowania warunków połaczonych ANDem czy ORem nie ma znaczenia (te opreratory sa przemienne). Jedynie ma znaczenie kolejność kolumn w indeksach wielokolumnowych, ale to indeksy dobiera się do zapytań, a nie na odwrót.

Odnośnie tego, że musiała by być to złożona klasa abstrakcji: i tak i nie. To że złożona, to jest oczywiste, problem prosty nie jest. Nikt nie mówił że ma być łatwo. Tyle, że to raczej cały system a nie pojedyncza klasa. No i wcale nie musi być to coś pomiędzy aplikacją PHP a bazą danych. Wystarczy osobny program, który ma dostęp do bazy danych i logów zapytań (w MySQL można go włączyć). Taki demon wspomagający pracę admina bazy. BTW: raczej nie wyobrażam sobie implementowania tego w PHP, ze względu na zbyt niską wydajność, tylko raczej w C++ lub Javie, ale to sprawa drugorzędna i dla użytkowników nie mająca większego znaczenia.

Cytat
optymalizacja jest zajęciem typowym dla fachowców

Hehe, a kompilatory to myślałeś że co robią? A optymalizatory zapytań w RDBMS? W serwerowni siedzi człowiek i każde zapytanie SELECT ręcznie optymalizuje?

Cytat
komputer nie wymyśli algorytmów

Wymyśli - złe słowo, ale dobierze i sparametryzuje - zdecydowanie TAK.

Cytat
tworzenie różnorodnych indeksów w celu maksymalnego wykorzystania zasobów jest raczej pracą twórczą niż odtwórczą

Słyszałeś o uczeniu maszynowym? AI?


--------------------
Projekty: PLAY, optymalizator baz danych
Go to the top of the page
+Quote Post
athabus
post 4.10.2007, 12:57:06
Post #26





Grupa: Zarejestrowani
Postów: 896
Pomógł: 45
Dołączył: 2.11.2005
Skąd: Poznań

Ostrzeżenie: (0%)
-----


Jak dla mnie sam pomysł aplikacji jest bardzo dobry. Sam mam raczej małą wiedzę o działaniu baz danych i indeksy dobieram "zdroworozsądkowo" - bardzo fajnie byłoby aby jakiś program zrobiła analizę co gdzie i jak umieścić. Plus tego taki, że programista nie zawsze ma dobre rozeznanie co i jak jest obciążone w bazie - może mieć inną wizję a logi pokażą co innego. Dla przykładu używając ORM'ów czasami można się zdziwić zapytaniami jakie są generowane. Oczywiście można powiedzieć dobry programista kontroluje wszystko i wie jak działa jego system, ale z ręką na sercu ilu z was przegląda wszystko dokładnie od a do z.

Program nie ma żadnych "przekonań" na początku i całą analizę oparłby na logach.

Dla początkujących i średnio zaawansowanych narzędzie wydaje mi się bardzo dobre, a i dla zaawansowanych pewnie przedstawiałoby jakąś wartość może nie jako "decydent" a bardziej jako "doradca".
Go to the top of the page
+Quote Post
zimi
post 4.10.2007, 22:38:40
Post #27





Grupa: Zarejestrowani
Postów: 233
Pomógł: 9
Dołączył: 3.06.2007

Ostrzeżenie: (0%)
-----


Cytat
Jedynie ma znaczenie kolejność kolumn w indeksach wielokolumnowych, ale to indeksy dobiera się do zapytań, a nie na odwrót.

nie mam wiedzy absolutnej na temat optymalizacji zapytań... co więcej jest ona dość nikła, dopiero wydrukowałem sobie z manuala MySQL co ciekawego napisali o optymalizacji i będę sobie to powoli przyswajał
więc teraz aby się upewnić czy się rozumiemy
załóżmy że mamy indeks na 3 polach w kolejności a, b, c
a następnie zapytanie:
Kod
SELECT (...) WHERE a="1" AND b="2" AND c="3"

i wtedy nasz indeks będzie działał, i teraz drugie zapytanie:
Kod
SELECT (...) WHERE b="2" AND c="3" AND a="1"

i tutaj nasz indeks już nic nie da...
jeśli mam rację to:
Cytat
Mianowicie mijasz się z prawdą twierdząc, że indeksowanie wymaga zmiany zapytań.

jednak wymaga to zmiany zapytania gdyż jedynie o ten przypadek mi chodziło... i sytuacje w której niczego nieświadomy użytkownik pomyli sobie kolejność kolumn albo nawet nie będzie wiedział że to ma znaczenie i zrobi odwrotnie "bo tak"
Cytat
ale to indeksy dobiera się do zapytań, a nie na odwrót

w tym momencie Twój projekt staje się jedynie rozwiązaniem połowicznym... gdyż projekt robisz jak rozumiem docelowo dla amatorów którzy nie mają pojęcia o indeksacji i ogólnie optymalizacji zapytań... jeśli tak to indeksy wielokolumnowe niewątpliwie stoją już na wyższym poziomie, a generalnie idea powinna być "trudne uprościć" a nie "łatwe uprościć"(to ew. przy okazji), przy jednokolumnowych indeksach (przy ich tworzeniu) to na dobrą sprawę "widzę że przez to polę wyszukuję często dane" => "robię indeks" (no ew. jeszcze kilka reguł, ale ta w sumie najprostsza), nie ma w tym zbyt wielkiej filozofii, a przynajmniej ja (zaznaczam że mam braki w tej dziedzinie, jak się wymądrzam to przepraszam i poprawcie mnie) nie widzę w tym większej filozofii, choć przydatnym narzędziem będą logi zapytań, ile czasu zajmuje zapytanie, tudzież stosunek czasu do ilości rekordów w tabeli bądź inne statystyki i analiza zapytania na poziomie abstrakcji bazy aby z klauzul WHERE, ORDER BY, GROUP BY, HAVING i chyba jeszcze jakiś wydobywał nazwy kolumn i weryfikował czy na danym polu jest indeks czy nie, oczywiście niekoniecznie w momencie wykonywania każdego zapytania

poza tym niezależnie od indeksów wielokolumnowych podejrzewam że optymalizacja może mieć również związek z kolejnością w klauzuli WHERE, gdyż prawdopodobnie (choć może i nie) zachodzi tam "skracanie" warunku (nie pamiętam czy miało to jakąś fachową nazwę, a jeśli tak to jaką...), a czytanie warunku zachodzi z tego co wiem od lewej do prawej
chodzi o to że jeśli będziemy mieli np.
Kod
SELECT ... WHERE 1=0 AND (inne warunki)

1=0 oczywiście nie ma być docelowym warunkiem, chodzi mi o to że programista przy pisaniu kodu ma świadomość, że coś często będzie fałszem lub prawdą i to wstawia na "pierwsze pozycje"
serwer SQL prawdopodobnie wiersz odpuści już po pierwszym warunku 1=0 gdyż z góry będzie fałszywy bezwzględu jakie wartości przybiorą kolejne zdania logiczne
natomiast gdy zamienimy kolejność:
Kod
SELECT ... WHERE (inne warunki) AND 1=0

serwer może sporo danych przewertować, stracić dużo zasobów a i tak w końcu wyjdzie że dany wiersz nas nie interesuję...
w tego typu przypadkach Twoja klasa/funkcja/program/cokolwiek nie będzie miało już wiele do gadania bo są to dość skomplikowane zagadnienia zresztą to była tylko taka dygresja o znaczeniu kolejności
no ale w sumie chyba wszystko można zaprogramować smile.gif
Cytat
A optymalizatory zapytań w RDBMS?

szczerze mówiąc nie wiem, a nawet nie wiedziałem o ich istnieniu choć ich istnienie wydaję się być zrozumiałe... nie mniej podejrzewam że mają minimalne znaczenie dla efektywności zapytań, podobnie jak w kodach PHP, podobno Zend Optimizer zamienia $d++ na ++$d bo jest szybsze (nie wiem czy to prawda, tak gdzieś przeczytałem... mało ważne) jednak znaczenie takiej optymalizacji przy skopanym algrotymie jest tak nikłe że nawet niewarto o nim wspominać
Cytat
Słyszałeś o uczeniu maszynowym? AI?

tak słyszałem, choć nie mam chwilowo pojęcia w jaki sposób działa (nie próbowałem się nawet nad tym bardziej zastanawiać), nie douczałem się w tej materii...
nie mniej gdy o tym wspomniałeś odbieram wrażenie że to przerost formy nad treścią...
i znacznie lepiej dla każdego kto potrzebuję optymalizacji będzie przeczytanie kilku stron o tym zagadnieniu niż skorzystaniu z takiej aplikacji, przynajmniej chwilowo taka moja opinia

Cytat
Plus tego taki, że programista nie zawsze ma dobre rozeznanie co i jak jest obciążone w bazie

a więc potrzebujesz logów a niekoniecznie takiej aplikacji, a resztę robisz dalej "zdroworozsądkowo", a taka aplikacja może się zacząć "wymądrzać" co różne programy mają do siebie... co zaczyna być działaniem szkodliwym
Go to the top of the page
+Quote Post
Krolik
post 5.10.2007, 10:25:32
Post #28





Grupa: Zarejestrowani
Postów: 53
Pomógł: 0
Dołączył: 16.11.2004

Ostrzeżenie: (0%)
-----


Cytat(zimi @ 4.10.2007, 21:38:40 ) *
załóżmy że mamy indeks na 3 polach w kolejności a, b, c
a następnie zapytanie:
Kod
SELECT (...) WHERE a="1" AND b="2" AND c="3"

i wtedy nasz indeks będzie działał, i teraz drugie zapytanie:
Kod
SELECT (...) WHERE b="2" AND c="3" AND a="1"

i tutaj nasz indeks już nic nie da...


Jeśli tak rzeczywiście jest w MySQL, to gratuluję jego twórcom lamerstwa biggrin.gif
To, że są słabi w te klocki, to wiedziałem, ale żeby aż tak, to się trzeba mocno wysilić.
Dlatego niezbyt Ci wierzę Ci i jeszcze to sprawdzę. W normalnym systemie oba zapytania użyją indeksu - nie ma żadnego przeciwskazania, żeby tak nie było.

Cytat
abstrakcji bazy aby z klauzul WHERE, ORDER BY, GROUP BY, HAVING i chyba jeszcze jakiś wydobywał nazwy kolumn i weryfikował czy na danym polu jest indeks czy nie, oczywiście niekoniecznie w momencie wykonywania każdego zapytania

Przy tym podejściu miałbyś 5 razy tyle indeksów co potrzeba. Czyli rozmiar bazy większy i niepotrzebnie spowolniony update/insert.

Dalszej części postu komentował nie będę tylko polecę Ci lekturę porządnej książki o optymalizacji zapytań, konstrukcji RDBMS np. z serii Klasyka informatyki "Implementacja systemów baz danych". Mam nieodparte wrażenie, że Twoja wiedza na ten temat kłada się głównie z tego "jak myślisz, że RDBMS działa" a nie jak jest zrobiony w rzeczywistości. Poza tym wzorowanie się w tym zakresie na MySQL to zły pomysł.

Cytat
tak słyszałem, choć nie mam chwilowo pojęcia w jaki sposób działa (nie próbowałem się nawet nad tym bardziej zastanawiać), nie douczałem się w tej materii...


Widać.

Cytat
nie mniej gdy o tym wspomniałeś odbieram wrażenie że to przerost formy nad treścią...
i znacznie lepiej dla każdego kto potrzebuję optymalizacji będzie przeczytanie kilku stron o tym zagadnieniu niż skorzystaniu z takiej aplikacji, przynajmniej chwilowo taka moja opinia
a więc potrzebujesz logów a niekoniecznie takiej aplikacji, a resztę robisz dalej "zdroworozsądkowo", a taka aplikacja może się zacząć "wymądrzać" co różne programy mają do siebie... co zaczyna być działaniem szkodliwym


Ok, przyjąłem tę opinię do wiadomości.

Dodam, że optymalizacja pewnej niewielkiej bazy danych (raptem 30 tabel) u nas w firmie zajęła metodą "analizy logów i EXPLAIN" jednemu wykwalifikowanemu adminowi 4 dni. Może i mało, ale należy pamiętać,że taką optymalizację robi się co jakiś czas, bo aplikacja / dane się zmieniają i że to była raptem jedna mała baza danych. A co gdybyśmy byli firmą hostingową i hostowali 100 aplikacji? Myślisz, że ktoś miałby czas bawić się i sprawdzać, czy jakiś lamer nie walnął selecta bez indeksu, który jedzie po tabeli na milion rekordów? Ten program nie ma być lepszy od wykwalifikowanego DBA, ale ma przede wszystkim zaoszczędzić czas. Podłączasz do bazy danych, wskazujesz log, klikasz jeden guzik i za 5 minut masz zestaw "prawie" optymalnych indeksów.

I jeszcze takie małe, łatwe pytanie kontrolne. Jakie indeksy są najlepsze w tym przypadku:

SELECT nazwa_produktu, cena, opis FROM produkty WHERE cena < 5000 AND miasto = 'Krakow' ORDER BY cena LIMIT 10;

W bazie są produkty o cenach od 10 do 10000, z całego kraju. To jest klasyczne pytanie na jakie musi odpowiedzieć każdy DBA. Odpowiedź trzeba uzasadnić.


--------------------
Projekty: PLAY, optymalizator baz danych
Go to the top of the page
+Quote Post
NuLL
post 6.10.2007, 02:03:55
Post #29





Grupa: Zarejestrowani
Postów: 2 262
Pomógł: 21
Dołączył: 3.05.2004
Skąd: Sopot, Krakow, W-wa

Ostrzeżenie: (0%)
-----


Krolik to pytanie dotyczy Postgres-a czy MySQLa ?

Miasta raczej bym trzymal w osobnej tabeli bo porownywanie stringow nie nalezy do najszybszych z tego co wiem. Gdyby mialo byc tak jak mowisz to na miasto nie oplacalo by sie zakladac indeksu jakoze dane powtarzaby sie. Krolik - dla MySQLa twoje pytanie nie ma sensu pozatym winksmiley.jpg Bo i tak tylko zwykly index mozna zalozyc. Primay i unique odpada no chyba ze sie myle ? Co do Postgres-a moja wiedza jest obecnie niewielka tak wiec nie bede nic pisal winksmiley.jpg Ale chetnie poslucham co w trawie piszczy smile.gif

Do do tego indeksowania po 3 polach. MySQL do wersji 5.0 korzysta tylko z jednego indeksu na danej tabeli w zapytaniu niestety tongue.gif Od wersji 5.0 dokonal sie postep. Aby wykorzystac indeksowanie na 3 polach czasem lepiej bylo tworzyc zapytanie korzystajac z UNION winksmiley.jpg


--------------------
Javascript, Coffeescript, Node.js, Mongo, CouchDb, chmury, workery & inne bajery - zycie jest zbyt krotkie aby miec nudna prace :)
Go to the top of the page
+Quote Post
Krolik
post 6.10.2007, 09:37:05
Post #30





Grupa: Zarejestrowani
Postów: 53
Pomógł: 0
Dołączył: 16.11.2004

Ostrzeżenie: (0%)
-----


Pytanie dotyczy dowolnego RDBMS. I nie chodzi mi tylko o jaki typ indeksu (w MySQL jest tylko B+ drzewo), ale na których (której) kolumnie. Są co najmniej 4 możliwości: tylko na cenie, tylko na mieście, 2 osobne indeksy na cenie i mieście, jeden 2-kolumnowy indeks (cena, miasto). I jeszcze zerowa możliwość: brak indeksu.

Cytat
Gdyby mialo byc tak jak mowisz to na miasto nie oplacalo by sie zakladac indeksu jakoze dane powtarzaby sie


Powtarzanie się danych nie jest przeciwwskazaniem dla indeksu, o ile nie jest UNIQUE. Przeciwsskazaniem może być natomiast zbyt mała selektywność warunków (czyli np. gdy się zbyt wiele powtarza) - w MyISAM niestety nie ma indeksów sklastrowanych, więc wtedy często skan sekwencyjny bywa lepszy niż użycie indeksu.

Indeksy wielokolumnowe są obsługiwane w wersji zarówno 4 jak i 5 MySQL. Tylko zauważ różnicę: użycie JEDNEGO wielokolumnowego indeksu, a użycie DWÓCH różnych indeksów. MySQL 5 potrafi użyć 2 różnych indeksów i dokonać unii (jeśli był warunek OR) albo przecięcia (dla AND) - tego MySQL 4 nie potrafił.


--------------------
Projekty: PLAY, optymalizator baz danych
Go to the top of the page
+Quote Post
SongoQ
post 15.10.2007, 17:53:02
Post #31





Grupa: Przyjaciele php.pl
Postów: 2 923
Pomógł: 9
Dołączył: 25.10.2004
Skąd: Rzeszów - studia / Warszawa - praca

Ostrzeżenie: (0%)
-----


Padła informacja o sposobie dobierania indeksow i porownie do ORACLE. Wiec tak to odbywa sie w nastepujacy sposob, juz pomijajac sam fakt prepare i weryfikacji obiektow bazy danych. Optymalizator wylicza sobie najlpesza metode polaczenia zapytania i tytaj nie wchodzi w gre tylko i wylacznie dobor indeksow ale rowniez kolejnosc tabel w from, jakie pola beda brane pod uwage co kiedy ma robic, liczba obliczeniami zajmuje sie optymalizator w bazie ORACLE jest to od 10g kilka zmian doszlo w 11. Co do MySQLa czy PG no to wiadomo. Ogolnie wiekszosc baz wykorzystuje optymalizator regulowy.

@Krolik pisales o wilu indeksach i roznym wykorzystaniu przez MySQL5. Nieraz tak jest nieraz nie, widac to po EXPLAIN. Optymalizator to tylko zbior regul ktore ma wykonywac i na podstawie indeksow i innych obiektow podejmowac decyzje jak dane sa wyciagane. Nie wiem jak to jest z MySQLem do konca ale w takich przypadkach powinny być HINTy dla optylamizatora takie wskazówki w komentarzu jak sie ma zachować.


--------------------
Go to the top of the page
+Quote Post
DeyV
post 22.10.2007, 23:20:46
Post #32





Grupa: Zarząd
Postów: 2 277
Pomógł: 6
Dołączył: 27.12.2002
Skąd: Wołów/Wrocław




@Krolik - dobre pytanie.
Niby takie proste, a jednak musiałem aż sprawdzić, by się upewnić, jak to powinno wyglądać.

I niestety - już tu widać, że co baza to zwyczaj.

MySQL i PG zachowują się pod tym względem bowiem nieco inaczej.

W każdym z przypadków najwięcej sensu ma oczywiście index miasto, które to pole będzie zawierać najmniejszą ilość unikalnych danych. Dzięki temu też wyszukanie rekordów spełniających określonych warunek będzie bardzo szybkie.

Niestety - cena jest znacznie bliższa wartości losowej, stąd też tworzenie na niej indexu w przypadku takiego zapytania nie ma zbyt wielkiej wartości, gdyż jego przeszukanie jest równoznaczne z przeszukaniem wszystkich pól w bazie, z chyba właśnie z tego powodu obie bazy nie będą chciały z niego korzystać.

Co ciekawe - w przypadku PG sens może mieć index miasto_cena, który (w przypadku mojej testowej bazy - 100 tys rekordów) o połowę przyśpieszył to zapytanie (niż tylko index miasto). MySql nie potrafił skorzystać z takiego indexu w tym zapytaniu.
Trzeba pamiętać jednak o tym, że będzie to naprawdę potężny index.

ps. Czy naprawdę sądzisz, że automat analizujący logi jest w stanie rozwiązać takie problem za mnie?

pps. Swoją drogą - jakiś mechanizm do analizy logów bazy tworzy depesz ( depesz.com )


--------------------
"Niezależnie od tego, jakie masz osiągnięcia, ktoś Ci pomaga..."
Go to the top of the page
+Quote Post
Krolik
post 31.10.2007, 12:58:11
Post #33





Grupa: Zarejestrowani
Postów: 53
Pomógł: 0
Dołączył: 16.11.2004

Ostrzeżenie: (0%)
-----


Pytanie było specjalnie takie, żeby nie było jednoznacznej odpowiedzi. Słabsze systemy najprawdopodobniej wybiorą mniejsze zło, tj. tak jak napisał DevV:

LIMIT (1, 10)
|
+ SORT (cena)
|
+ INDEX_SCAN (miasto = 'Krakow' AND cena < 5000) <-- indeks na (miasto, cena)


Albo tak (nieco gorzej):


LIMIT (1, 10)
|
+ SORT (cena)
|
+ FILTER (cena < 5000)
|
+ INDEX_SCAN (miasto = 'Krakow') <--- indeks tylko na (miasto)


Wszystko zależy trochę od rozkładu wartości w bazie, ale można się spodziewać, że ponieważ Kraków jest dużym miastem,
to warunek miasto = Kraków ma słabą selektywność (załóżmy 20%), podobnie warunek na cenę też ma b. słabą selektywność (ok. 50%, jeśli rozkład jest równomierny). W tej sytuacji najlepszy byłby indeks klastrujący na cena, żeby uniknąć sortowania:

LIMIT(1, 10)
|
+ FILTER (miasto = 'Krakow')
|
INDEX SCAN (cena < 5000) <--- indeks tylko na (cena)

Niezależnie od sumarycznej liczby rekordów ten plan wymaga odczytania średnio raptem ok. 50 rekordów tabeli, ze względu na możliwość wykonania iteracyjnego i LIMIT, podczas gdy poprzednie plany czytają odpowiednio 10% * liczba_rekordów (pierwszy) i 20% * liczba_rekordów (drugi) i oba sortują 10% rekordów całej tabeli. Pewnie DB/2 lub Oracle potrafiłoby znaleźć ten plan bez hintów, ale muszę sprawdzić. Jeśli optymalizator nie zauważy, że można wyeliminować sortowanie oraz że można przerwać skanowanie po osiągnięciu 10 rekordów wyniku, ten plan automatycznie staje się prawie najgorszym z możliwych.

To tyle omówienia zadania. Zadanie miało na celu tylko zilustrowanie, że problem wprawdzie prosty nie jest i rozwiązanie mocno zależny od jakości optymalizatora bazy danych, to nie jest wcale żadną tajemnicą, co potrafią robić różne optymalizatory i program może to uwzględniać. Wydaje mi się, że nawet w niektórych przypadkach może to zrobić lepiej niż człowiek - kto z Was zna szczegóły działania optymalizatora MySQL czy PostgreSQL? Raczej stosuje się metodę "prób i błędów" a nie podejście naukowe. Podobnie program bez trudu potrafi oszacować selektywność warunków i zrobić podobną analizę, którą przedstawiłem przy okazji zadania.

BTW. Istnieje taki projekt dla DB/2 i działa nieźle. Dla MySQLa byłoby dużo prosciej, bo on potrafi zdecydowanie mniej (ma regułowy optymalizator -> łatwo się go przewiduje). Ponadto nie zalezy mi na tym, by ten program dawał zawsze najlepszy możliwy wynik, ale żeby raczej stanowił pomoc w "zgrubnym" dobraniu większości indeksów, w bardzo krótkim czasie.


--------------------
Projekty: PLAY, optymalizator baz danych
Go to the top of the page
+Quote Post

2 Stron V  < 1 2
Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 6.12.2019 - 06:18