Aktualizacja

Od roku 2010 trochę się już zmieniło w tej kwestii. Stan obecny (5.6-rc1) najlepiej opisuje poniższy post:
http://dimitrik.free.fr/blog/archives/11-01-2012_11-30-2012.html
W skrócie, InnoDB jest szybsze praktycznie w każdym elemencie. Pora najwyższa zapomnieć o MyISAM. A teraz wracamy do oryginalnego wpisu.

 

Przeglądałem właśnie w Google Analytics statystyki bloga dla ostatniego miesiąca i z tego co widzę, bardzo często zadawane są pytania na temat tego, czy lepszym rozwiązaniem jest zastosowanie InnoDB, czy też jednak MyISAM? Skoro jest zapotrzebowanie, to napiszę coś w tym temacie, szczególnie że kilka postów na temat tych silników na blogu już się pojawiło i będzie dobra okazja żeby zebrać je w jednym miejscu. No to zaczynamy.

Jakby się tak zastanowić, to okazuje się, że popularność tego typu pytań nie powinna nikogo dziwić. W ciągu ostatnich kilku miesięcy sytuacja na “rynku” silników bazodanowych w MySQL zmieniła się o 180 stopni. Wiąże się to oczywiście z wejściem MySQL 5.5 i zastosowaniem InnoDB jako silnika domyślnego. W erze pre-5.5 sprawa była jasna. Znakomita większość stosowała MyISAM. Głównie z tego względu, że tak było domyślnie, a mało kto domyślne ustawienia zmienia. Jeśli ktoś wybierał InnoDB (czy też w ogólności jakiegokolwiek silnika, innego niż domyślny), to zazwyczaj była to osoba w pełni świadoma wyboru, orientowała się jakie są wady i zalety obu silników i na tej podstawie podejmowała samodzielnie decyzję o zastosowaniu silnika innego niż MyISAM. W erze post-5.5 sytuacja jest już inna. Domyślnie mamy InnoDB, ale jako że większość osób przyzwyczajona jest do MyISAM, to pojawiają się pytania czy taka zmiana ma sens, czy może jednak zostać przy dotychczasowym silniku bazodanowym? Szczególnie że tyle przecież lat dało się go stosować, więc niby czemu na to nowe InnoDB przechodzić? No ale skoro jest to silnik domyślny, to może jednak warto? Użytkownicy MySQL szukają informacji żeby świadomie podjąć decyzję.

Tym, którzy się wahają, polecam zapoznanie się z następującymi postami, które mniej więcej rok temu pojawiły się na tym blogu:

http://blog.ksiazek.info/2010/08/11/roznice-pomiedzy-myisam-i-innodb-wydajnosc/
http://blog.ksiazek.info/2010/08/17/co-jest-szybsze-myisam-czy-innodb/
http://blog.ksiazek.info/2010/08/23/roznice-pomiedzy-myisam-i-innodb-odpornosc-na-awarie/
http://blog.ksiazek.info/2010/08/29/roznice-pomiedzi-myisam-i-innodb-backup/
http://blog.ksiazek.info/2010/09/04/roznice-pomiedzy-myisam-i-innodb-high-availability/

Ta seria, mam nadzieję, powinna dać przynajmniej ogólne pojęcie o wadach i zaletach obu rozwiązań.

Wracamy jednak do pytania “co wybrać – MyISAM czy InnoDB”? Jak się można domyślić, odpowiedź jest banalna: “to zależy”. MyISAM to dobry silnik do tabel, w których nie przechowujemy dużych ilości danych a dodatkowo dane te są głównie odczytywane, z niewielkimi ilościami zapisów. W takim środowisku MyISAM będzie szybszy od InnoDB a problemy z ewentualnymi uszkodzeniami tabeli nie będą groźne. MyISAM można także stosować tam, gdzie nie ma potrzeby replikowania danych. Co prawda, replikacja tabel na silniku MyISAM jak najbardziej działa, ale brak transakcji może spowodować rozsynchronizowanie się zawartości tabel pomiędzy master i slave w wypadku awarii i np. przerwania wykonywania się zapytania typu UPDATE. Ogólnie mówiąc, główną wadą silnika MyISAM jest brak mechanizmów zapewniających integralność danych. Jeśli integralność nie jest dla nas niezbędna, a wiemy (bo wykonaliśmy odpowiednie testy), że w naszym środowisku i w przypadku naszego miksu zapytań MyISAM jest szybszy niż InnoDB, to zastosowanie tego silnika może nie być złym rozwiązaniem. Oczywiście, cały czas trzeba pamiętać o ilości danych i wielkości tabel. REPAIR TABLE na prawdę może trwać bardzo długo – trzeba to uwzględnić przy wyborze silnika.

Zastosowanie InnoDB w zasadzie można podsumować następująco – stosować powinno się wszędzie, o ile ktoś nie udowodni że MyISAM w danej sytuacji jest lepszy. InnoDB jest bardziej uniwersalnym silnikiem. W domyślnej konfiguracji gwarantuje integralność danych, ale można także tą integralność poświęcić na rzecz wydajności operacji modyfikujących dane. InnoDB to w zasadzie jedyne rozwiązanie, jeśli chcemy zastosować bardziej zaawansowane rozwiązania gwarantujące wysoką dostępność MySQL typu DRBD + Pacemaker czy innego rodzaju klaster active – passive. Przy zastosowaniu InnoDB standardowa replikacja będzie bardziej stabilna – mniejsze szanse na wystąpienie problemów z synchronizacją w razie zerwania replikacji. Dodatkowo, o czym także trzeba pamiętać, InnoDB jest aktywnie rozwijane. Co jakiś czas pojawia się nowa wersja silnika, zawierająca nowe rozwiązania bądź ulepszenia dotychczasowych. Przykładowo, od pewnego czasu Percona w swoim Percona Server 5.1 i 5.5 udostępnia mechanizm zachowujący zawartość InnoDB buffer pool pomiędzy restartami serwera MySQL. Dzięki temu serwer znacznie szybciej zaczyna działać z pełną wydajnością (z resztą, zapraszam po więcej informacji do tego posta). Oracle tego typu mechanizm udostępniło w MySQL 5.6. Właściwie większość nowych wersji MySQL niesie ze sobą jakieś poprawki w zakresie InnoDB. Część to poprawki błędów, ale część skutkuje większą wydajnością. Szczegóły można znaleźć w changelogach MySQL 5.1 i 5.5

Podsumowując, moim zdaniem zmiana domyślnego silnika to była dobra decyzja. W większości zastosowań InnoDB będzie lepsze niż MyISAM. Nawet jeśli będzie minimalnie ustępować wydajnością, to nadrobi to bezpieczeństwem danych, prostym mechanizmem naprawy tabel itp. Oczywiście MyISAM nie jest zły – znajdą się takie sytuacje gdzie to właśnie ten silnik będzie najlepszym rozwiązaniem. Tyle że w większości przypadków tak nie będzie.