Dlaczego bazy danych są nieefektywne?

Koziołek napisał(a):

Po co wdawać się z tobą w dyskusje, skoro już pierwszy post pozwala dość dokładnie ocenić jej przebieg... #filozoraptor

Mamy dwa samochody. Jeden osiąga maksymalną prędkość 100km/h drugi 50km/h. Koniecznie trzeba zrobić wyścig, aby wiedzieć który wygra?
Przecież mniej/więcej wiadomo jak ma się do siebie wydajność języków kompilowanych/interpretowanych.

Koziołek napisał(a):

Skoro zapytanie na tzw. pełnej bazie danych, trwa kilka sekund, to w pierwszej kolejności sprawdza się samo zapytanie. Plan zapytania jest tylko ogólną wskazówką co do tego jak może być ono wykonane. Następnie sprawdza się czy baza nie ma włączonych jakiś dziwnych konfiguracji w rodzaju logowania pewnych zapytań, zapisywania średnich czasów wyszukiwania, czy zapisywania dostępów do rekordów.

Baza testowa była utworzona na tym samym pliku konfiguracyjnym i na niej zapytanie trwa 1-2ms.

Koziołek napisał(a):

I najważniejsze nie porównuje się czasu działania zapytania z czasem testu napisanego ad hoc, ponieważ test wykonuje tylko niewielki ułamek tego co robi silnik bazy danych w czasie procesowania zapytania.

A właśnie ten program był najbardziej przydatny, bo dzięki niemu wiedziałem że jest spowolnienie 100tys razy i że coś wymaga ponownego przemyślenia. Bez tego programu bym do tej pory myślał że tak długi czas wykonania tego zapytania jest normalny.

Duży Terrorysta napisał(a):

Pewnego razu brałem udział w szczególnym spotkaniu projektowym. Kierownik zespołu opisał problem, zrobiliśmy burzę mózgów i przedstawiliśmy swoje propozycje rozwiązań.
Przyszła kolej na takiego starego inżyniera, który podał swoje uniwersalne rozwiązanie: "To jest źle zrobione, i trzeba to tak zrobić, żeby było dobrze."

Jakie z tego wnioski i jak to się ma do własnej implementacji transakcji?

artur_bredzki napisał(a):

Właśnie dlatego pytałem, na jakim sprzęcie to działało i jak to było zrównoleglane. Czy baza dała radę, czy przerzucono trud na programistów.

Ale ciągle baza danych musiała obsłużyć ileśtam (dużo) zapytań. Zakładam, że tam była jedna jej instancja - tak jak np. u mnie gdzie jest jedna baza danych per system core'owy (w szczycie po 60-80 GB logów na godzinę, w tygodniu spokojnie jeden TB się wykręci).

wartek01 napisał(a):

artur_bredzki napisał(a):

Właśnie dlatego pytałem, na jakim sprzęcie to działało i jak to było zrównoleglane. Czy baza dała radę, czy przerzucono trud na programistów.

Ale ciągle baza danych musiała obsłużyć ileśtam (dużo) zapytań. Zakładam, że tam była jedna jej instancja - tak jak np. u mnie gdzie jest jedna baza danych per system core'owy (w szczycie po 60-80 GB logów na godzinę, w tygodniu spokojnie jeden TB się wykręci).

Może tak było. Jeśli faktycznie była jedna instalacja bazy na jednym mocny komputerze, a nie klastrze, to chwała bazie że sobie poradziła.

artur_bredzki napisał(a):

Mamy dwa samochody. Jeden osiąga maksymalną prędkość 100km/h drugi 50km/h. Koniecznie trzeba zrobić wyścig, aby wiedzieć który wygra?

Jako miłośnik wyścigów samochodowych aspirujący do uzyskania licencji wyścigowej powiem, że warto, bo na torach z krótkimi prostymi może okazać, że ten z mniejszym vmaxem wygra, w wyścigach vmax ma znaczenie na torach z długimi prostymi, a na technicznych już się liczy przyczepność oraz przyspieszenie tak uogólniając. Także ten mogę ci o tym napisać esej, chcesz? :)

mr_jaro napisał(a):

artur_bredzki napisał(a):

Mamy dwa samochody. Jeden osiąga maksymalną prędkość 100km/h drugi 50km/h. Koniecznie trzeba zrobić wyścig, aby wiedzieć który wygra?

Jako miłośnik wyścigów samochodowych aspirujący do uzyskania licencji wyścigowej powiem, że warto, bo na torach z krótkimi prostymi może okazać, że ten z mniejszym vmaxem wygra, w wyścigach vmax ma znaczenie na torach z długimi prostymi, a na technicznych już się liczy przyczepność oraz przyspieszenie tak uogólniając. Także ten mogę ci o tym napisać esej, chcesz? :)

Wiedziałem że tak odpiszesz :)

artur_bredzki napisał(a):

Nie wiem jakiego systemu dotyczy pytanie. Czy chodzi o tę hipotetyczną specjalistyczną bazę danych jaką bym chciał napisać i zastąpic bazę transakcyjną?

