blog kris’a

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 🙂