Temat wydajności tych czy innych silników baz danych był już wielokrotnie poruszany na stronach i blogach. Testy, na które się dotychczas natknąłem nie były zbyt wartościowe. Raz MySQL wygrywał, raz PostgreSQL. W dodatku każda dyskusja na temat MySQL konta PostgreSQL wywoływała wiele niepotrzebnych emocji.
Natknąłem się jednak na ciekawy wpis na blogu działu IT serwisu grono.net. Cytat:
"W chwili obecnej caÅ‚ość dziaÅ‚a już na PostgreSQLu, dziaÅ‚a Å‚adnie i szybko. Load maszyny z PostgreSQLem jest okoÅ‚o 3-krotnie niższy niż load maszyny z MySQL’ em (przy tym samym obciążeniu).”
Podano mało informacji na temat zawartości, jednak z profilu serwisu można się domyślać, że najczęstsze operacje to SELECT, a potem INSERT. Ilość danych to 60GB w 150 mln rekordach.
Całość na IT blogu grono.net.
5 responses so far ↓
Nowaker // grudnia 18, 2007 at 12:46
Tak sobie rozmyÅ›lam na temat tego 3-krotnie mniejszego load’a w PostgreSQL-u. Brakuje mi tutaj jeszcze jednej rzeczy - ilość req/s na MySQL-u i Postgresie. Być może MySQL, choć powoduje wiÄ™kszy load, wykonuje operacje szybciej?
Jest to możliwe - natknąłem się niedawno na test frameworków, gdzie podane były zarówno load, jak i req/s. Wynik: część frameworków miała więcej req/s kosztem większego loadu.
Zyx // stycznia 7, 2008 at 22:38
Nie dziwię się takiemu wnioskowi - istnieje całkiem sporo algorytmów, które można przyspieszyć kosztem większego zużycia pamięci i vice versa. Wiąże się to z możliwością zapamiętania wyników części obliczeń i ich późniejszego spożytkowania do pominięcia części kroków.
Nowaker // stycznia 10, 2008 at 20:20
Dlatego też dokonam testu - zbadam zarówno req/s, jak i load. Wyniki wkrótce.
MaKARON // lutego 8, 2008 at 11:14
Niestety porównanywane były dwa różne systemy - w postgresie baza
została podzielona na 3 tabele, zamiast dwóch. W moim (niedużym)
systemie rss’ów (>2mln wiadomoÅ›ci) rozdzielenie pól o staÅ‚ej
długości od tych o zmiennej przyspieszyło MySQL kilkukrotnie.
Porównanie zatem jest kompletnie bezsensowne.
Nowaker // lutego 8, 2008 at 16:41
Dzięki za komentarz. Skąd masz informację, że podzielone to zostało właśnie w taki sposób? (varchar -> char)
Leave a Comment