Dlaczego bazy danych są nieefektywne?

W poprzednim wątku wykazałem, że nawet w przypadku prostych zapytań select (prostych czyli bez złączeń tabel, bez grupowania, bez agregacji, bez offset, bez sortowania wielokolumnowego, bez LIKE, itd), transakcyjna baza danych sql jest około 100tys (słownie sto tysięcy) razy wolniejsza od programu napisanego w kompilowanych językach (np. C, C++, Java, Delphi, Assembler). Żeby nie było znowu wielkich nieporozumień, przypomnę co najistotniejsze, mianowicie test zakładał, iż dane są całkowicie zbuforowane w pamięci RAM.

Spowolnienie 100tys razy oznacza, że baza danych (dokładnie pisząc silnik bazy danych) wykonuje 100tys instrukcji procesora w jakimś innym celu po to, aby potem wykonać jedną instrukcję w celu właściwym, czyli w celu wyszukania właściwych danych. Jakby baza poświęcałą 300 instrukcji na inny cel, to może bym zrozumiał. Jednak 100tys nie mieści mi się w głowie.

Zastanawia mnie czego się spodziewać w przypadku baz NoSQL. W przypadku baz NoSQL rząd wielkości też będzie w okolicach 100tys, bo
baza 'musi jeszcze coś innego'?

Pozdrawiam

jedyne co wykazales to ze nie masz za bardzo pojecia co robisz. masz jakas swoja hipoteze wynikajaca z ignorancji w temacie i stosujesz demagogie zeby ja przeforsowac.
wyobraz sobie alternatywna teorie - bazy danych zostaly stworzone po to zeby efektywnie przechowywac, zarzadzac i zwracac dane i (niepodzianka) dzialaja calkiem niezle na milion razy wiekszych zbiorach danych niz twoj. no ale jasne, bazy danych winne ze zamiast je jako tako ogarnac to ubolewasz ze w asemblesze to by szybciej bylo ;)

@artur_bredzki gdzie ten post gdzie to wykazales?

Bo jedynie co moge znalezc, to kod pisany w C z klasami (wiec ani to C ani to C++) i porownujesz baze danych do... tablic... co jest bardzo nietrafione

Patrzysz na efekt globalny a nie na techniczne detale i wyciagasz zle wnioski (odnosnie tego tematu Jak postgresql przechowuje tabele)

Moglbys mi podac linka gdzie przeprowadzales i wykazales ze sa wolniejsze? I to w tylu jezykach? a co z niekompilowalnymi jezykami? No i oczywiscie Ty piszesz ze pchasz wszystko do ramu. A jak to moge zapisac i pozniej odczytac? (zastanow sie nad ostatnim pytaniem, bo nie jest trywialne)

ja tylko przekopiuję tu odpowiedź jaśnie oświeconego na pytanie jak policzyć średnie w zadanym okresie czasu, uwaga

Policz średnie ruchome i uaktualniaj przyrostowo.

średnia roczna na dziś = ( średnia roczna na wczoraj * 365 + temperatura z dziś - temperatura sprzed roku ) / 365

jak widzicie wszystko staje się jasne - chcesz mieć szybką bazę danych - trzymaj wszystko w ramie (oczywiście wyniki wszelkich wcześniejszych zapytań też) i NIGDY nie wyłączaj komputera bo stracisz dane

katelx napisał(a):

jedyne co wykazales to ze nie masz za bardzo pojecia co robisz.

Nie musisz sprowadzać rozmowy na poziom niżej.

katelx napisał(a):

masz jakas swoja hipoteze wynikajaca z ignorancji w temacie i stosujesz demagogie zeby ja przeforsowac.

Założe się o 1000zł że nie zrozumiałeś/aś mojej hipotezy.

katelx napisał(a):

wyobraz sobie alternatywna teorie - bazy danych zostaly stworzone po to zeby efektywnie przechowywac, zarzadzac i zwracac dane i

Proponuję na alternatywne teorie zalożyć osobny wątek, może być ciekawie.

katelx napisał(a):

(niepodzianka) dzialaja calkiem niezle na milion razy wiekszych zbiorach danych niz twoj. no ale jasne, bazy danych winne ze zamiast je jako tako ogarnac to ubolewasz ze w asemblesze to by szybciej bylo ;)

