kwietnia 04

Do napisania czegoś o mysql skłoniły mnie dwie rzeczy. Były to dwie migracje. Jedna z mysql 5.0 do mysql 5.1 i migracja z PostgreSQL 8.1 do 8.3 jakie wykonałem kilka dni temu. Zacznę może od tego co zaskoczyło mnie bardzo pozytywnie. Czyli migracja do Postgresa 8.3 .

Nigdy nie ukrywałem że jestem fanem postgresa,  a mysql nie jest dla mnie prawdziwą bazą danych. Jednak postgres miał pewną wadę. Była nią słaba wydajność. Oczywiście w porównaniu tego co działo się podczas wykonywania transakcji w postgresql, a mysql nie dziwiła mnie ta różnica. MySql nie jest w 100% zgodny ze standardem SQL i wiele rzeczy, zwłaszcza w tablicach MyISAM idzie po prostu “na skróty”.
Po testowej instalacji wersji 8.3 zauważyłem sporą różnice w wydajności zapytań. Skrypt który na poprzedniej wersji działał cztery godziny na nowej wersji skończył pracę w 45 minut. Oczywiście częściowo zasługą mogło być to że importowałem na nowo bazę więc znalazła się na niepofragmentowanej części dysku. Kolejny skrypt zamiast w 8 godzin skończył w 2. To już nie był przypadek. Pamiętam że kiedyś wybrałem mysql na hurtownie danych bo zapytania kończyły pracę po około 50% czasu który na te same zapytania potrzebował PostgreSQL. Czyżby wychodziło na to że Mysql nie był już najszybszy? Według innych testów które znalazłem autorzy mówili o ponad dwukrotnym przyspieszeniu pracy co potwierdzało to co sam zauważyłem.
Później szukając trochę w necie trafiłem na tego pdf’a , gdzie autor dokonał porównania mysql i postgresql na maszynach wielordzeniowych i wychodzi na to że postgresql jest szybszy od mysql, a przewaga rośnie wraz z liczbą współbieżnych zapytań i liczbą rdzeni procesora.
Skąd ten wzrost wydajności?  Postgres kulał z pewnością przez duży narzut danych jakie robił na tabele. Bo wiadomo że czym więcej dodatkowych danych należy odczytać z dysku by przeczytać ten sam rekord tym gorzej. W wersji 8.3 nastąpiła duża redukcja rozmiaru bazy. Z rzeczy które na pewno mają też duży wpływ na pracę bazy jest optymalizacja sortowania w zapytaniu i synchroniczne skany danych, czyli wiele sesji używa tego samego buffora dysku podczas skanowania.
Ciekawą nową opcją są też mini VACUUMs. Bloki tabel mogą czyścić się same bez konieczności przeprowadzania pełnej operacji vacuum na całej tabeli.
Dla mnie najbardziej przydatną funkcją było załączenie wyszukiwania pełnotekstowego Tsearch2, dzięki któremu odpadało już użycie sphinx‘a o którym pisałem wcześniej.
Miłym zaskoczeniem było również to że migracja wielu baz, których obciązenie to często kilkaset zapytań na sekunde odbyła się właściwie bez problemu. Jedyny kłopot sprawiły moje błędy w zapytaniach porównujące liczby i wyrażenia tekstowe które nie są już tolerowane przez postgresa 8.3.
Musiałem spędzić trochę czasu analizując logi i szybko poprawiając kwiatki w stylu id <> ” , czy tabla.nazwa=123 ponieważ w nowym postgresie takie rzeczy nie przechodzą. String to string, a liczba to liczba.

