🚀 go-pugleaf

On Saturday, December 12, 2015 at 10:01:33 PM UTC+1, szemrany wrote:
> On Sat, 12 Dec 2015 10:52:51 -0800 (PST), M.M. wrote:
> 
> >>> mechanizmu niż indeksy, to inne rozwiązanie też będzie zabójcze.
> >>> Wyszukiwanie przez index hash jest bardzo szybkie, więc inne rozwiązania
> >>> będą szybsze maksymalnie 3-4 razy i to tylko na silnikach które mają
> >>> coś lepszego niż indeksy.
> >> 
> >> Inne rozwiązania będą szybsze setki razy :-)
> > Analiza jest skomplikowana. Na czas zapytania składa się kilka czynników:
> > 1) Transfer danych
> > 2) Parsowanie zapytania
> > 3) Optymalizowanie i sposób wykonania.
> > 4) Dostępy do danych w buforze ram
> > 5) Dostępy do danych na dysku
> > 6) Odczyty danych z dysku.
> 
> Ok, ok, ale... to wszystko bez znaczenia, bo występuje w każdym wypadku.
Nie nie. Masz dwa zapytania. Jedno 'zwykłe' drugie 'zoptymalizowane' 
Odpalasz na jednym sprzęcie: zoptymalizowane działa 10 razy szybciej. Na
drugim sprzęcie: zoptymalizowane działa 3 razy szybciej. Sprzęt ma
duży wpływ na to 'ile razy będzie szybciej'.


> Pisząc o "innych rozwiązaniach" miałem na myśli inaczej zbudowany SQL
> (select), 
Tak właśnie zrozumiałem.


> niż to co pokazałeś. Bo albo ja nie rozumiem co masz na myśli,
> albo Ty nie rozumiesz jak serwer tego typu zapytanie wykonuje.
Trochę rozumiem, trochę się domyślam... Szczegółów na pewno
nie rozumiem. Warto rozumieć szczegóły? Jeśli masz ochotę, 
chętnie zobaczę Twoje zapytanie vs moje i uzasadnienie dlaczego
Twoje nie zabije serwera. Może warto się czegoś nauczyć, ale
póki co, dla mnie baza sql to czarna skrzynka, która ma
dobrze działać.



> > Jeden dysk (SSD) ma 100tys dostępów na sekundę, drugi tylko 100. Każda
> > strategia na każdym dysku da inne przyspieszenie.
> 
> Mówimy cały czas o jednym i niezmiennym środowisku, porównywanie wydajności
> rozwiązania na różnym hardware jest bezcelowe i bezowocne.
Ja z kolei zmierzałem do tego, że bezcelowe jest mówienie o przyspieszeniu
np. 100-krotnym, bez uwzględnienia sprzętu :)



> > Spójrzmy skrótowo. Dostęp do danych zaindeksowanych wymaga 3-4 odczytow z
> > dysku. Dostęp optymalny wymaga jednego odczytu. Czyli teoretycznie można
> > przyspieszyć nie więcej niż 3-4 razy. A jeśli optymalizator opracuje
> > tak kosztowny plan wykonania że faktycznie można przyspieszyć setki
> > razy, to mi ręce opadają i używam innego rozwiązania.
> 
> Chodziło o zwykłe:
> 
> select L.imie, L.Nazwisko, count(z.id) as liczba_samochodow from Ludzie L
> join zasoby z on z.id_1 = L.id
> join samochody s on s.id = z.id_2 
> group by L.imie, L.nazwisko
>  
> Tylko dzięki takiej budowie zapytania (w przeciwieństwie do Twojego)
> zyskujesz potwornie na wydajności. 
Tak myślałem że to masz na myśli, nie mam bladego pojęcia, jakie jest
uzasadnienie, że Twoja wersja zyskuje potwornie na wydajności. Powiem
więcej, w pewnym momencie wyrzuciłem z pamięci swoje doświadczenia z
optymalizacji zapytań, bo mialem sprzeczne wyniki testów, albo wyniki
były bardzo wrażliwe na ilość danych i architekturę bazy. Uznałem że
lepiej bazę traktować jako czarną skrzynkę.


> No wiesz, nie wszystko się da jednak zoptymalizować. Programista też musi
> myśleć. Doczytałem, że Oracle coś tam umie keszować przy zapytaniu tego
> typu jaki zaprezentowałeś (nazywają to scalar subquery), ale warunkiem jest
> powtarzalność rekordów z tabeli bazowej (tu: Ludzie), a to nie zawsze jest
> spełniony warunek (tu nie jest).
Cóż, nie rozumiem za wiele z tego. W każdej bazie ustawia się pamięć na
bufor. Ba, każdy system plików może być buforowany przez system operacyjny. Ba,
każdy dysk może mieć swój bufor, a i kontroler dysku może mieć swój bufor.
Piszesz o jakimś jednym buforze w jednej konkretnej bazie - ja nie wiem
dlaczego warto się tym zainteresować. 

Pozdrawiam