Niespodzianka zaszła jedynie w Twojej wyobraźni, ponieważ chesz przeforsować teorię, że mam strasznie złowrogie intencje wobec słodkich i kochaniutkich baz danych ;-)

Posłucha uważniej, ja rozmawiam rzeczowo, rzetelnie i o faktach. Faktami np. są:

• te same wyniki uzyskane z zapytania sql co z programu napisanego w C++.
• opis środowiska testowego, ten sam komputer, dane przechowywane w tym samym nośniku,
• te same możliwości zaindeksowania danych,
• znacząco różny czas wykonania obu prgramów, różnica rzędu 100tys razy.

Wniosek jest prosty, baza danych robi coś jeszcze. Zastanawia mnie po pierwsze co takiego baza jeszcze robi? Druga sprawa, czy w przypadku baz NoSQL można spodziewać się takiej samej katastrofy wydajnościowej?

Pozdrawiam

abrakadaber napisał(a):

ja tylko przekopiuję tu odpowiedź jaśnie oświeconego na pytanie jak policzyć średnie w zadanym okresie czasu, uwaga

Policz średnie ruchome i uaktualniaj przyrostowo.

średnia roczna na dziś = ( średnia roczna na wczoraj * 365 + temperatura z dziś - temperatura sprzed roku ) / 365

jak widzicie wszystko staje się jasne - chcesz mieć szybką bazę danych - trzymaj wszystko w ramie (oczywiście wyniki wszelkich wcześniejszych zapytań też) i NIGDY nie wyłączaj komputera bo stracisz dane

Gdzie Ty widzisz że użyłem słowa RAM w tej odpowiedzi? Masz urojenia czy co?

fasadin napisał(a):

@artur_bredzki gdzie ten post gdzie to wykazales?
Bo jedynie co moge znalezc, to kod pisany w C z klasami (wiec ani to C ani to C++)

To odszukałeś nie mój post, bo ja nie umiem programować w C z klasami, znam tylko C i C++.

fasadin napisał(a):

i porownujesz baze danych do... tablic... co jest bardzo nietrafione

Nie wiem czemu tak zrozumiałeś, przecież cały czas rozmowa byłą o zbuforowanej w pamięci RAM bazie danych. Bufor bazy danych porównuję do tablic, a nie bazę danych, co jest oczywiste.

fasadin napisał(a):

Patrzysz na efekt globalny a nie na techniczne detale i wyciagasz zle wnioski (odnosnie tego tematu Jak postgresql przechowuje tabele)

Co nazywasz detalami technicznymi i dlaczego powinienem zwracać uwagę na detale techniczne a nie na efekt globalny? Mojego klienta nie interesują detale techniczne, tylko właśnie efekt, czyli czas dostępu do danych, czas wyświetlenia rezultatu.

fasadin napisał(a):

Moglbys mi podac linka gdzie przeprowadzales i wykazales ze sa wolniejsze? I to w tylu jezykach?

Wydajność języków kompilowanych jest bardzo podobna, zależna od optymalizatora w kompilatorze tego języka. Jeśli w jednym kompilowanym języku uzyskuje się dany efekt, to w innych będzie bardzo podobny.

fasadin napisał(a):

a co z niekompilowalnymi jezykami?

Nie wiem, ale można się domyślać, że zależy wiele od tego, jak się użyje języków niekompilowanych. Zwykle języki interpretowane są wolniejsze 100 razy od kompilowanych, ale wiele zależy od sposobu w jaki się używa danego języka.

fasadin napisał(a):

No i oczywiscie Ty piszesz ze pchasz wszystko do ramu. A jak to moge zapisac i pozniej odczytac? (zastanow sie nad ostatnim pytaniem, bo nie jest trywialne)

To pytanie zadałeś, bo jak pisałem wyżej, nie zorzumiałeś o czym jest rozmowa. Nie chodzi o 'pchanie wszystkiego do ramu', tylko o pełne buforowanie danych dyskowych w pamięci RAM. Nie wiem dlaczego nie zrozumiałeś i TY i Twój przespiśca, ponieważ technki buforowania danych dyskowych w pamięci RAM są powszechne, buforują urządzenia, kontrolery, systemy plików, sterowniki, systemy operacyjne, bazy danych, a nawet aplikacje klienckie.

Pozdrawiam

ok, widze ze cie najprawdopodobniej nie przekonam, no ale jeszcze raz zachecam do zapoznania sie z dowolna baza danych (dowolna popularna, ale polecam postgresa bo jest imo najfajniejszy). powtorze - to ze masz problemy wydajnosciowe to twoja wina.

katelx napisał(a):

ok, widze ze cie najprawdopodobniej nie przekonam, no ale jeszcze raz zachecam do zapoznania sie z dowolna baza danych (dowolna popularna, ale polecam postgresa bo jest imo najfajniejszy). powtorze - to ze masz problemy wydajnosciowe to twoja wina.

Przecież tutaj nie chodzi o przekonywanie ani o czyjąś winę. Co do czego w tym wątku chcesz mnie przekonywać? Chcesz mnie przekonać że minuta to jest sekunda? Czy to moja wina że mój zegarek chodzi tak samo jak Twój?

Powtórzę, nie chodzi o moje problemy z wydajnością bazy. Chodzi o rzetelny i obiektywny pomiar czasu wykonania dwóch programów. Jeden z tych programów wykonuje się koszmarnie wolno, tak się składa że koszmarnie wolno wykonuje się zapytanei SQL. Chcę wiedzieć dlaczego wykonuje się koszmarnie wolno i chcę wiedzieć czy podobnie jest w przypadku baz NoSQL. Po to są obiektywne metody porównywania, żeby nikt do niczego nie musiał nikogo przekonywać.

Mogę nawet napisać Ci dlaczego chcę to wiedzieć. Bo zamierzam napisać specjalistyczną bazę danych do jednej aplikacji w C++. Zastanawiam się czy moja baza nie będzie musiała robić tego wszystkiego co robi baza SQL i czy w efekcie nie zadziała też koszmarnie wolno. Rozumiesz już cokolwiek z mojej wypowiedzi, czy nadal wolisz sprowadzać rozmowę na tor w stylu 'jaki z ciebie ignorant/debil, nie rozumiesz do czego są bazy danych'? Jeśli rozumiesz i masz do powiedzenia coś rzeczowego/obiektywnego w temacie, to zachęcam do dalszej rozmowy, a w przeciwnym razie proponuję osobny wątek.

Pozdrawiam

Spowolnienie 100tys razy oznacza, że baza danych (dokładnie pisząc silnik bazy danych) wykonuje 100tys instrukcji procesora w jakimś innym celu po to, aby potem wykonać jedną instrukcję w celu właściwym, czyli w celu wyszukania właściwych danych.

WTF? Idąc tym tokiem rozumowania skoro moja strona www ładuje się w 600ms, a google w 300ms - to znaczy że kod google'a jest dwa razy mniej skompilowany? czy może serwery google wykonują mniej 2x mniej instrukcji niż u mnie? A może google ma tylko 2x mocniejszy serwer niż mój?

1. bazy danych SQL (mam na myśli program, nie konkretne schematy bazy) są projektowane i pisane tak, aby pokryć jak największą ilość przypadków - są uniwersalne
2. bazy danych SQL muszą zapewnić po pierwsze bezpieczeństwo danych (w tym fakt, że po wyłączeniu zasilania dane nie zginą) a po drugie WIELODOSTĘP
3. system napisany pod specjalne wytyczne (o ile jest napisany poprawnie) zawsze będzie szybszy od systemu ogólnego

axelbest napisał(a):

Spowolnienie 100tys razy oznacza, że baza danych (dokładnie pisząc silnik bazy danych) wykonuje 100tys instrukcji procesora w jakimś innym celu po to, aby potem wykonać jedną instrukcję w celu właściwym, czyli w celu wyszukania właściwych danych.

WTF? Idąc tym tokiem rozumowania skoro moja strona www ładuje się w 600ms, a google w 300ms - to znaczy że kod google'a jest dwa razy mniej skompilowany? czy może serwery google wykonują mniej 2x mniej instrukcji niż u mnie? A może google ma tylko 2x mocniejszy serwer niż mój?

Dlaczego pytasz?