Drugi upgrade z mysql 5.0 do 5.1, który nie poszedł niestety tak gładko. Baza która pracowała na mysql ma do kilku tysięcy requestów na sekundę i właściwie wszystko działało na niej w miarę sprawnie. Po migracji nagle umarła po dwóch godzinach. Na tabelach pojawiły się niezliczone ilości locków i baza stanęła. Po restarcie podobny efekt , za każdym razem po około dwóch godzinach.
Okazało się że nie jesteśmy pierwszymi osobami, które borykają się z takim problemem. Co gorsze,  nie został on rozwiązany od kilku miesięcy. Jedynym rozwiązaniem jest wyłączenie query cache. Sorry ale jeżeli wersja Mysql 5.1 jest wersją rekomendowaną i przez tak długi czas posiada w sobie takie błędy to ja przestaje mieć ochotę na developowanie jakiegokolwiek softu w oparciu o to rozwiązanie. Do tego wyłączenie query cache pomogło o tyle że baza wieszała się rzadziej i po 2-3 minutach przestoju była w stanie odwiesić się sama. Myślę że takie rozwiązanie nie satysfakcjonowało by nikogo, bo kto chciałby mieć serwis który staje kilka razy dziennie na kilka minut. Wykonaliśmy migrację do wersji 5.0 i problemy zniknęły . W międzyczasie naczytałem się na forach dyskusyjnych o ludziach którzy mieli podobne problemy na bazach o większym obciążeniu i wszyscy odradzali migracje do wersji 5.1 .
Do tego co jakiś czas czytam artykuły o tym jak to ważni developerzy odchodzą z projektu MySQL.  Myślę, że widać to już w jakości wersji 5.1 . Miejmy nadzieje że nie spaprają niczego poważnego w wersji 5.0 i przyjdzie nam się jeszcze nią trochę pocieszyć by aplikacje które już zostały na niej rozwinięte mogły pracować w spokoju jak najdłużej. Wiem że zaraz pojawią się ludzie którzy będą twierdzić, że mają 5.1 i działa spoko, a to ja się nie znam. Tylko ja mówię o bazach które mają kilka tysięcy requestów na sekundę a nie kilka tysięcy requestów dziennie. Według mnie baza przy tak dużym obciążeniu nie radzi sobie w zarządzaniu lockami co pewnie przy mniej wydajnej pracy jest zupełnie niezauważalne. Rozumiem też że błędy w różnych programach się zdarzają, ale błędy takiego kalibru powinny być rozwiązywane natychmiastowo i maksymalnie w ciągu kilku dni powinna się pojawiać nowa wersja albo chociaż patch.

Porównując mysql i postgresa należy też powiedzieć kilka słów o licencji, bo pomijając wszystkie aspekty techniczne to PostgreSQL oparty jest o licencje BSD co umożliwia wydawanie programów wymagających użycia Postgresa również komercyjnie bez żadnych problemów, w Przypadku Mysqł licencja jest podwójna. Można używać mysql do projektów jeżeli opublikujemy je na licencji GPL, lub zapłacić jeżeli chcemy projekt oparty o mysql sprzedać klientowi i nie udostępniać kodu źródłowego.

Jak dla mnie po rozwiązaniu problemów z wydajnością PostgreSQL w wersji 8.3 nie ma już żadnych racjonalnych powodów by rozwijać oprogramowanie w czymś innym niż PostgreSQL. Od wersji 8 Postgres jest również portowany na Windowsa. Posiada przewagę w umowie licencyjnej, o wiele większą funkcjonalność i lepszą stabilnośc. Postgres to taki prawie Oracle, tylko że za free. A w przypadku MySQL dokumentacja na ich stronie jak migrować z Oracla do MySQL brzmi jak prima aprilisowy żart. Do tej pory udało mi się już przekonać kilka osób do przejścia na Postgresa i mam nadzieje że przekonam kolejne osoby, co teraz powinno iść dużo łątwiej :)