Jeśli pytanie dotyczy takiej bazy, to generalnie z tego typu oprogramowaniem są ogromne problemy, problemy pojawiają się nie tylko przy grupowaniu i transakcjach. Większość problemów da się lepiej lub gorzej rozwiązać. Rozwiązania wymagają dużego nakładu pracy programistycznej. Transakcje projektuje się oddzielnie dla każdego systemu, często perfekcyjne wykonanie transakcji jest w ogole niemożliwe, stosuje się jakieś protezy, albo dopuszcza się jakieś minimalne błędy w danych. Wszystko zależy od systemu, ponieważ w każdym systemie inne operacje na bazie są objęte transakcją. Jesli podasz przykład operacji wymagającej transakcji, to możemy zastanowić się nad rozwiązaniem.

Tak chodzi mi o tę hipotetyczną bazę jaką byś chciał napisać, bo w sumie najbardziej interesuje mnie jakie mechanizmy wdrożyłbyś żeby dane dopisywały się w sposób kontrolowany, to samo z modyfikacją oraz usuwaniem. Mało tego, co z relacyjnością? I jakie problemy masz na myśli z grupowaniem i transakcjami, proszę o przykłady. :-)

artur_bredzki napisał(a):

Tak chodzi mi o tę hipotetyczną bazę jaką byś chciał napisać, bo w sumie najbardziej interesuje mnie jakie mechanizmy wdrożyłbyś żeby dane dopisywały się w sposób kontrolowany, to samo z modyfikacją oraz usuwaniem. Mało tego, co z relacyjnością? I jakie problemy masz na myśli z grupowaniem i transakcjami, proszę o przykłady. :-)

To jest dobry temat na calą książkę :)

artur_bredzki napisał(a):

Duży Terrorysta napisał(a):

Pewnego razu brałem udział w szczególnym spotkaniu projektowym. Kierownik zespołu opisał problem, zrobiliśmy burzę mózgów i przedstawiliśmy swoje propozycje rozwiązań.
Przyszła kolej na takiego starego inżyniera, który podał swoje uniwersalne rozwiązanie: "To jest źle zrobione, i trzeba to tak zrobić, żeby było dobrze."

Jakie z tego wnioski i jak to się ma do własnej implementacji transakcji?

Nie obraź się, ale czytam te Twoje posty i odnoszę wrażenie, że próbujesz wyważać otwarte drzwi.
To jest tak: "Czym rozpalacie ognisko? Zapałkami? Zapalniczką? Pfffff, co za dziwne sposoby... ja mam najlepszy sposób - pocieram dwa suche patyki."
I to tyle, więcej nie mam zamiaru prowadzić dyskusji, bo to jakbym się z koniem kopał.
Są na świecie osoby, które robią sobie pod górkę i nie powinno mnie to w ogóle interesować.
Powodzenia.

Duży Terrorysta napisał(a):

artur_bredzki napisał(a):

Duży Terrorysta napisał(a):

Pewnego razu brałem udział w szczególnym spotkaniu projektowym. Kierownik zespołu opisał problem, zrobiliśmy burzę mózgów i przedstawiliśmy swoje propozycje rozwiązań.
Przyszła kolej na takiego starego inżyniera, który podał swoje uniwersalne rozwiązanie: "To jest źle zrobione, i trzeba to tak zrobić, żeby było dobrze."

Jakie z tego wnioski i jak to się ma do własnej implementacji transakcji?

Nie obraź się, ale czytam te Twoje posty i odnoszę wrażenie, że próbujesz wyważać otwarte drzwi.
To jest tak: "Czym rozpalacie ognisko? Zapałkami? Zapalniczką? Pfffff, co za dziwne sposoby... ja mam najlepszy sposób - pocieram dwa suche patyki."
I to tyle, więcej nie mam zamiaru prowadzić dyskusji, bo to jakbym się z koniem kopał.
Są na świecie osoby, które robią sobie pod górkę i nie powinno mnie to w ogóle interesować.
Powodzenia.

No i pewnie w 95% przypadków to jest racja, że robienie szybszej bazy mija się z celem. Jednak pozostaje jeszcze te 5%.

Mamy dwa samochody. Jeden osiąga maksymalną prędkość 100km/h drugi 50km/h. Koniecznie trzeba zrobić wyścig, aby wiedzieć który wygra?
Przecież mniej/więcej wiadomo jak ma się do siebie wydajność języków kompilowanych/interpretowanych.

To pokazuje jak bardzo nie rozumiesz o czym piszesz w kontekście testów.

Baza testowa była utworzona na tym samym pliku konfiguracyjnym i na niej zapytanie trwa 1-2ms.

Sprzęt taki sam? W tym samym DC? Obie instancje tak samo skonfigurowane na poziomie sysopu?

A właśnie ten program był najbardziej przydatny, bo dzięki niemu wiedziałem że jest spowolnienie 100tys razy i że coś wymaga ponownego przemyślenia. Bez tego programu bym do tej pory myślał że tak długi czas wykonania tego zapytania jest normalny.

Tyle tylko, że twój program nie wykonuje nawet dziesiątej części zadań jakie wykonuje RDBMS w trakcie procesowania zapytania. I nie mówię tu o translacji SQL na jakiś wewnętrzny język zapytań, czy też o wyznaczeniu planu zapytania. Twój program nie zapewnia współbieżnego przetwarzania danych, nie zapewnia kontroli dostępu (w postgresie można skonfigurować per rekord) ani bezpieczeństwa, nie zapewnia spójności danych, nie zapewnia logowania historii operacji... mam dalej wymieniać?

Twój program działa szybciej ponieważ ma żałośnie małą funkcjonalność w porównaniu z nawet prosta bazą danych.

Koziołek napisał(a):

Mamy dwa samochody. Jeden osiąga maksymalną prędkość 100km/h drugi 50km/h. Koniecznie trzeba zrobić wyścig, aby wiedzieć który wygra?
Przecież mniej/więcej wiadomo jak ma się do siebie wydajność języków kompilowanych/interpretowanych.

To pokazuje jak bardzo nie rozumiesz o czym piszesz w kontekście testów.
ponieważ...

Baza testowa była utworzona na tym samym pliku konfiguracyjnym i na niej zapytanie trwa 1-2ms.

Sprzęt taki sam? W tym samym DC? Obie instancje tak samo skonfigurowane na poziomie sysopu?

Ten sam komputer, ta sama instalcja systemu, ta sama instalacja postgresa. Plik tworzący testową bazę danych utworzony przez usunięcie większości zbędnych tabel i kolumn w teście. Ten sam dysk, ten sam system plików, ta sama patrycja, ten sam czas z dokładnością do jednej doby.
W bazie testowje jest mniej pól i mniej tabel, właściwie to w bazie testowej jest tylko jedna tabela.

A właśnie ten program był najbardziej przydatny, bo dzięki niemu wiedziałem że jest spowolnienie 100tys razy i że coś wymaga ponownego przemyślenia. Bez tego programu bym do tej pory myślał że tak długi czas wykonania tego zapytania jest normalny.

Tyle tylko, że twój program nie wykonuje nawet dziesiątej części zadań jakie wykonuje RDBMS w trakcie procesowania zapytania. I nie mówię tu o translacji SQL na jakiś wewnętrzny język zapytań, czy też o wyznaczeniu planu zapytania. Twój program nie zapewnia współbieżnego przetwarzania danych, nie zapewnia kontroli dostępu (w postgresie można skonfigurować per rekord) ani bezpieczeństwa, nie zapewnia spójności danych, nie zapewnia logowania historii operacji... mam dalej wymieniać?
Twój program działa szybciej ponieważ ma żałośnie małą funkcjonalność w porównaniu z nawet prosta bazą danych.

Piszesz, jakbym tym programem chciał zastąpić całego postgresa, albo twierdził że on dorównuje postgresowi pod względem funkcjonalności :)

Ten program był celowo minimalistyczny, żeby był jakiś odnośnik do porównania.

Ponieważ

Ano ponieważ:

Bolid Ferrari z sezonu 2015 V_max ~300km/h

Dodge Charger STR V_max ~326km/h

Lamborghini Hurracan V_max ~340km/h

Dlaczego w bezpośrednim starciu na torze wygrywa najwolniejszy samochód?

W bazie testowje jest mniej pól i mniej tabel, właściwie to w bazie testowej jest tylko jedna tabela.

Czyli jednak nie to samo. Podpowiem środowisko testowe powinno być identyczne ze środowiskiem produkcyjnym. Inaczej można otrzymać zupełnie niemiarodajne wyniki.

Piszesz, jakbym tym programem chciał zastąpić całego postgresa, albo twierdził że on dorównuje postgresowi pod względem funkcjonalności :)

Ten program był celowo minimalistyczny, żeby był jakiś odnośnik do porównania.

Tyle tylko, że odnośnik jest nieprawidłowy. Porównujesz dwie zupełnie różne rzeczy. Twój program, który jest obcięty z funkcjonalności z programem, który ma pełną funkcjonalność. Jak chcesz mieć prawidłowe porównanie, to przeprowadź test dla zbliżonych, najlepiej identycznych, funkcjonalności. Mówiąc wprost metodologia twoich testów jest zła.

Może dodam jeszcze parę słów. Mam jakąś bazę danych i zapytanie. Wysyłam zapytanie do bazy, mierzę czas. Co mogę zrobić dalej? Mogę przy pomocy narzędzi i opcji bazy danych ten czas poprawić. W momencie gdy już nic nie pomaga, co można zrobić jeszcze? Mogę wierzyć że baza danych działa szybko lub wolno, albo mogę napisać właśnie taki minimalistyczny program i porównać czasy. Gdy zauważę, że baza danych działa 10 razy wolniej, to myślę sobie, baza osiąga bardzo dobry wynik. Gdy widzę że baza działa 30, a nawet 100 razy wolniej, to myślę, że nie jest najgorzej. Ale gdy widzę że baza działa 1000 razy wolniej, to zapala mi się czerwone światełko i myślę, że pomimo ogromu rzeczy jakie baza musi dodatkowo zrobić, coś jest nie tak z bazą, albo że próbuję bazie zlecić zadanie do którego się ona nie nadaje.