Jestem ciekaw jak policzyłeś fakt że jeśli jakiś proces wykonuje się 100 tys. razy wolniej niż drugi - to że ten pierwszy wykonuje dokładnie tyle samo nadmiarowych instrukcji? Nie mam takiej wiedzy jak Ty, na codzień programuje w języku programowania dla leszczy (żadne tam C/Java) więc po prostu chce się dokształcić, bo jak to mawiają - mądrego zawsze warto posłuchać.

Przypomniało mi się jak na prywatnym portalu nie nadałem indexów na pewnych tabelkach. W pewnym momencie strona generowała się 10s, a ja zwalałem winę na hosting. W końcu sprawdziłem czasy zapytań a tam jedno z zapytań 5s xd nadałem indexy tam gdzie nie nadałem i nagle wszystko zaczęło śmigać. A zapytanie najcięższe z 5s spadło do 200ms :D

artur_bredzki napisał(a):

Bo zamierzam napisać specjalistyczną bazę danych do jednej aplikacji w C++
nie no to szacun ze masz wystarczajaca wiedze na napisanie lepszej bazy danych niz te opracowane przez specjalistow w tej dziedzinie i przetestowane przez miliony wdrozen. klient na pewno bedzie zadowolony z oszczednosci jakie poczynil wybierajac wlasnie twoje rozwiazanie

artur_bredzki napisał(a):

Zastanawiam się czy moja baza nie będzie musiała robić tego wszystkiego co robi baza SQL i czy w efekcie nie zadziała też koszmarnie wolno
ano tak, nie znasz podstaw dzialania baz danych wiec stwierdzasz ze napiszesz swoja, jednym slowem pro

artur_bredzki napisał(a):

Rozumiesz już cokolwiek z mojej wypowiedzi, czy nadal wolisz sprowadzać rozmowę na tor w stylu 'jaki z ciebie ignorant/debil, nie rozumiesz do czego są bazy danych'?
ale ja nie chce cie obrazac, po prostu cos tam wiem o bazach danych i mozna powiedziec ze na codzien zajmuje sie pisaniem wlasnych struktur danych do przetwarzania duzych ilosci danych w czasie rzeczywistym. dlatego traktuj to jako przyjacielska rade - wez sobie postaw postgresa na wirtualce, znajdz fajny tutorial i pobaw sie troche danymi zamiast robic bezsensowne porownania miedzy hello world w c++ a profesjonalnym rozwiazaniem bo to naprawde nie ma sensu.

@artur_bredzki linkowałem ci w ostatnim tematcie bardzo porządną ksiażkę. Ściągnij ja / wypożycz z biblioteki i przeczytaj ze zrozumieniem. Ja wiem ze długa, ale doświadczenie uczy że da się ją przeczytać w 2 dni przed egzaminem, więc w normalnych warunkach starczy ci tydzień. Dopiero jak przeczytasz ją ze zrozumieniem wróć tutaj i możemy o czymś dyskutować.

abrakadaber napisał(a):

1. bazy danych SQL (mam na myśli program, nie konkretne schematy bazy) są projektowane i pisane tak, aby pokryć jak największą ilość przypadków - są uniwersalne
2. bazy danych SQL muszą zapewnić po pierwsze bezpieczeństwo danych (w tym fakt, że po wyłączeniu zasilania dane nie zginą) a po drugie WIELODOSTĘP
3. system napisany pod specjalne wytyczne (o ile jest napisany poprawnie) zawsze będzie szybszy od systemu ogólnego

Oooo! W końcu widzę i odpowiedź którą nazwałbym 'światełko w tunelu' :)

To wszystko co napisałeś jest prawdą, jest wręcz oczywiste i odzwierciedla przyczynę spowolnienia które mnie niepokoi.

Oczywiście baza danych (rozumiana jako silnik) musi wykonać więcej niż program operujący na tablicy ram.

Mimo wszystko niepokoi mnie rząd wielkości jaki zaobserwowałem, różnicy czasu rzędu 100tys raz nie spodziewałbym się w
najgorszych koszmarach. Myślałem że narzut bazy będzie od 100 do 1000 razy, ale 100tys?

Co baza danych musi zrobić z zapytaniem?

1. Najpierw połączenie przez np. TCP/IP.
2. Potem parsowanie zapytania.
3. Dalej, optymalizacja zapytania.
4. Potem, (chyba) zamiana zapytania na wewnętrzny kod.
5. Dalej (być może) kompilacja wewnętrznego kodu.
6. W końcu wykonanie zapytania.
7. Odesłanie wyników.