18 Responses to “Postgres 8.3 – początek końca mysql’a ?”

  1. Ziom Says:

    Jestem ciekaw, czy ta migracja z 5.0 do 5.1 była Ci rzeczywiście potrzebna? Masz aż tak skomplikowane zapytania, by to było konieczne? Ja generalnie jestem zwolennikiem upraszczania funkcjonalności by nie trzeba było korzystać z najnowszych baz.

  2. Fus Says:

    Bardzo subiektywny post. Nie podałeś żadnych konkretnych informacji, ustawień konfiguracyjnych na których testowałes bazy itp.. Strzelam, że Twoje problemy z wydajnością postgresa były spowodowane jego domyślnym konfigiem.

    “Postgres to taki prawie Oracle, tylko że za free.” PRAWIE robi wielką różnicę.

    Sam nie przepadam za MySQL, ale ma kilka zalet – `super tanie hostingi` mają je w swej ofercie. Jest sporo ludzi, którzy używają takiego śmiesznego systemu operacyjnego, na którym do niedawna instalacja postgresa była ciężka – takich ludzi /developerow/ wcześniej mogła ta wada ostraszyć.

    PS. “podczas wykonywania tranzakcji w postgresql”… a nie tranSakcji? Jak można traktować taki post poważnie? :)

  3. s Says:

    napisz sobie wlasny storage engine do mysql’a pod konkretne rozwiazanie przechowywania danych, a zobaczysz ze oracle i wszystkie inne bazy sa do niczego, a mysql smiga jak burza.

  4. mt3o Says:

    Jest jeden mały, a zasadniczy powód popularności MySQLa, przynajmniej w Polsce – ceny. Hosting z MySQLem u wiodącego dostawcy jest tańszy niż z PostgreSQLem.

  5. Bartosz Says:

    Aby kogoś przekonać, najlepiej jakbyś podał jakiś link do artykułu na temat różnic pomiędzy MySQL i Postgresa. Albo jakiś ogólny poradnik na temat Postgresa. Bo przekononywać ludzi trzeba juz od początku. Jak zaczynają się bawić w programowanie :)

  6. admin Says:

    @Fus – a gdzie ja napisałem że miałem problemy z postgresem? no i nie żartuj z tą domyślną konfiguracją bo ona nie pociągnie kilkuset zapytań na sekunde. Ustawienia były takie same:
    shared_buffers = 1024MB
    work_mem = 8MB
    maintenance_work_mem = 256MB
    random_page_cost = 2.5
    effective_cache_size = 2048MB
    reszta parametrów już nie jest taka istotna

    a co do wyboru bazy bo hosting jest tani, no to sorry. Dedykowane serwery też są już tanie i można na nich postawić o wiele więcej serwisów niż na “tanich hostingach” za te same pieniądze.

    @Zion – chciałem przejść na 5.1 bo mysql zalecał migracje od dłuższego czasu, dla mnie to wystarczający powód. Wersja jest ponad rok, producent ją zaleca i twierdzi że jest 15% szybsza.

  7. gregj Says:

    przyspieszenie ktore zauwazasz, to zmiana w sposobie obslugi dysku. Postgres juz nie zapisuje dirty-blockow w calosci (evict), zapisuje na dysku tylko to co sie zmienia.
    Co do porownania, porownywanie myisam z postgresem, to jak porownywanie dosa z uniksem, po odpaleniu go na 64 procesorowym systemie. wybacz, ale nie tedy droga :)
    Co prawda, pewne inne rzeczy sie zmienily pomiedzy wersjami – ale to co podajesz jako przyczyne przyspieszenia, wcale nia nie jest.
    A teraz jeszcze sciagnij sobie 8.4 beta, jak wyjdzie, i przetestuj 😉 Szczegolnie jesli masz maciez, a system na ktorym to uruchamiasz wspiera ‘posix fadvise’.

  8. Jarek Says:

    Do Oracla to chyba daleko, wątpie czy Postgres ma np. coś takiego jak funkcje analityczne (PARTITION BY, LEAD, LAG .. OVER BY() i inne).

  9. Olek Says:

    Od wersji 8.4 postgres juz to ma :)
    http://www.depesz.com/index.php/2009/01/21/waiting-for-84-window-functions/

  10. MrMgr Says:

    Gwoździem do trumny mySQL będzie przejście WordPressa i Joomli na PostgreSQL puki to się nie stanie mqSQL będzie miał się dobrze.

  11. BlackWeb Says:

    Muszę pochwalić post. Co prawda jest parę niedociągnięć, które zaprezentowano w powyższych komentarzach, lecz… mimo wszystko dało mi do myślenia. Zrobię parę eksperymentów na moich ‘farmach’, najłatwiej będzie porównać przy wydajności na kilku tysiącach artykułów.

  12. mp Says:

    Bardzo fajny post, dzięki 😉

  13. tc Says:

    Sam troche teraz przetestowalem te szybkosci i jestem zaskoczony – przy prostej operacji z grupowaniem na niecalych 2mln rekordow, postgres zwrocil mi wynik po 1min i 28 sek, a mysql po 6 min i 11 sek.

  14. Michał Says:

    Tego postu nie da się czytać! Merytorycznie miałkie stwierdzenia, już w pierwszym zdaniu rażący błąd gramatyczny, całość brzmi jak przeżycia emo-nastolatki na blogasku. Klikając na wykopie w ten artykuł spodziewałem się czegoś odkrywczego, a trafiłem na zlepek nic nie wartych wynurzeń, nie popartych obiektywnymi argumentami.

    Skąd takie rzeczy biorą się na wykopie?!

  15. Adder Says:

    Wszystko zależy od zastosowania, typów itp. Efektywność może być różna. Jednak rzeczywiście postgre jest potrzebny – konkurencja = rozwój :)

  16. zbiju Says:

    skoro skrypty ktory meczyly baze przez 8h koncza po 2h teraz, to cos w tym musi byc :)

  17. admin Says:

    @Michał – tego komentarza nie da się czytać. Zlepek złośliwości i szukania dziury w całym. Napisz lepszy artykuł, wrzuć do niego linka to porozmawiamy.

  18. Łukasz Dywicki Says:

    “Do Oracla to chyba daleko, wątpie czy Postgres ma np. coś takiego jak funkcje analityczne (PARTITION BY, LEAD, LAG .. OVER BY() i inne).”

    Na bazie PostgreSQL jest zbudowany projekt Enterprise DB (
    http://www.enterprisedb.com/), który gwarantuje zgodność z Oracle. :-)
    I kosztuje mniej :-)

Leave a Reply

Preview: