PostgreSQL vs MySQL vs MSSQL2K
Posted by Jarosław Zabiełło Mon, 02 Apr 2007 15:14:00 GMT
Zawsze dziwiłem się dlaczego aplikacje komunikujące się z MSSQL chodzą tak niemrawo. Zrobiłem sobie szybki test szybkości. Na tym samym komputerze zainstalowałem: MSSQL 2000 SP4, MySQL 5.0.27 i PostgreSQL 8.2.3. Zadanie było proste, pobrać listę tabel w bazie.
Użyto następującego kodu w Pythonie:
import adodbapi, MySQLdb, odbc, psycopg2, time
conn = [
( 'mysql', MySQLdb.connect(user='root', db='test'), 'SHOW TABLES'),
('pgsql', psycopg2.connect("user='postgres' password='test''"), 'SELECT * FROM pg_tables jdb273'),
('mssql ado', adodbapi.connect('Provider=SQLNCLI.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=test'), 'EXEC sp_tables'),
('mssql odbc', odbc.odbc('DRIVER={SQL Server};SERVER=localhost;DATABASE=test;UID=sa;PWD=test'), 'EXEC sp_tables'),
]
def test(repeat=100):
for c in conn:
dbtype, db, sql = c
print dbtype,
t = time.time()
for i in range(repeat):
cursor = db.cursor()
cursor.execute(sql)
rows = cursor.fetchall()
cursor.close()
print '%d req/s' % round(repeat / (time.time() - t))
if __name__ == '__main__':
test()Użyta konfiguracja:
- WinXP Pro 2000 SP2, P4 3.2GHz, 1GB RAM.
- Python 2.5
- MySQL v5.0. 27, driver: MySQLdb v1.2.2
- PostgreSQL v8.2.3, driver: psycopg2 v2.0.6b1 (dec dt ext pq3)
- MSSQL 2000 SP4, driver: ADO
Wyniki:
C:\home\app\bench\scripts>bench_db.py
mysql 457 req/s
pgsql 581 req/s
mssql ado 6 req/s
mssql odbc 9 req/s
C:\home\app\bench\scripts>bench_db.py
mysql 457 req/s
pgsql 581 req/s
mssql ado 9 req/s
mssql odbc 10 req/s
C:\home\app\bench\scripts>bench_db.py
mysql 457 req/s
pgsql 578 req/s
mssql ado 9 req/s
mssql odbc 11 req/s
C:\home\app\bench\scripts>bench_db.py
mysql 457 req/s
pgsql 581 req/s
mssql ado 8 req/s
mssql odbc 11 req/s
C:\home\app\bench\scripts>bench_db.py
mysql 455 req/s
pgsql 641 req/s
mssql ado 9 req/s
mssql odbc 10 req/sMit o rzekomej szybkości MySQL już jest nieaktualny. Nowy PostgreSQL 8 bije go pod każdym względem. Zarówno wydajnościowo i jak i znacznie większymi mozliwościami (o tym może kiedy indziej). Dziwi słaba, a raczej nędzna, wydajność produktu firmy Microsoft. Nie sprawdzałem nowego MSSQL 2005, ale wszystko wskazuje na to, że przynajmniej MSSQL2K to kompletne dno!
Subskrypcja kanału RSS
Kanały IRC![[Dilber w Onecie]](/images/larry.png)
Ten test powinien używać w połączeniach dla MySQL i PostgreSQL używać także adodb, w celu wyeliminowania problemów z tymże właśnie. Po teście nie widać, czy to adodb ssie na maksa, czy też coś innego.
Test jest delikatnie mówiąc skopany. Na maszynie z 2GB ramu wrzuca się do bazy 10GB danych i zadaje równolegle zapytania. Wtedy patrzymy ile sesji na raz wytrzyma serwer …
nie bierzesz pod uwagę, że pobranie listy tabel może być zupełnie inaczej zaimplementowane w różnych bazach (co zresztą widać: w PSQL i MySQL jest to prosty select, w MSSQL jakaś procedura – cholera wie, co ona robi).
nie zdziwiłbym się też, gdyby się okazało, że “pusta” baza MSSQL zawiera masę tabel systemowych albo założonych na zapas przez instalera.
poza tym pobieranie listy tabel to nie jest typowa operacja, jaką wykonują aplikacje. IMHO test byłby wiarygodniejszy, gdybyś w tych bazach założył w miare sensowne tabele z w miare sensowną zawartością, pozakładał indeksy i wtedy porównywał.
Winna jest strasznie gruba warstwa sterowników i nietypowe zapytanie.
Działałem kiedyś sporo na styku .NET-a i MSSQL-a (ORM) i w moim przekonaniu jest to bardzo szybki i inteligentny DBMS.
Przedpiszcy maja rację. Ten test niczego nie dowodzi. Tak właściwie ten test to nie test.
Po raz kolejny widzę tu kolejny “test wydajnościowy” przez który autor bloga traci wiele w moich hax0rskich oczach ;)
Przynajmniej się ubawiłem ;)
Przecież jasne że nie jest to wyczerpujący test, tylko mała próbka. Ja bym nie bagatelizował tego że MSSQL jest tu wolniejszy od PostgreSQL 50-60 razy!
Moim zdaniem by ten test mial jakikolwiek sens (pomijam sensownosc testowania listowania tabel) powinienes uzyc http://pymssql.sourceforge.net/.
>Moze Szanowny Autor mieszka w strefie czasowej w której wciąż jest 1.IV? Mars?
To chyba nie jest najlepszy pomysł na benchmark. Dowodzi jedynie tego, że pewna, dość specyficzna operacja jest inaczej zaimplementowana w różnych bazach danych.
Co do MS SQL – te liczby brzmią bardzo niewiarygodnie :) Wstukałem do Google’a ‘mssql return a list of tables’ i dostałem kilka różnych sposobów wyciągania listy tabel. Może warto spróbować różnych? MS SQL to bardzo przyzwoita baza danych i nie uwierzę że jest aż tak powolna.
hax0r: jak nie wierzysz to sobie sam odpal ten skrypt. Kod masz. Nie moja wina że mssql tak nędznie wypada. Później przygotuję mniej trywialny test.
Tak, jeśli będę chciał sprawdzać kilkaset razy na sekundę jakie tabele mam w bazie, a nie odczytywać zawarte w nich dane, to zdecydowanie wybiorę… lol, powiedz, że to z okazji 1.IV?
LOL. A może jakieś konkretne zapytania? Bardziej skomplikowane joiny z warunkami, grupowaniem etc. Jestem na 80% pewny, że MSSQL wypadnie bardzo dobrze.
rsz: A masz coś może bardziej konkretnego poza samą wiarą w MSSQL’a? Np. jakiś przykładowy dump i kwerendy które by można zapuścić na tych trzech bazach?
Nic nie mówi ten test. Pobieranie listy tabel to operacja używana niezbyt często i nie stanowiąca jakiegoś bardziej krytycznego kryterium. Na tej podstawie możnaby wywnioskować, że np. Oracle czy DB2 są niewydajne a to przecież nieprawda. Równie dobrze możnaby sprawdzać np. ile trwa uruchamianie usług danego DBMS czy np. nawiązanie połączenia. Bardziej miarodajny byłby test, np. wstawiający milion krotek w pętli, przy pomocy różnych interfejsów (ODBC, .NET itd.). Następnie kilka milionów update, delete w równoległych sesjach. Wtedy możnaby próbować wygenerować jakieś statystyki i próbować analizować. Aha, tak na koniec – nie podejmowałbym się testów porównawczych nie prosząc człowieka znającego przyzwoicie dany silnik i nie prosząc o tunning. Źle ustawiony MSSQL potrafi być wolniejszy od dobrze ustawionego PostgreSQL-a i na odwrót. Defaultowo nie znaczy dobrze.
Ronald Kuczek: Rozumiem, że tuning jest ważny, ale jak widzę różnicę rzędu 60x to nie za bardzo wierzę iż tunning wywróci taką proporcję do góry nogami. Faktycznie lepiej byłoby sprawdzić czytanie rekordów. Może przygotuję jakiś prosty kod – ale to wszystko, bo nie mam czasu na dokładną analizę ani żadne tuningi. (btw, mam pewną hipotezę dlaczego to mogło mi to działać tak wolno, ale o tym później). Zamiast mnie tu napadać, niech ktoś lepiej sam zrobi bardziej profesjonalne porównanie.
Jarku, nikt nie napada. Robiłem niejeden projekt i przeprowadzałem dobór bazy. Raz lepszy był Firebird, innym razem PostgreSQL a w jeszcze innym wypadku MSSQL. Chciałem Ci jedynie powiedzieć, abyś nie wyciągał pochopnych wniosków. Warto posiedzieć nad benchmarkiem bo jak projekt już się zacznie trudno będzie raz dokonany wybór zmienić. Zazwyczaj pisałem programy testowe działające na zaprojektowanej strukturze tabel (zbliżonej do tej ostatecznej, zaakceptowanej w projekcie). Po testach trwających co najmniej kilka dni dla jednej bazy – analizowałem zebrane statystyki i wyciągałem wnioski. Tylko tak przekonałem się np., że w przypadku PostgreSQL i dostępu przez .NET lepiej użyć komercyjnego sterownika crlab (najszybszy) lub npgsql (porównywalny, ale wolniejszy o jakieś 25%)niż np. ODBC (różnica w wydajności około trzykrotna). Okazało się też przy .NET MSSQL jest szybszy od PostgreSQl, ale w przypadku użycia natywnych interfejsów różnica nie była już tak oczywista. Oracle działał po ODBC o wiele wolniej niż przy użyciu napisanego wrappera na OCI itd.
Dlaczego do testow uzyles najnowszych wersji mysqla i postgresqla oraz jakies muzealnej wersji mssql? Nie lepiej byloby wziac mssql 2k5? albo jakis mysql 3? kilka lat czasu miedzy wydaniami silnikow jednak swoje robi.
Muzealny? Chyba trochę przesadasz. Ten MSSQL2K całkiem popularny w wielu firmach i sam go używam na codzień w pracy (oczywiście ma zaplikowany SP4). Powtarzam: dlaczego nikt z was nie ruszy dupy i nie napisze solidniejszych testów zamiast marudzić i ronić tu krokodyle łzy? Takie trudne, czy co?
Jarku, To Ty powinieneć użyć Mocy i napisać solidniejszy test. Skąd mamy wiedzieć jak ma wyglądać docelowa platforma, jakie interfejsy, obciążenie bazy itp ? Napisałem Ci już, programik testowy - napisz pętlę ( w docelowej technologii, cokolwiek to jest): 1. Wstaw po milionie wylosowanych krotek do tabel w zaprojektowanej bazie danych. 2. Wykonaj update na milionie losowych krotek. 3. Usuń milion razy losowe krotki z wybranych tabel. 4. Operacje 1-3 powtórz 10 razy i zapisz czasy. 4. Porównaj statystyki dla różnych silników. Takie to trudne ? Czasochłonne na pewno, ale nie niewykonalne.
To napisz to sam zamiast ściemniać i klepać po próżnicy. Kogo obchodzi jaka platforma jest użyta? A wybierz sobie co chcesz, byle te testy były przeprowadzane na sprzęcie o tej samej mocy, najlepiej tym samym komputerze. Skoro ty kwestionujesz to że mssql okazał się wolny, to wykaż że jest odwrotnie. Onus probandi ciąży po twojej stronie.
Jarosław Zabiełło: Rozumiem, że tuning jest ważny, ale jak widzę różnicę rzędu 60x to nie za bardzo wierzę iż tunning wywróci taką proporcję do góry nogami.
A ja wierzę – np. silnik InnoDB w MySQL jest strasznie wrażliwy na ilość dostępnej pamięci i na domyślnych ustawieniach potrafi się potężnie zamulić. Ostatnio eksperymentowałem na przerośniętej tabeli tokenów spamassassina (jakieś 3 miliony rekordów) – lekki tuning skrócił czas potrzebny na dodanie kolejnego rekordu z 14 (czternastu) do 0.2 sekundy…
Na moje się czepiacie. Nie chodzi o pełny test, super benchmark. Na moje Jarek chciał wykazać jedno: w zakresie pobierania listy tabel, na standardowych konfiguracjach, bez tuningu MSSQL nie wypada za dobrze.
Czy napisał gdzieś, że w związku z tym MSSQL można wyrzucić ? Nie, po prostu w tym aspekcie tak to wygląda. Czy często pobiera się listę table ? Na pewno nie. Tylko co to zmienia, gdy autor napisał “postanowiłem zrobić sobie SZYBKI test”. Gdybanie zostawmy filozofom – zatem jak ktoś może to niech zrobi ten wspomniany test milionokrotkowy i da wyniki. Marudzić każdy potrafi…
@Yar: Jarek napisał “wszystko wskazuje na to, że przynajmniej MSSQL2K to kompletne dno” oraz “łaba, a raczej nędzna, wydajność produktu firmy Microsoft” – to nie brzmi zbyt obiektywnie w kontekście zakresu jego testów, nieprawdaż?
Robert, napisz może jakieś bardziej obiektywne testy zamiast czepiać się moich uwag.
>> rsz said 1 day later: >>@Yar: Jarek napisał “wszystko wskazuje >>na to, że przynajmniej MSSQL2K to >>kompletne dno” oraz “łaba, a raczej >>nędzna, wydajność produktu firmy >>Microsoft” – to nie brzmi zbyt >>obiektywnie w kontekście zakresu jego >>testów, nieprawdaż?
Ja to rozumię w ten sposób: kompletne dno, słaba a raczej nędzna wydajność produkty MS – ale nie całościowo a w zakresie tego miniminitestu – czyli pobierania tabel. No w tym obszarze, rzeczywiście tak to wygląda i nie udowadniajmy co jest wielbłądem. Czy ten test jest supercomperativemegatest ;) ? Nie, na podstawie testu pobierania tabel MSSQL w wersji (fakt że nie najnowszej, ale cały czas dość popularnej) jest bardzo wolny, czyli w tym aspekcie “kompletne dno i nędzna wydajność”. Tak na mój rozum…
Na marginesie – jest tyle innych ciekawych informacji na tym blogu a komentarzy niezbyt wiele; zatem jak rozumię – jak coś jest dobrego i ciekawego wygrzebane przez Jarka to nie ma co komentować (wg zasady Bismarcka – za dobre rzeczy się nie chwali, bo to w pełni normalne i oczekiwane zachowanie, za złe lub niefortunne – od razu można bluzgać). To tylko moje nic nie znaczące zdanie :) Pozdr. dla wszystkich RoRowców :)
Dobra, jak będzie chwila czasu to sprawdzę. Na razie po pół godziny prób skonfigurowania SQL expresa 2005 się poddaję. Nota bene: może ktoś ma jakiś tutorial dla lamerów jak to skonfigurować krok po kroku, tak żeby działało np. z adodbapi?
Niedługo uzupełnię artykuł o troszkę dokładniejsze informacje. Na razie tylko krótka zajawka: ładowanie 37 tys. rekordów za pomocą SQLAlchemy: PostgreSQL=4 min, MSSQL=15 min, MySQL=8 min. Ale sprawdzę to na szybszej maszynie, bo P4 3.2GHz cały czas pracował na 100% i nie wiem na ile to ma wpływ na wyniki.
Jarku, Oprogramowanie porównujące pisałem na własne potrzeby i na własny koszt. Chętnie napiszę Ci takie narzędzie jeśli sprecyzujesz: 1. Schemat testowej bazy danych. 2. Zapytania jakie mają być wykonywane – z zastrzeżeniem – mogę je zoptymalizować pod względem wydajności. 3. Docelowe obciążenie. BTW. nie zgadzam się z Tobą. Platforma (a raczej interfejs) ma kolosalne zdarzenie. Jeśli użyjemy np. ODBC lub .NET PostgreSQL wypadnie na tle MSSQL słabiej niż powinien. Nie jest to winą wspomnianych baz a jedynie implementacji sterowników.
JZ: Mógłbyś wkleić definicję tabeli, której użyłeś do testu? Głównie ciekawią mnie indeksy. No i co do MySQL pytanie: InnoDB czy MyISAM?
Dane były wkładane do tabel bez indeksów (nie licząc pk). Dla MYSQL – InnoDB. Chcę porównać dla różnych bibliotek, np. pymsssql, adodbapi, psycopg2, MySQLdb oraz odbc w każdym przypadku. Struktura tabeli jest prosta, pola typu INT, VARCHAR i TEXT. Wkrótce podam kod i wyniki.
Importowalem olbrzymi schemat z MSSQL do PostgreSQL w sposob automatyczny. Sprowadzalem schemat bazy do pseudo ORM’a a z niego generowalem specyficzny SQL dla postgresa. Stwierdzam ze akurat pobieranie definicji tabel, indeksow, funkcji w MSSQL jest koszmarnie wolne bez wzgledu na zastosowana metode. Taki urok tej bazy. Import kilkuset tabel trwal kilka godzin na Centrino1.4 512MB.
Nie znam pythona. Dodalem do petli dwie linie: print rows print len(rows)
ta pierwsza generuje duzo tekstu dla mssql, ta druga: dla mysql daje 0, dla mssql 296 (tylko te dwie bazy porownalem)
Domyslam sie, ze mssql przesyla wielokrotnie wiecej danych, dlatego taka roznica w ilosci wykonanych zapytan. Podrawiam
Ok. Mam pytanie. Czy moze ktos robil testy w/w baz i porownal MySQL w srodowisku Linux? Mysle ze w/w produkty wypadna bardzo kiepsko oprocz MySQL. Ale napewno wasze kochane produkty pod Win XX sa i jeszcze beda dlugo komercyje. Skad moja zlosliwosc? Moze i MySQL wypada nie znacznie lepiej lub i gorzej, ale czy warto wydac za ta drobna roznice pare set tys zlotych? Mysle ze dalsze testy nie maja wiekszego sensu. Wazne jest ja duza jaest korporacja i jak duza bedzie w przyszlosc oraz jakie ma zasoby finansowe. Sorry ale ja na to patrze pod tym katem. Pozdrawiam i czekam na reprymendy ;-)
Przeglądanie listy tabel to operacja z kategorii refleksji struktury bazy danych – takie operacje z założenia są wolne i w żaden sposób nie optymalizowane. Test, ciekawostka – nic więcej.
Rownie dobrze mozna powiedziec, ze MySQL jest the best bo sie najszybciej sciaga z sieci, a MSSQL trzeba kupic na plytce:) Albo badac czas potrzebny, aby przecietny prawnik zrozumial zapisy licencji kazdej z tych baz.
Niestety MSSQL chodzi tylko z windozą, co w praktyce oznacza że w wypadku aplikacji internetowej pozostaje tylko asp.net, gówniany IIS, ciągłe dziury w systemie i duże koszta hostingu. Dla firm uzależnionych od win32 to nie problem. Ale tylko dla nich.
Pragnę zauważyć, że PostgreSQL lepiej się skaluje przy większej liczbie procesorów. http://tweakers.net/reviews/657/6
hehe, dobry test. Podstawa to DBA przymajmniej przy MySQL. Jakoś do tej pory 4 razy migrując z Postgre na MySQL uzyskiwałem znacznie lepszy performance. Dla mnie to żaden mit. Najpierw trzeba dobrze poznać te dystrybucje, które chce się testować, a potem zamieszczać wyniki. To, że to nie jest takie łatwe świadczy fakt ilości podobnych tekstów o podobnej wartości merytorycznej w sieci.
blee…