Porównanie wydajnosci wybranych baz danych
wojtek
Zainpirowany testami przeprowadzonymi przez Roberta Grabowskiego
postanowilem
zrobic zestawienie wybranych baz danych (akurat takie mam u siebie na
komputerze)
Testowalem na komputerze
AMDXP 2GHz, FBS 100MHz, 768 MB ram, HDD 80GB Seagate Barracuda
system operacyjny WinXP
testowane bazy danych:
- MySQL 3.23.56nt
- PostgreSQL 7.5 devel win
- Firebird 1.5
- Oracle 8
- Pervasive 8.5 Workgroup
Na kazdej z baz danych utworzylem prosta tabele z 5 milionami rekordow (na
kazdej te same dane)
Wyniki:
SELECT count(*) FROM test;
1. Mysql - 0.00s
2. Pervasive - 0.00s
3. Firebird - 8.70s
4. Pgsql - 9.19s
5. Oracle - 13.42s
SELECT nazwa, count(*) FROM test GROUP BY nazwa;
1. Oracle - 14.82s
2. Pgsql - 17.83s
3. Mysql - 32.61
4. Firebird - 45.58
5. Pervasive - 3m37s
SELECT nazwa, opis, count(*) FROM test GROUP BY nazwa, opis;
1.Oracle - 16.54s
2. Pgsql - 25.55s
3. Mysql - 1m21s
4. Firebird - 5m57s
5. Pervasive - 13m25s
DELETE FROM test;
1. Mysql - 0.02s
2. Pgsql - 2m12s
3. Firebird - 4m58s
4. Pervasive - 8m02s
5. Oracle - ? (problemy z RBS)
Pewnie zabrakło tutaj wiele innych zapytań które nalezalo by przetestować,
ale przyznam, ze przeprowadznie takich testow
jest badzo czasochlonne, glownie generowanie danych.
pozdrawiam
wojtek
Marcin Gajda
> SELECT count(*) FROM test;
> 1. Mysql - 0.00s
> 2. Pervasive - 0.00s
> 3. Firebird - 8.70s
> 4. Pgsql - 9.19s
> 5. Oracle - 13.42s
Mógłbyś jeszcze dorzucić jakiegoś WHERE'a do tego zapytania (a najlepiej
do wszystkich)? Tak, aby zmusić dwie pierwsze bazy do przeglądania
tabel (np. WHERE id mod 10 = 0 ).
Pozdrawiam,
--
Marcin Gajda ________________________
Linux registered user #300108 _______
Dieu me pardonerra - c'est son metier
wojtek
Użytkownik "Marcin Gajda" <marcin...@kicha.zagrycha.pl> napisał w
wiadomości news:c7jb4u$dgp$1...@kenny.mimuw.edu.pl...
> wojtek <woj...@beztegopulpit.pl> wrote:
>
> > SELECT count(*) FROM test;
> > 1. Mysql - 0.00s
> > 2. Pervasive - 0.00s
> > 3. Firebird - 8.70s
> > 4. Pgsql - 9.19s
> > 5. Oracle - 13.42s
>
> Mógłbyś jeszcze dorzucić jakiegoś WHERE'a do tego zapytania (a najlepiej
> do wszystkich)? Tak, aby zmusić dwie pierwsze bazy do przeglądania
> tabel (np. WHERE id mod 10 = 0 ).
>
bardzo przymulily mi kompa
ale jezeli opracuje sie liste zapytan jakie mialyby byc, to powotorzylbym te
testy;
pozdrawiam
wojtek
Paweł
> Witam
> Zainpirowany testami przeprowadzonymi przez Roberta Grabowskiego
> postanowilem
> zrobic zestawienie wybranych baz danych (akurat takie mam u siebie na
> komputerze)
Polecam jednak przetestowanie baz danych standardowym testem, który
zbada wydajność SZBD w konkretnych zastosowaniach (systemy transakcyjne,
magazyny danych (np. testy TPC-C i TPC-H).
Przeprowadzałem kiedyś takie testy dla SZBD SQL Server 2000, Oracle 9i i
DB2 8.1 na komputerze Athlon 1800+, 512MB Ram, Seagate 80GB. SQL Server
był najlepszy w przetwarzaniu transakcyjnym (TPC-C, wolumen danych ok.
1GB), natomiast Oracle w magazynach danych (TPC-H, wolumen danych ok.
900MB).
Paweł O.
Wojtek pBT
wojtek wklepala z wieksza lub niejsza iloscia bledow:
może i ja się dorzucę ;)
Może Alter table, a już dobrze by było [INNER | LEFT] JOIN.
Może sortowanie, i przedewszystkim WHERE. Cielawi mnie czy waro
maltretowac bazę LIKE
ps: Opublikowałeś gdzieś te dane, prucz grupy??
pBT
wojtek
Użytkownik "Paweł" <pa...@poczta.onet.pl> napisał w wiadomości
news:c7jfo0$kn5$1...@topaz.icpnet.pl...
> Polecam jednak przetestowanie baz danych standardowym testem, który
> zbada wydajność SZBD w konkretnych zastosowaniach (systemy transakcyjne,
> magazyny danych (np. testy TPC-C i TPC-H).
> Przeprowadzałem kiedyś takie testy dla SZBD SQL Server 2000, Oracle 9i i
> DB2 8.1 na komputerze Athlon 1800+, 512MB Ram, Seagate 80GB. SQL Server
> był najlepszy w przetwarzaniu transakcyjnym (TPC-C, wolumen danych ok.
> 1GB), natomiast Oracle w magazynach danych (TPC-H, wolumen danych ok.
> 900MB).
>
> Paweł O.
A czy te testy mozna rozwniez wykonac na bazach niekomercyjnych? np
Postgresql,
Firebird i MySQL (przy zalozeniu, ze tez jest niekomercyjna) ?
pozdrawiam
wojtek
wojtek
Użytkownik "Wojtek pBT" <ba...@wp.pl> napisał w wiadomości
news:c7jj6v$bc0$2...@absinth.dialog.net.pl...
> może i ja się dorzucę ;)
> Może Alter table, a już dobrze by było [INNER | LEFT] JOIN.
alter table?? hmm nie za bardzo rozumiem
> Może sortowanie, i przedewszystkim WHERE. Cielawi mnie czy waro
> maltretowac bazę LIKE
> ps: Opublikowałeś gdzieś te dane, prucz grupy??
> pBT
te testy sa bardzo amatorskie, w zasadzie to zalezalo mi na tym, jak bazy
danych radza sobie z miare duzymi tabelami
bo jak dla mnie 5 milionow wierszy to juz jest duzo.
Test mial na celu porownanie Firebirda 1.5 z Postgresem poniewaz obie sa
calkowicie bezplatne
Wydaje mi sie, ze ogolnie Postgres jest lepszy (szybszy), juz nie moge sie
doczekac oficjalnej wersji na windowsa
pozdrawiam
wojtek
Adam Buraczewski
> A czy te testy mozna rozwniez wykonac na bazach niekomercyjnych? np
> Postgresql,
> Firebird i MySQL (przy zalozeniu, ze tez jest niekomercyjna) ?
Tak, obejrzyj sobie linki:
http://osdb.sourceforge.net/
http://sourceforge.net/projects/osdldbt
http://www.osdl.net/projects/performance
Te testy są wykorzystywane m.in. przez deweloperów Postgresa do oceny
zmian w jego wydajności w kolejnych wersjach.
Pozdrawiam!
--
Adam Buraczewski <adamb (at) nor (dot) pl> * Linux user #165585
GCS/TW d- s-:+>+:- a C+++(++++) UL++++$ P++ L++++ E++ W+ N++ o? K w--
O M- V- PS+ !PE Y PGP+ t+ 5 X+ R tv- b+ DI D G++ e+++>++++ h r+>++ y?
Wojtek pBT
> alter table?? hmm nie za bardzo rozumiem
odjęcie kolumny, zmiana typu kolumny...
>
>
> te testy sa bardzo amatorskie, w zasadzie to zalezalo mi na tym, jak bazy
> danych radza sobie z miare duzymi tabelami
> bo jak dla mnie 5 milionow wierszy to juz jest duzo.
Jeżeli jeszcze masz, mógłbyś podać strukturę tabel, bo sam bym chętnie
wykonał kilka testów. A jakoś niespecjalnie wiem, co dawać do takich
tabel...
Wojtek
"Paweł O."
> A czy te testy mozna rozwniez wykonac na bazach niekomercyjnych? np
> Postgresql,
> Firebird i MySQL (przy zalozeniu, ze tez jest niekomercyjna) ?
Można, chociaż co dla MySQL będzie to pewnie nieco trudniejsze
(specyfikacja TPC-C wymaga zaimplementowania 5 procedur składowanych
realizujących transakcje, a obecna wersja produkcyjna MySQL zdaje się,
że ich nie obsługuje). W sieci dostępne są implementacje testów opartych
na TPC-C i TPC-H (o czym pisał już kolega Adam Buraczewski), które nieco
się różnią od testów oryginalnych (dokładna implementacja jest dość
czasochłonna), ale nie znam szczegółów tych implementacji. Dodatkowo
polecam wizytę na www.tpc.org
Pozdrawiam,
Paweł O.
Przemyslaw Popielarski
> testowane bazy danych:
> - MySQL 3.23.56nt
Ale czemu wziales jakas wersje przedpotopową? Toż MySQL v4 przeciez od
ponad roku jest dostepna w wersji produkcyjnej.
--
./ premax
./ premax@hot,pl
./ koniec i bomba, a kto czytal ten traba. w.g.
wojtek
Użytkownik "Przemyslaw Popielarski" <pre...@hot.pl> napisał w wiadomości
news:409e39c3$1...@news.home.net.pl...
> wojtek <woj...@BEZTEGOpulpit.pl> wrote:
> > testowane bazy danych:
> > - MySQL 3.23.56nt
>
> Ale czemu wziales jakas wersje przedpotopową? Toż MySQL v4 przeciez od
> ponad roku jest dostepna w wersji produkcyjnej.
>
Oracle 8 tez jest przedpotopowy
nie za bardzo korzystam na codzien z MySQL, a akurat taka wersje mialem
zainstalowana
pozdrawiam
wojtek
Filip Sielimowicz
Użytkownik "Paweł" <pa...@poczta.onet.pl> napisał w wiadomości
news:c7jfo0$kn5$1...@topaz.icpnet.pl...
TPC-H na 900 MB ? Czy to trochę nie za mało na hurtownię danych ?
Ale generalnie: czy można by nieśmiało prosić o te wyniki (na priv'a, jeśli nie
publicznie) ?
I taka uwaga dodatkowa: wydaje mi się, że test TPC-C nie sprawdza spustoszenia,
jakie może wywołać źle zaprojektowany system blokowania rekordów. Same transakcje
mogą chodzić szybko, ale w sytuacji, gdy chcemy uzyskać odpowiedni poziom izolacji
i w czasie pracy w przeważającej mierze transakcyjnej puszczamy "drobne" raporty
wyciągające dane zagregowane to może się okazać, że czas wykonywania takiego
raportu jest nieproporcjonalnie duży lub wpływa znacznie na czas wydłużenia
trwania samych transakcji modyfikujących. Albo nie ma odpowiedniej izolacji i
zwrócony w raporcie wynik jest niespójny - np. uwzględnia po części transakcje
zatwierdzone już w trakcie jego generowania.
Paweł
> TPC-H na 900 MB ? Czy to trochę nie za mało na hurtownię danych ?
Na pewno za mało. Ale miałem niewiele czasu na te testy, a generowanie
bazy o takim rozmiarze i tak trochę trwa...
> Ale generalnie: czy można by nieśmiało prosić o te wyniki (na priv'a, jeśli nie
> publicznie) ?
Publicznie to raczej nie z bardzo prozaicznego powodu. Nie miałem czasu
na dokładne dostrojenie baz danych (właściwie zrobiłem to bardzo
pobieżnie), a ponadto moja implementacja transakcji na pewno nie jest
optymalna. W związku z tym nie chcę się narażać na (z pewnością
uzasadnione) ataki grupowiczów preferujących którąkolwiek z
porównywanych SZBD. Wyślę Ci wyniki na priv po pracy :)
> I taka uwaga dodatkowa: wydaje mi się, że test TPC-C nie sprawdza spustoszenia,
> jakie może wywołać źle zaprojektowany system blokowania rekordów. Same transakcje
> mogą chodzić szybko, ale w sytuacji, gdy chcemy uzyskać odpowiedni poziom izolacji
> i w czasie pracy w przeważającej mierze transakcyjnej puszczamy "drobne" raporty
> wyciągające dane zagregowane to może się okazać, że czas wykonywania takiego
> raportu jest nieproporcjonalnie duży lub wpływa znacznie na czas wydłużenia
> trwania samych transakcji modyfikujących. Albo nie ma odpowiedniej izolacji i
> zwrócony w raporcie wynik jest niespójny - np. uwzględnia po części transakcje
> zatwierdzone już w trakcie jego generowania.
Tymi sprawami zajmowałem się już jakiś czas temu, ale z tego co
pamiętam, to w TPC-C ten temat jest też odpowiednio potraktowany. Jedna
z transakcji to właśnie taki raport, który jakośtam agreguje dane. Pełna
specyfikacja TPC-C zakłada nawet przeprowadzenie testów, które udowodnią
izolację transakcji. Ja na to (testy izolacji) nie miałem czasu, ale
ustawiłem dość restrykcyjne poziomy izolacji transakcji w procedurach
składowanych (więc na pewno spełniłem założenia TPC-C), co odbiło się na
rezultatach (np. zakleszczenia przy eskalacji blokad, które znacznie
obniżają osiągi SZBD).
Pozdrawiam,
Paweł O.
Robert Grabowski
> Witam
> Zainpirowany testami przeprowadzonymi przez Roberta Grabowskiego
> postanowilem
> zrobic zestawienie wybranych baz danych (akurat takie mam u siebie na
> komputerze)
> Testowalem na komputerze
> AMDXP 2GHz, FBS 100MHz, 768 MB ram, HDD 80GB Seagate Barracuda
> system operacyjny WinXP
>
> testowane bazy danych:
> - MySQL 3.23.56nt
> - PostgreSQL 7.5 devel win
> - Firebird 1.5
> - Oracle 8
> - Pervasive 8.5 Workgroup
>
> Na kazdej z baz danych utworzylem prosta tabele z 5 milionami rekordow (na
> kazdej te same dane)
> Wyniki:
> SELECT count(*) FROM test;
> 1. Mysql - 0.00s
> 2. Pervasive - 0.00s
> 3. Firebird - 8.70s
> 4. Pgsql - 9.19s
> 5. Oracle - 13.42s
>
MySQL i Pervasive "wiedzą" ile mają rekordów w tabeli, więc nie muszą
ich liczyć. Stąd te czasy. Dodaj jakiś warunek where. Co do Oracle, to
ja testowałem takie zapytanie w wersji Oracle 9i i wyszło mi, że jest 4
razy szybszy niż PostgreSQL.
> SELECT nazwa, count(*) FROM test GROUP BY nazwa;
> 1. Oracle - 14.82s
> 2. Pgsql - 17.83s
> 3. Mysql - 32.61
> 4. Firebird - 45.58
> 5. Pervasive - 3m37s
>
Tu widać, jak Pervasive dostaje po dupie. Aktualnie trochę pracuję z tą
bazę i uważam, że jest to najgorsza baza SQL'owa z jaką pracowałem. Jest
strasznie wolna, ma chore ograniczenia składni SQL'a -- uniony to
koszmar. Nie polecam. Pervasive powstał chyba tylko dlatego, że jest
jeszcze trochę aplikacji Btriev'owych.
> SELECT nazwa, opis, count(*) FROM test GROUP BY nazwa, opis;
> 1.Oracle - 16.54s
> 2. Pgsql - 25.55s
> 3. Mysql - 1m21s
> 4. Firebird - 5m57s
> 5. Pervasive - 13m25s
>
Nie wiem, ile dałeś sort_mem w PostgreSQL'u ... Być może wyniki były by
lepsze.
> DELETE FROM test;
> 1. Mysql - 0.02s
> 2. Pgsql - 2m12s
> 3. Firebird - 4m58s
> 4. Pervasive - 8m02s
> 5. Oracle - ? (problemy z RBS)
>
MySQL po prostu zrobił truncate tabeli. Inne bazy ze względu na
transakcje musiały przelecieć po całych tabelach i stąd ten wynik.
> Pewnie zabrakło tutaj wiele innych zapytań które nalezalo by przetestować,
> ale przyznam, ze przeprowadznie takich testow
> jest badzo czasochlonne, glownie generowanie danych.
>
>
Najlepsze zapytania wychodzą w trakcie pracy nad dużym projektem, ale
wtedy nie ma czasu, aby przenościć całą (czasami ogromną) strukturę bazy
na inny serwer i robić testy.
pozdrawiam
Robert Grabowski