Powtórzę: żeby nie ten głupi-śmieszny programik, to bym myślał, że 6s na zapytanie które przewala 20mln rekordów, to dobry rezultat, bo baza wykorzystuje indeksy, bo to porządna baza, itd. Zatem proszę, nie tłumacz mi, że baza robi coś więcej niż ten programik, bo nie porównuje się jeden do jeden. Jeśli baza osiąga czas 30 razy dłuższy, to już można uznać, że baza działa bardzo dobrze. Dopiero gdy jest powyżej 1000 to można się zastanwiać jak coś ulepszyć.

bo nie porównuje się jeden do jeden.

I to chyba jest najlepsze podsumowanie tego „porównania”. Równie dobrze można porównywać trąbkę do pomidora. Porównujesz dwie zupełnie inne rzeczy i dziwisz się, że otrzymujesz takie, a nie inne wyniki. Właśnie na tym polega błąd w metodologii. Takie porównanie nie ma sensu.

Testujesz na zbyt małym zadaniu. Baza danych choćby przez to, że obsługuje wielu użytkowników komunikuje się po TCP. Działa też jako osobny proces. Napisz ten swój program w wersji klient-serwer i zobacz co się stanie. Na samym dwukrotnym przyłączeniu kontekstu między procesami stracisz kilkaset mikrosekund. Podobnie przejście komunikatu przez stos sieciowy w jądrze też zajmuje trochę. To są wszystko czasy rzędy wielkości większe niż dostęp do cache procesora.

Poza tym nie wolno oceniać szybkości bazy po samym opóźnieniu. To że zapytanie trwa 1 ms nie oznacza, że baza pozwala tylko na 1000 zapytań na sekundę. Zwykle bazy pozwalają na dużą równoległość dostępu. Dorzuć do swojego kodu możliwość operowania na strukturze danych przez wiele wątków i dostaniesz kolejne spowolnienie.

Innymi słowy porównujesz bolid F1 z kontenerowcem. Twój bolid wygra wyścig w specyficznych, sztucznych warunkach, tj. na torze. Natomiast kontenerowcem przewieziesz więcej w tym samym czasie, mimo że ma znacznie mniejszą prędkość i nie opłaca się go stosować do przewożenia jednej malutkiej paczki.

Spróbuj użyć bazy danych w pamięci: https://www.sqlite.org/inmemorydb.html
Odpadnie czas na komunikowanie się po socketach, na operacje dyskowe, itd

Wibowit napisał(a):

Spróbuj użyć bazy danych w pamięci: https://www.sqlite.org/inmemorydb.html
Odpadnie czas na komunikowanie się po socketach, na operacje dyskowe, itd

SQLite w ogóle mnie intryguje. Jest bazą o mniejszej funkcjonalności, więc powinien być bardziej wydajny.

@artur_bredzki bzdura, chyba że pomijamy tutaj kwestie skomplikowanych struktur danych, algorytmów i optymalizacji kosztowych siedzących w bazach enterprise ;]

Czy na serio tylko ja i @wloochacz widzimy ze jakakolwiek dyskusja z autorem wątku jest całkowicie bezsensowna? @Koziołek jasno napisał ze jego metodologia jest zła, w komentarzu dostał info "Nie, nie jest zła". Co to za dyskusja w ogóle i dlaczego jeszcze nie leży w off-topic'u?

artur_bredzki napisał(a):

Może dodam jeszcze parę słów. Mam jakąś bazę danych i zapytanie. Wysyłam zapytanie do bazy, mierzę czas. Co mogę zrobić dalej? Mogę przy pomocy narzędzi i opcji bazy danych ten czas poprawić. W momencie gdy już nic nie pomaga, co można zrobić jeszcze? Mogę wierzyć że baza danych działa szybko lub wolno, albo mogę napisać właśnie taki minimalistyczny program i porównać czasy. Gdy zauważę, że baza danych działa 10 razy wolniej, to myślę sobie, baza osiąga bardzo dobry wynik. Gdy widzę że baza działa 30, a nawet 100 razy wolniej, to myślę, że nie jest najgorzej. Ale gdy widzę że baza działa 1000 razy wolniej, to zapala mi się czerwone światełko i myślę, że pomimo ogromu rzeczy jakie baza musi dodatkowo zrobić, coś jest nie tak z bazą, albo że próbuję bazie zlecić zadanie do którego się ona nie nadaje.

Najpierw zastanów się co porównujesz. Ja spojrzałem na http://4programmers.net/Forum/1275173 z http://4programmers.net/Forum/1275261 i z szybkich oględzin wyszły mi takie różnice:

• w pg masz id jako bigint, a nie int,
• w pg masz dodatkowe pola w tabeli których nie ma w c++,
• w pg sortujesz po id (order by id),
• w pg masz dodatkowy warunek na id, którego nie ma w c++,
• w pg masz inną kolejność warunków (najpierw sprawdzanie =, potem sprawdznie in),
• przede wszystkim, w pg robisz select * from zamiast select sum(val) from - a więc na podstawie danych w tabeli tworzysz efektywnie nową tabelę z wierszami z podstawowej, zamiast po prostu policzyć jedną wartość,

artur_bredzki napisał(a):

SQLite w ogóle mnie intryguje. Jest bazą o mniejszej funkcjonalności, więc powinien być bardziej wydajny.

Jakiej funkcjonalności ci brakuje?

\timing on
-- jaki jest narzut czasowy na najprostsze zapytanie? Nie traci czasu na jakieś logi?
select id from testabc limit 1;  -- tutaj powinien się połączyć ( u mnie czasy od 0.2ms do 0.5ms )

Czas przetwarzania trywialnego zapytania nie ma raczej nic wspólnego z czasem przetwarzania jakiegoś nietrywialnego, jak już słusznie poprzedni koledzy zauważyli. Zrób sobie symulację dla różnych rozmiarów danych i zobaczy jak rośnie czas względem rozmiaru danych.

Wątek może jest głupi, ale potwierdza tylko moją obserwację, że większość ludzi nie umie robić benchmarków. Tzn. ludzie często mierzą A, a następnie konkludują, że zmierzyli B, a następnie wyciągają daleko idące wnioski typu "Baza X jest zawsze szybsza od Y". A najczęściej nie da się stwierdzić wprost, że jedna baza jest szybsza od drugiej, bo to zależy od zbyt wielkiej liczby czynników.

Np. czy MySQL jest szybszy od Postgresa? Jeśli wyłączysz transakcje, to zapewne w niektórych przypadkach będzie szybszy. Jeśli zmierzysz czas nawiązywania połączenia, to znowu - może się okazać, że będzie mniejszy. Przy prostym zapytaniu też może być szybszy, bo optymalizator jest bardzo prymitywny i niewiele robi, a do prostego zapytania raczej trudno o beznadziejny plan, więc znowu MySQL może wygrać. Ale jeśli wrzucisz rozbudowane zapytanie ze złączeniami i podzapytaniami na dużej ilości danych, to na 99% Postgres zmiażdży MySQLa, bo ma dużo lepszy planner zapytań.

Tu jeszcze trochę informacji jak nie robić benchmarków. To pasuje nie tylko do Cassandry:
http://www.datastax.com/dev/blog/how-not-to-benchmark-cassandra

Wibowit napisał(a):

artur_bredzki napisał(a):

Może dodam jeszcze parę słów. Mam jakąś bazę danych i zapytanie. Wysyłam zapytanie do bazy, mierzę czas. Co mogę zrobić dalej? Mogę przy pomocy narzędzi i opcji bazy danych ten czas poprawić. W momencie gdy już nic nie pomaga, co można zrobić jeszcze? Mogę wierzyć że baza danych działa szybko lub wolno, albo mogę napisać właśnie taki minimalistyczny program i porównać czasy. Gdy zauważę, że baza danych działa 10 razy wolniej, to myślę sobie, baza osiąga bardzo dobry wynik. Gdy widzę że baza działa 30, a nawet 100 razy wolniej, to myślę, że nie jest najgorzej. Ale gdy widzę że baza działa 1000 razy wolniej, to zapala mi się czerwone światełko i myślę, że pomimo ogromu rzeczy jakie baza musi dodatkowo zrobić, coś jest nie tak z bazą, albo że próbuję bazie zlecić zadanie do którego się ona nie nadaje.

Najpierw zastanów się co porównujesz. Ja spojrzałem na http://4programmers.net/Forum/1275173 z http://4programmers.net/Forum/1275261 i z szybkich oględzin wyszły mi takie różnice:

• w pg masz id jako bigint, a nie int,
• w pg masz dodatkowe pola w tabeli których nie ma w c++,
• w pg sortujesz po id (order by id),
• w pg masz dodatkowy warunek na id, którego nie ma w c++,
• w pg masz inną kolejność warunków (najpierw sprawdzanie =, potem sprawdznie in),
• przede wszystkim, w pg robisz select * from zamiast select sum(val) from - a więc na podstawie danych w tabeli tworzysz efektywnie nową tabelę z wierszami z podstawowej, zamiast po prostu policzyć jedną wartość,

Opisałem już wcześniej co w związku z tym wszystkim.

• w pg masz id jako bigint, a nie int,
  Różnica pomijalnie mała w zrgubnych testach, a na komputerze 64 bitowym może bigint nawet szybciej działać.