Oczywistym jest, że wraz z rozrostem danych coraz bardziej istotny wpływ na czas wykonania ma punkt 6, więc pozostałe punkty bym pominął.
Szczególnie w prostych zapytaniach punkt 6 ma decydujący wpływ.

Więc co taka lub inna baza danych musi zrobić w punkcie szóstym, czego nie robi program operujący na tablicy w RAM?

I/O jest tysiace razy wolniejsze niż dostęp do CPU cache (a to w twoim programie robiłeś, nie było tam nigdzie czytania z RAMu).
Czytanie danych z dysku to jest bardzo wolne I/O, a jeśli jeszcze baza uzna że najlepiej zrobić skanowanie według indeksu secondary i wykona wiele dostępów do dysku to juz w ogóle mogiła.

mr_jaro napisał(a):

Przypomniało mi się jak na prywatnym portalu nie nadałem indexów na pewnych tabelkach. W pewnym momencie strona generowała się 10s, a ja zwalałem winę na hosting. W końcu sprawdziłem czasy zapytań a tam jedno z zapytań 5s xd nadałem indexy tam gdzie nie nadałem i nagle wszystko zaczęło śmigać. A zapytanie najcięższe z 5s spadło do 200ms :D

Wiadomo, indeksy to podstawa optymalizacji. Myślę że najważniejsza sprawa w optymalizacji baz danych to odpowiednia struktura, w tym wyniki częściowe. Druga co do ważności to odpowiedni sprzęt i bufor RAM. Czasy dostępu na dyskach talerzowych, dyskach SSD i w pamięci RAM
różnią się kolosalnie. Trzecia co do ważności to pewnie indeksy. To wszystko przerobiłem i okazało się, że nie wystarcza. Na niektórych zapytaniach baza zamula i daje odpoweidź aż po 40s. Więc myślę, że teraz przyszedł czas na optymalizację samego wykonania zapytania, niestety tego już w SQLu nie da się zrobić.

Pozdrawiam

axelbest napisał(a):

Jestem ciekaw jak policzyłeś fakt że jeśli jakiś proces wykonuje się 100 tys. razy wolniej niż drugi - to że ten pierwszy wykonuje dokładnie tyle samo nadmiarowych instrukcji? Nie mam takiej wiedzy jak Ty, na codzień programuje w języku programowania dla leszczy (żadne tam C/Java) więc po prostu chce się dokształcić, bo jak to mawiają - mądrego zawsze warto posłuchać.

Nie zrobiłem w tej kwestii nic bardziej rewelacyjnego niż mógłby zrobić każdy. Podzielilem jeden czas przez drugi. Wyszło 1000 razy.
Program w C++ był metodą fullscan, a SQL z indeksami. Więc zastanowiłem się co się stanie gdy w C++ też użyję indeksów. Wyszło mi że
program przerzuci 1000razy mniej danych, ale dostęp do danych (nie-sekwencyjny) wydłuży się 10 razy, czyli 1000*1000/10 = 100tys razy.

zeby nie bylo ze tylko dokuczam, masz tu rozwiazanie nosql ktore smialo moglabym polecic najbardziej wymagajacym maniakom czystej wydajnosci - kdb+

artur_bredzki napisał(a):

Na niektórych zapytaniach baza zamula i daje odpoweidź aż po 40s. Więc myślę, że teraz przyszedł czas na optymalizację samego wykonania zapytania, niestety tego już w SQLu nie da się zrobić.

Podziel zapytanie. Jeżeli jedno duże wykonuje się zbyt długo to w 99% przypadkach u mnie podział na kilka mniejszych zapytań nawet wywoływanych w pętli dał wynik mnie satysfakcjonujący.

katelx napisał(a):

artur_bredzki napisał(a):

Bo zamierzam napisać specjalistyczną bazę danych do jednej aplikacji w C++
nie no to szacun ze masz wystarczajaca wiedze na napisanie lepszej bazy danych niz te opracowane przez specjalistow w tej dziedzinie i przetestowane przez miliony wdrozen. klient na pewno bedzie zadowolony z oszczednosci jakie poczynil wybierajac wlasnie twoje rozwiazanie

