Chwilę temu wspominałem o fakcie, iż MariaDB w wersji 5.3 wprowadziła optymalizacje dotyczące działania podzapytań. Dziś chciałbym podzielić się kilkoma dodatkowymi informacjami na ten temat. Niestety, nie jestem w stanie podać dokładnych cyfr, jako że w tej kwestii obowiązują mnie pewne ograniczenia, ale myślę, że mimo wszystko ten post będzie przydatny.

W ramach jednego ze zleceń miałem wykonać benchmark różnych forków MySQL pod kątem zastosowania ich w produkcji. Zapytania idące do bazy to w głównej mierze pojedyncze, skomplikowane UPDATE/INSERT bądź też ich kombinacje w procedurach składowanych. Praktycznie każde zapytanie w jakiś sposób wykorzystuje podzapytania.

Co się okazało? Podstawową kwestią jest to, że w przypadku gdy nie obsługujemy dużej ilości połączeń, to stosowanie rozwiązań typu Percona Server nie ma większego sensu. W teście Percona Server okazał się wolniejszy od standardowego MySQL 5.5 czasem nawet o kilkanaście procent. Wytłumaczenie jest proste. Percona Server to de facto standardowy MySQL jeśli chodzi o kwestię optimizera. Różnicą jest tylko silnik – XtraDB. Problem w tym, że większość modyfikacji tego silnika ma na celu zwiększenie jego wydajności w przypadku dużej ilości jednoczesnych zapytań. Zauważcie, drodzy Czytelnicy, że w testach prezentowanych przez Perconę widać to wyraźnie – praktycznie wszystkie wykonywane są na kilkunastu (16 dla okrągłej wartości) użytkowników, bądź nawet więcej. Przy takim obciążeniu XtraDB zaczyna pokazywać swoje możliwości. Tak więc, w moim przypadku nie było właściwie żadnego zysku z faktu, że silnik zmienił się z InnoDB na XtraDB. Jak pisałem przed chwilą, Percona Server to, poza silnikiem, standardowy MySQL. Wynika z tego, że jeśli nie da się wykorzystać poprawek w silniku, to tak właściwie to wydajność samego MySQL będzie bez zmian a nawet spadnie. Spadnie bo Percona Server udostępnia dużo dodatkowych informacji o zapytaniach. Do slowlogów trafić może informacja o tabelach tymczasowych, o ilości sprawdzonych rekordów, typie zapytania itp. Zbieranie tych danych generuje oczywiście jakiś tam narzut i zapotrzebowanie na moc procesora.

W przypadku MariaDB sytuacja jest odmienna – także korzysta ona z XtraDB jako silnika bazodanowego, ale w tym przypadku modyfikacje zostały wprowadzone również bezpośrednio w kodzie MySQL i w szczególności w optimizerze. Z jakimi efektami? Łącznie okazało się, że MariaDB, w tym konkretnym przypadku i przy takim a nie innym zestawie zapytań, była szybsza o ok. 10%. Tak na prawdę wyglądało to tak, że wśród testowych 20 różnych zapytań trzy były znacznie szybsze (ok. 30 – 50%) a pozostałe wykonywały się minimalnie wolniej. Dodatkowo, aby uzyskać takie wyniki konieczne były kombinacje z ustawieniami optimizera na poziomie zapytania. Globalne włączenie flag, które przyspieszały te trzy zapytania skutkowało znacznym spowolnieniem wykonywania części innych zapytań. Przydało się to, że @@optimizer_switch można ustawiać także na poziomie konkretnej sesji.

Wniosek, jaki wyciągnąłem z powyższego jest z grubsza taki, że MariaDB to ciekawe rozwiązanie, które potencjalnie może dać sporo przyspieszenia. Niestety, na ten moment, aby uzyskać taki przyrost wydajności, trzeba mieć bardzo specyficzny miks zapytań. W każdym razie, warto spróbować. Druga obserwacja to to, że MySQL z Oracle to całkiem wydajny serwer i nie ma co na siłę przesiadać się na inne rozwiązania. Owszem, często będzie tak że MariaDB czy Percona Server będą szybsze. Trzeba to jednak wcześniej dokładnie sprawdzić i przetestować. Nie ma co przyjmować tego na wiarę.