• w pg masz dodatkowe pola w tabeli których nie ma w c++,
  Tak mam, ale istnieje pewien rodzaj optymalizacji w wyniku której ilość kolumn na które nie jest założony żaden warunek nie powinna rzutować na czas zapytania. Słyszałem że ten rodzaj optymalizacji jest w postgresie zaimplementowany. Było też kilka postów o tym, co się dzieje z wydajnością gdy dochodzą inne kolumny które nie są uwzględniane w warunkach zapytania.
• w pg sortujesz po id (order by id),
  Pierwszy warunek przechodzi jeden rekord na N, drugi jeden na M, trzeci jeden na K. Średnio sortowaniem objęty jest jeden rekord na NxMxK. Więc czas sortowania to jakieś log 10 * (1 / NMK) * ilość wierszy - pomijalnie mały w zgrubnym teście.
• w pg masz dodatkowy warunek na id, którego nie ma w c++,
  Dochodzi do tego warunku z prawdopodobieństwem 1 / (NMK) - czas pomijalnie mały w zgrubnym teście.
• w pg masz inną kolejność warunków (najpierw sprawdzanie =, potem sprawdznie in),
  Czas pomijalnie mały, ponieważ każdy warunek odrzuca bardzo dużo rekordów. Poza tym słyszałem, że bazy same potrafią zmienić kolejność warunków, tak aby zacząć od warunku który odrzuca najwięcej rekordów.
• przede wszystkim, w pg robisz select * from zamiast select sum(val) from - a więc na podstawie danych w tabeli tworzysz efektywnie..
  Przede wszystkim w postgresie mam indeksy, a w programie ich brak. Jak już pisałem, program został napisany tak, aby jego napisanie zajęło mało czasu i jednocześnie aby na jego podstawie dało się oszacować czas zapytania z sub-optymalnymi indeksami. Program nie ma na celu odtworzenia algorytmu który wykonuje baza danych z dokładnością jeden do jeden - czemu to nie jest oczywiste?! Program wykonuje pewną operację na 20mln rekordów metodą fullscan. Drobiazgi zostały pominęte. Ta operacja zajmuje określoną ilość czasu. Z tego czasu z kolei można oszacować ile czasu trwałoby takie zapytaneie gdyby program miał indeksy. Jako że baza ma potencjalnie większą funkcjonalność, oszacowany czas należy jeszcze pomnożyć przez jakąś stałą wartość. Dopiero wtedy porównywanie ma sens i do takiego porównywania powstał ten program. Jeśli myslisz, że chcę porównywać jeden do jeden, to masz mnie za idoitę.

artur_bredzki napisał(a):

SQLite w ogóle mnie intryguje. Jest bazą o mniejszej funkcjonalności, więc powinien być bardziej wydajny.

Jakiej funkcjonalności ci brakuje?

Gdzie, co, jak, kiedy? Wątek z SQLite padł na marginesie, nie używam go nawet, nic mi nie brakuje. Generalnie jest bazą o mniejszej funkcjonalności, więc powinien być szybszy.

\timing on
-- jaki jest narzut czasowy na najprostsze zapytanie? Nie traci czasu na jakieś logi?
select id from testabc limit 1;  -- tutaj powinien się połączyć ( u mnie czasy od 0.2ms do 0.5ms )

Czas przetwarzania trywialnego zapytania nie ma raczej nic wspólnego z czasem przetwarzania jakiegoś nietrywialnego, jak już słusznie poprzedni koledzy zauważyli.

To zapytanie nie było po to, aby porównywać czas przetwarzania jednego wiersza z 20mln wierszy, tylko po to, aby upewnić się, czy z systemem nie ma jakiś problemów, albo czy jakiś proces w tle nie zaczął obciążać, itd. Jakby czas tego zapytania był powyżej 10ms, to dalsze testy nie mają sensu.

Zrób sobie symulację dla różnych rozmiarów danych i zobaczy jak rośnie czas względem rozmiaru danych.

Czemu nie, można zobaczyć. W przypadku gdy baza poprawnie wykorzysta właściwości b-tree do tego zapytania, to wiadomo z góry, że nawet gdy będzie 10^9 rekordów (zbuforowanych w RAM rzecz jasna) nie zauważę wzrostu czasu. A gdy baza to zapytanie wykonuje jakoś inaczej, to... nie mam pojęcia co wyjdzie. Ale... przypominam sobie jak działało w trakcie rozwoju aplikacji, bazy miały mniejszy rozmiar, i często zamulało po 300-600ms.

Krolik napisał(a):

Wątek może jest głupi, ale potwierdza tylko moją obserwację, że większość ludzi nie umie robić benchmarków. Tzn. ludzie często mierzą A, a następnie konkludują, że zmierzyli B, a następnie wyciągają daleko idące wnioski typu "Baza X jest zawsze szybsza od Y". A najczęściej nie da się stwierdzić wprost, że jedna baza jest szybsza od drugiej, bo to zależy od zbyt wielkiej liczby czynników.

Moja odpowiedź na to jest taka sama jak odpoweidź powyżej. Jeśli zrozumiałeś to tak, że program został napisany aby porównywać jeden do jeden, to też masz mnie za idiotę i dalsza rozmowa nie ma żadnego sensu.

Ale to Ty mimo, że mówisz, że program nie ma odzwierciedlać bazy danych twierdzisz, że baza danych jest beznadziejna, gdyż Twój program jest szybszy mimo braku właściwie jakichkolwiek funkcjonalności. Generalnie Koziołek wytknął Ci bardzo duży błąd w Twoich testach, a tam gdzie jest błąd w testach lub dowodzie nie można mówić o jakimkolwiek prawidłowym wniosku - w Twoim wypadku jest to stwierdzenie, że baza danych jest strasznie wolna w stosunku do Twojego programu. Stwierdzenie jest prawdziwe ale nie ma sensu, gdyż ten program nie ma praktycznie zastosowania w praktyce z uwagi na braki w funkcjonalności.

Offtopic: Jak dla mnie temat nadaje się do Perełek albo Flame - sam nie jestem pewien gdzie ;)

Alinous napisał(a):

Ale to Ty mimo, że mówisz, że program nie ma odzwierciedlać bazy danych twierdzisz, że baza danych jest beznadziejna, gdyż Twój program jest szybszy mimo braku właściwie jakichkolwiek funkcjonalności. Generalnie Koziołek wytknął Ci bardzo duży błąd w Twoich testach, a tam gdzie jest błąd w testach lub dowodzie nie można mówić o jakimkolwiek prawidłowym wniosku - w Twoim wypadku jest to stwierdzenie, że baza danych jest strasznie wolna w stosunku do Twojego programu. Stwierdzenie jest prawdziwe ale nie ma sensu, gdyż ten program nie ma praktycznie zastosowania w praktyce z uwagi na braki w funkcjonalności.

Offtopic: Jak dla mnie temat nadaje się do Perełek albo Flame - sam nie jestem pewien gdzie ;)

Piszesz nieprawdę w tym poście. Nie mówię nic takiego. Nie mowię, że program nie ma odzwierciedlać bazy danych jednocześnie twierdząc że baza danych jest beznadziejna. Owszem, piszę coś podobnego i łatwo pomylić, ale właśnie bez szczegółów które pomijasz, brzmi to jak idiotyzm. To co chcę powiedzieć jest trudniejsze, jest trudniejsze do zrozumienia, przykro mi że nie rozumiesz, albo celowo wypaczasz moją wypowiedź, ja już nie mam siły tłumaczyć tego samego piąty raz w kółko. Poza tym poza programem było jeszcze coś istotnego, ciekawe czy w ogóle kojarzysz co.

PS. Do przeniesienia nadaje się ten dowcip, który zamieściłem w komentarzu, nadaje się on do przeniesienia do podsumowania wątku:

Sytuacja zdarzyła się naprawdę kilka dni temu. W kuchni spadły zakupy, na podłogę rozlało się mleko z jakąś marmoladą. Mówię do niespełna 4 letniej dziewczynki: 'podaj szmatę'. Dziewczynka szmatę podała, ale weszła w pacię na podłodze. Mówię do niej: 'mogłaś przecież ominąć'. A ona do mnie: 'nie mówileś żebym ominęła'. Teraz wyształconym ludziom, specjalistom od baz danych, nie powiedziałem explicite że nie chcę porównywać jeden do jeden i nazwali mnie wariatem, albo zaproponowali aby wątek wyrzucić do kosza :D

To Ty postawiłeś tezę, że bazy danych są nieefektywne i na potwierdzenie pokazałeś jakiś program zupełnie od czapy.
Zamiast stawiać w pytaniu tezę (tj. zadawać pytanie w stylu: "od kiedy przestał Pan bić żonę?"), mogłeś np. spytać:

Co składa się na czas wykonania zapytania przez system baz danych?

Ale... przypominam sobie jak działało w trakcie rozwoju aplikacji, bazy miały mniejszy rozmiar, i często zamulało po 300-600ms.

300-600 ms to bardzo dużo. Przez ten czas baza danych może przejrzeć setki tysięcy a może nawet miliony rowków i to na dysku, a nie w pamięci. Jeśli nie miałeś tam setek MB danych do przejrzenia ani jakiś kosmicznych zapytań na kilka stron ala TPC-H, to raczej winni są (od najbardziej do najmniej prawdopodobnych):

• słaby programista tj. źle napisana aplikacja, zły model danych, złe zapytania
• słaby administrator bazy tj. zła konfiguracja, źle dobrany sprzęt, brak odpowiednich indeksów / statystyk itp.
• słaby lub nieadekwatny system baz danych (tak, widziałem kolesia, który chciał budować system o skali Allegro na PHP i MySQLu na jednym serwerze).

Generalnie jest bazą o mniejszej funkcjonalności, więc powinien być szybszy.