Nadal nic nie rozumiesz, albo celowo wypaczasz moją wypowiedź. Pisałem 'specjalistyczną bazę do jednej aplikacji', a nie bazę ogolną. Czy wiesz jaka jest różnica pomiędzy specjalistyczną bazą a ogólną? Za szacunek dziękuję, mam więdzę aby napisać niektóre specjalistyczne bazy danych do aplikacji.

artur_bredzki napisał(a):

Zastanawiam się czy moja baza nie będzie musiała robić tego wszystkiego co robi baza SQL i czy w efekcie nie zadziała też koszmarnie wolno
ano tak, nie znasz podstaw dzialania baz danych wiec stwierdzasz ze napiszesz swoja,
</quote>
Nie lubię ogólnej krytyki, bo nie mogę się z tego nic nauczyć. Czy możesz napisać konkretnie JAKICH podstaw nie znam?

artur_bredzki napisał(a):

jednym slowem pro

Jednym słowem, ja o niebie, a Ty o chlebie, ale nie musisz zrozumieć wypowiedzi, aby krytykować.

artur_bredzki napisał(a):

Rozumiesz już cokolwiek z mojej wypowiedzi, czy nadal wolisz sprowadzać rozmowę na tor w stylu 'jaki z ciebie ignorant/debil, nie rozumiesz do czego są bazy danych'?

artur_bredzki napisał(a):

ale ja nie chce cie obrazac, po prostu cos tam wiem o bazach danych i mozna powiedziec ze na codzien zajmuje sie pisaniem wlasnych struktur danych do przetwarzania duzych ilosci danych w czasie rzeczywistym. dlatego traktuj to jako przyjacielska rade - wez sobie postaw postgresa na wirtualce, znajdz fajny tutorial i pobaw sie troche danymi zamiast robic bezsensowne porownania miedzy hello world w c++ a profesjonalnym rozwiazaniem bo to naprawde nie ma sensu.

Wcale a wcale nie krytykujesz, nic nie obrażasz, rozmowa z Tobą jest na wysokim poziomie, a program który wypluwa te same dane co zapytanie SQL nazywasz hello world....

Jeśli nie obrażasz celowo, to może Ty czegoś nie rozumiesz? Może znasz się na bazach, a nie znasz się na bebechach procesora i nie dociera do Ciebie porównanie programu w C++ do zapytania SQL?

mr_jaro napisał(a):

artur_bredzki napisał(a):

Na niektórych zapytaniach baza zamula i daje odpoweidź aż po 40s. Więc myślę, że teraz przyszedł czas na optymalizację samego wykonania zapytania, niestety tego już w SQLu nie da się zrobić.

Podziel zapytanie. Jeżeli jedno duże wykonuje się zbyt długo to w 99% przypadkach u mnie podział na kilka mniejszych zapytań nawet wywoływanych w pętli dał wynik mnie satysfakcjonujący.

Tak, jest to dobra technika optymalizacyjna. W moim przypadku akurat bym musiał zainstalować kilka baz (tak żeby pracowały na niezależnym procesorze i ram), potem podzielić dane pomiędzy bazy, ostatecznie w programie złączać wyniki. Jakiś czas temu nawet wypromowano tej technice optymalizacyjnej marketingową nazwę map-reduce. Niby taki hadoop ma tę technikę natywnie, ale nie wiem jaka jest wydajność przykładowego hadoopa na pojedynczej maszynie. Myślę, że to co można zrealizować na postgresie na 10-300 maszynach, w niektórych przypadkach można w C++ na jednej maszynie. Bym musiał analogiczny eksperyment przeprowadzić na hadoopie.

Jak napiszesz swoją bazę i będzie ci wszystko działać to wróć się pochwal :) Ja też kiedyś napisałem framework php bo uważałem, że to co jest na rynku jest zbyt wolne :) Nawet działał na 3 stronach także ten... :p

mr_jaro napisał(a):

Jak napiszesz swoją bazę i będzie ci wszystko działać to wróć się pochwal :) Ja też kiedyś napisałem framework php bo uważałem, że to co jest na rynku jest zbyt wolne :) Nawet działał na 3 stronach także ten... :p

Co tu się chwalić. Kilka swoich specjalistycznych baz pod daną aplikację napisałem, spełniały swoje zadanie bardzo dobrze. Problem jest czas niezbędny na pracę i ryzyko, że się wszystkiego nie uwzględni i potem własna baza będzie działała gorzej niż dostępne za darmo i od razu.

artur_bredzki napisał(a):

Jeśli nie obrażasz celowo, to może Ty czegoś nie rozumiesz? Może znasz się na bazach, a nie znasz się na bebechach procesora i nie dociera do Ciebie porównanie programu w C++ do zapytania SQL?
no tak srednio trafiles. wlasnie sporo pracuje nad optymalizacja kodu pod cache procesora. nie dociera do mnie porownanie bo jest ono najogolniej mowiac z d**y. ale wierz tam sobie nawet we wrozbite macieja.
dalam ci wyzej linka do bardzo dobrego (jesli nie najlepszego), komercyjnie wspieranego (a 32bitowa baza za free) rozwiazania na problemy ktore posiadasz (minimalistyczny jezyk/interpreter pozwala na upakowanie calej appki w L1 cache!) wypadaloby zebys chociaz podziekowal i powiedzial czy jest to wystarczajace na twoje potrzeby.

katelx napisał(a):

artur_bredzki napisał(a):

Jeśli nie obrażasz celowo, to może Ty czegoś nie rozumiesz? Może znasz się na bazach, a nie znasz się na bebechach procesora i nie dociera do Ciebie porównanie programu w C++ do zapytania SQL?

no tak srednio trafiles. wlasnie sporo pracuje nad optymalizacja kodu pod cache procesora. nie dociera do mnie porownanie bo jest ono najogolniej mowiac z d**y.

Dla mnie z d**y jest odpowiedź która zaiwera uzasadnienie że że coś jest z d**y.

katelx napisał(a):

ale wierz tam sobie nawet we wrozbite macieja.

Ja wierzę tylko w pomiar czasu. Jeśli coś działa w krótszym czasie i daje ten sam efekt, to nie jest z d**y.

katelx napisał(a):

dalam ci wyzej linka do bardzo dobrego (jesli nie najlepszego), komercyjnie wspieranego (a 32bitowa baza za free) rozwiazania na problemy ktore posiadasz (minimalistyczny jezyk/interpreter pozwala na upakowanie calej appki w L1 cache!) wypadaloby zebys chociaz podziekowal i powiedzial czy jest to wystarczajace na twoje potrzeby.

Dziękuję. Czy jest na moje potrzeby? Trudno będzie odpowiedzieć, to pewnie wymaga nie tylko analizy, ale i testów. Kiedyś naczytałem się o rzekomej wydajności baz danych SQL i też myślałem że będą idealne na moje potrzebny, indeksy, optymalizatory, cuda... a tu wyszło że są, że znowu posłużę się Twoim porównaniem, z d**y.

Shalom napisał(a):

I/O jest tysiace razy wolniejsze niż dostęp do CPU cache (a to w twoim programie robiłeś, nie było tam nigdzie czytania z RAMu).
Czytanie danych z dysku to jest bardzo wolne I/O, a jeśli jeszcze baza uzna że najlepiej zrobić skanowanie według indeksu secondary i wykona wiele dostępów do dysku to juz w ogóle mogiła.

Oczywiście, to wszystko prawda. Dostęp do danych na dysku jest bardzo wolny. Odczyt danych z dysku zazwyczaj też szybki nie jest. Dlatego oczywiście zadbałem w testach o to, aby dane i indeksy bazy SQL był w buforze RAM.

Widzę, że jest zajadła dyskusja, więc próbowałem się dowiedzieć z Jak postgresql przechowuje tabele, o czym, ale może za wcześnie odpadłem. Wygląda, że porównujesz zapytanie SQL z programem w C++, który jednak robi coś prostszego, bo nie ma sortowania. Chyba można przyjąć, że najlepszy czas wykonania SQL jest wtedy, gdy dane rzeczywiście są zbuforowane w RAM, a wtedy jest tylko o rząd wielkości wolniej niż w przypadku programu w C++. Poza tym nie wiadomo, jakie są rozkłady wartości w tabeli i czy są policzone statystyki. Od tego może mocno zależeć, czy użycie indeksów jest sensowne.

Czy coś pominąłem?

@artur_bredzki Na moje to za dużo biadolisz, napisz coś i zaprezentuj na forum to pogadamy