Funkcjonalność nie zawsze ma wpływ na wydajność w taki prosty sposób. Są takie funkcje, które stoją w opozycji do wysokiej wydajności (np. transakcje, wielodostęp, zapewnienie trwałości danych), ale też i takie, które umożliwiają uzyskanie większej wydajności (np. indeksy, perspektywy zmaterializowane, cache itp.)

To Ty postawiłeś tezę, że bazy danych są nieefektywne i na potwierdzenie pokazałeś jakiś program zupełnie od czapy.
Zamiast stawiać w pytaniu tezę (tj. zadawać pytanie w stylu: "od kiedy przestał Pan bić żonę?"), mogłeś np. spytać:

Ale ja widzę przypadek w którym są nieefektywne, zapytanie trwa 6s a może trwać 1ms - to jedna sprawa.

Druga sprawa jest taka, że w wątku poprzednim zasugerowano mi, iż:

1. baza musi przeznaczyć rzędy wielkości instrukcji na dodatkowe obliczenia
2. baza musi posortować wyniki, co jest bardzo ciężkie obliczeniowo,
3. przerobienie 20mln rekordów to wyzwanie dla bazy,
4. i rozmowę przerwano argumentując że program jest śmieszny.

Więc w tym wątku zadałem pytanie: dlaczego baza danych są nieefektywne?
Warto przeczytać poprzedni wątek, wtedy będzie wiadomo skąd taki tytuł tego wątku.

Okazało się, że ani baza nie musi przeznaczać rzędów wielkości na dodatkowe obliczenia, ani sortowanie nie jest takie ciężkie. ani 20 mln rekordów zbuforowanych w RAM nie stanowi żadnego wyzwania dla bazy. Wygląda jedynie na to, że bazy nie zawsze w pełni potrafią wykorzystać możliwości jakie dają b-drzewa.

300-600 ms to bardzo dużo. Przez ten czas baza danych może przejrzeć setki tysięcy a może nawet miliony rowków i to na dysku, a nie w pamięci. Jeśli nie miałeś tam setek MB danych do przejrzenia ani jakiś kosmicznych zapytań na kilka stron ala TPC-H, to raczej winni są (od najbardziej do najmniej prawdopodobnych):

Zależy jak używasz określenia 'może przejrzeć'. Jeśli mamy dysk talrzowy i baza szuka losowo rozmieszczonych danych, to może nie dać rady przejrzeć 100 rekordów w sekundę. Natomiast jeśli mamy dane w pamięci RAM i baza nie przegląda dosłownie, tylko skacze pod właściwe rekordy dzięki indeksom, to może przez sekundę przejrzeć większą pamięć, niż jest sumarycznie na wszystkich komputerach świata.

Co do ilości danych, to chciałbym aby baza wyrabiała się na dowolej ilość danych pod warunkiem że dane i indeksy są całkowicie zbuforowane w pamięci ram, czyli np. gdy komputer będzie miał 1TB pamięci RAM, to bym chcial, aby tamto zapytanie działało w góra 10ms na zbiorze o rozmiarze powiedzmy 0.5TB. Myślę, że to nie jest ciężki wymóg, ale baza musi używać optymalnie indeksów.

słaby programista tj. źle napisana aplikacja, zły model danych, złe zapytania

Jedno zapytanie sql na jednej tabeli, choćbym chciał, to bym nie dał rady spieprzyć. Poza tym na uproszczonej bazie działa ono w 1ms.

słaby administrator bazy tj. zła konfiguracja, źle dobrany sprzęt, brak odpowiednich indeksów / statystyk itp.

TO się zgadza, jestem raczej słabym administratorem bazy danych. Umiem tylko podstawowe opcje ustawić. Ale to właśnie podstawowe są najważniejsze. Nie wiem nic o statystykach postgresa, w tej sprawie bym musiał coś poczytać. Indkesy chyba rozumiem, sam własnoręcznie kiedyś napisałem b-drzew w C++, ale co zrobić aby postgres lepiej korzystał z b-drzew, to też wiem raczej słabo.

łaby lub nieadekwatny system baz danych (tak, widziałem kolesia, który chciał budować system o skali Allegro na PHP i MySQLu na jednym serwerze).

Mato Boska.

U mnie skala zadania, dobór bazy do zadania, są w porządku, o czym świadczy wynik testu na uproszczonej bazie.

Wniosek taki wyciągasz na podstawie nieprawidłowego, na poziomie metodyki i założeń, pojedynczego testu na zupełnie różnych zbiorach danych, tak?

Bazy danych do przechowywania danych operacyjnych - zbiroru roboczego sa bez sensu od wielu lat. To bylo rozwiazanie z lat 90 jak bylo w komputerach po 120MB pamieci (a 2GB to byly duze zbiory danych).

Nie tylko spowalniaja ale tez totalnie psuja kod, przejrzystosc systemu i przeszkadzaja w efektywnej wspolbieznosci.

Zreszta bierzcie moje video:
https://vimeo.com/170796157

@Jarek000000, ale tu test jest bez sensu :)