InnoDB Plugin
- Thread starter koob
- Start date
Paxton
Banned User
Nie zobaczysz znaczacej roznicy uruchamiajac AAC, czy TFS. Zestresuj server kilkoma polaczeniami i wieloma zapytaniami i zrob sobie benchmark, ale nie bedziesz mial kolosalnej roznicy 
L
Lanceq2
Guest
MySQL posiada modułową budowę, dzięki czemu może udostępnić użytkownikom dużą ilość silników bazodanowych. Znakomita większość z nich powstała dla konkretnego zastosowania i służy do realizowania wyspecjalizowanych zadań. Wśród silników można jednak znaleźć dwa, które wykorzystywane są powszechnie. Chodzi oczywiście o MyISAM i InnoDB. Administrator MySQL często staje przed dylematem – który z tych dwóch silników wybrać dla własnych celów? Na przestrzeni lat przez internet przewaliły się dziesiątki zaciekłych dyskusji na temat tego, który z tych silników jest lepszym rozwiązaniem. MyISAM oferuje znacznie szybszą obsługę SELECTów, jest też łatwiejszy w backupowaniu i szybciej da się odtworzyć z backupu tabelę działającą na silniku MyISAM. InnoDB obsługuje transakcje, umożliwia stosowanie kluczy obcych, nie da się go łatwo backupować przez kopiowanie plików, ma przeciętną wydajność. Mniej więcej do takich wniosków doszedłem bazując na szybkim przeglądnięciu wyników z Google. Jak to się ma do realiów w jakich pracuje administrator MySQL z 2010 roku?
Realia te są trochę inne, niż cztery – pięć lat temu. Od tego czasu MyISAM praktycznie się nie zmienił – prace nad tym silnikiem być może są prowadzone, natomiast nie jest to w praktyce widoczne. W ciągu ostatnich kilku lat rozwój InnoDB ruszył natomiast gwałtownie do przodu. Zarówno programiści z Innobase, którzy obecnie udostępniają do ściągnięcia InnoDB Plugin w wersji 1.0.7 dla MySQL 5.1, a także InnoDB Plugin w wersji 1.1.0 dla MySQL 5.5, jak też programiści z Percony, pracujący nad swoim silnikiem, XtraDB, będącym tuninngowaną wersją InnoDB, praktycznie co kilka miesięcy wydają kolejną, ulepszoną wersję silnika. Spróbuję porównać oba silniki bazodanowe i zaznaczyć słabe i mocne strony każdego z nich. Temat jest o tyle aktualny, że wraz z MySQL w wersji 5.4 MyISAM przestanie być domyślnym silnikiem – stanie się nim InnoDB. O ile do tej pory sporo osób decydowało się na MyISAM w sposób nieświadomy – silnik ten był domyślny, a ustawienia domyślne traktowane są często jako optymalne, to po wprowadzeniu tej zmiany decyzja o stosowaniu MyISAM będzie musiała zostać podjęta bardziej świadomie.
W tym poście zajmę się porównaniem tych cech obu silników, które mają wpływ na wydajność.
MyISAM to blokowanie na poziomie tabel. Jeśli do tabeli `tabela` idzie INSERT, który długo się wykonuje, wszystkie inne zapytania idące do tej tabeli muszą czekać aż to zapytanie się
skończy. W praktyce, jeśli tylko wzrasta ilość jednoczesnych operacji modyfikujących dane w jednej tabeli, MyISAM nie daje rady. InnoDB stosuje blokowanie na poziomie rekordów, umożliwia jednoczesne działanie większej ilości zapytań modyfikujących dane. Ta cecha była od zawsze jedną z głównych przyczyn, dla których rezygnowano z MyISAM a stosowano InnoDB.
W przypadku zapytań typu SELECT powszechnie twierdzi się, że MyISAM jest szybszy. Nie jest to tak oczywiste. InnoDB posiada specyficzną cechę, która w pewnych sytuacjach znacznie przyspiesza działanie SELECTów – klastrowane indeksy. Ogólna idea działania indeksu jest taka, że zamiast przeglądać tabelę w poszukiwaniu rekordów spełniających dane warunki, przegląda się posortowany indeks – z niego pobierane są informacje, gdzie fizycznie znajduje się potrzebny rekord. Rekordy są odczytywane i wyświetlane. Są to przynajmniej dwie operacje dyskowe – odczyt indeksu i odczyt danych. Indeksy klastrowane cechują się tym, że dane przechowywane są w obrębie indeksu. Dzięki temu oszczędzana jest jedna operacja odczytu – odczyt indeksu łączy się z odczytem potrzebnych danych. Tyle teoria. W praktyce bywa różnie, ale w niektórych sytuacjach zastosowanie klastrowanych indeksów daje spore przyspieszenie działania.
Kolejną różnicą pomiędzy tymi silnikami jest wykorzystanie pamięci. MyISAM buforuje tylko indeksy – wielkość tego buforu określa zmienna ‘key_buffer’. Dane nie są trzymane w pamięci, a przynajmniej nie na poziomie MySQL. Wykorzystywane są do tego standardowe mechanizmy cache dyskowego używanego w danym systemie operacyjnym. W przypadku InnoDB MySQL obsługuje buforowanie wszystkich danych – wielkość tego buforu określa zmienna ‘innodb_buffer_pool_size’. Różnica jest o tyle istotna, że odwołanie się do systemowego cache jest bardziej kosztowne, niż odwołanie się do buforów w obrębie samego MySQL.
Wolne odzyskiwanie danych z backupu – MyISAM historycznie patrząc był znacznie szybszy jeśli chodzi o tworzenie tabel ze zrzutów. Zestaw mysqldump + cat dump.sql | mysql baza zazwyczaj szybciej funkcjonował na silniku MyISAM. MySQL odtwarza indeksy na dwa sposoby – poprzez sortowanie (szybszy) i z wykorzystaniem cache indeksów (key cache – wolniejszy). W MySQL 5.0 i 5.1 InnoDB nie potrafi zastosować szybszego algorytmu, przez co odzyskanie z backupu jest wyraźnie wolniejsze, szczególnie gdy ilość danych to kilkadziesiąt GB. Problem ten został rozwiązany przez programistów Innobase, a rozwiązanie to zostało wykorzystane też przez programistów Percony. W tym momencie użytkownicy InnoDB plugin oraz XtraDB także mogą korzystać z szybkiego tworzenia indeksów. Dotyczy to tak zwanych secondary indexes – indeks główny, ze względu na to, że jest klastrowany, musi zostać wygenerowany przez kopiowanie danych, a nie sortowanie.
MyISAM w niektórych sytuacjach jest szybszy jeśli chodzi o operacje dotyczące modyfikacji danych. Oczywiście, dzieje się to głównie wtedy, gdy ilość tabel jest na tyle duża, że blokowanie na poziomie tabel nie stanowi znacznego ograniczenia. InnoDB jest silnikiem transakcyjnym, zapewniającym integralność danych. Spełnienie tych wymagań wiąże się ze sporym narzutem, co przekłada się na niższą wydajność silnika. Można jednak to zmienić – jeśli w danych zastosowaniach nie konieczne jest zachowanie integralności danych (a tylko w takich sytuacjach sens ma porównywanie z MyISAM, które integralności nie zachowuje w ogóle), można zluzować część wymagań. Służy do tego zmienna innodb_flush_logs_at_trx_commit. Zmiana jej na ustawienie mniej bezpieczne (np. możliwa jest strata 1 sekundy transakcji w przypadku padu serwera fizycznego) skutkować może nawet dziesięciokrotnym wzrostem wydajności.
Realia te są trochę inne, niż cztery – pięć lat temu. Od tego czasu MyISAM praktycznie się nie zmienił – prace nad tym silnikiem być może są prowadzone, natomiast nie jest to w praktyce widoczne. W ciągu ostatnich kilku lat rozwój InnoDB ruszył natomiast gwałtownie do przodu. Zarówno programiści z Innobase, którzy obecnie udostępniają do ściągnięcia InnoDB Plugin w wersji 1.0.7 dla MySQL 5.1, a także InnoDB Plugin w wersji 1.1.0 dla MySQL 5.5, jak też programiści z Percony, pracujący nad swoim silnikiem, XtraDB, będącym tuninngowaną wersją InnoDB, praktycznie co kilka miesięcy wydają kolejną, ulepszoną wersję silnika. Spróbuję porównać oba silniki bazodanowe i zaznaczyć słabe i mocne strony każdego z nich. Temat jest o tyle aktualny, że wraz z MySQL w wersji 5.4 MyISAM przestanie być domyślnym silnikiem – stanie się nim InnoDB. O ile do tej pory sporo osób decydowało się na MyISAM w sposób nieświadomy – silnik ten był domyślny, a ustawienia domyślne traktowane są często jako optymalne, to po wprowadzeniu tej zmiany decyzja o stosowaniu MyISAM będzie musiała zostać podjęta bardziej świadomie.
W tym poście zajmę się porównaniem tych cech obu silników, które mają wpływ na wydajność.
MyISAM to blokowanie na poziomie tabel. Jeśli do tabeli `tabela` idzie INSERT, który długo się wykonuje, wszystkie inne zapytania idące do tej tabeli muszą czekać aż to zapytanie się
skończy. W praktyce, jeśli tylko wzrasta ilość jednoczesnych operacji modyfikujących dane w jednej tabeli, MyISAM nie daje rady. InnoDB stosuje blokowanie na poziomie rekordów, umożliwia jednoczesne działanie większej ilości zapytań modyfikujących dane. Ta cecha była od zawsze jedną z głównych przyczyn, dla których rezygnowano z MyISAM a stosowano InnoDB.
W przypadku zapytań typu SELECT powszechnie twierdzi się, że MyISAM jest szybszy. Nie jest to tak oczywiste. InnoDB posiada specyficzną cechę, która w pewnych sytuacjach znacznie przyspiesza działanie SELECTów – klastrowane indeksy. Ogólna idea działania indeksu jest taka, że zamiast przeglądać tabelę w poszukiwaniu rekordów spełniających dane warunki, przegląda się posortowany indeks – z niego pobierane są informacje, gdzie fizycznie znajduje się potrzebny rekord. Rekordy są odczytywane i wyświetlane. Są to przynajmniej dwie operacje dyskowe – odczyt indeksu i odczyt danych. Indeksy klastrowane cechują się tym, że dane przechowywane są w obrębie indeksu. Dzięki temu oszczędzana jest jedna operacja odczytu – odczyt indeksu łączy się z odczytem potrzebnych danych. Tyle teoria. W praktyce bywa różnie, ale w niektórych sytuacjach zastosowanie klastrowanych indeksów daje spore przyspieszenie działania.
Kolejną różnicą pomiędzy tymi silnikami jest wykorzystanie pamięci. MyISAM buforuje tylko indeksy – wielkość tego buforu określa zmienna ‘key_buffer’. Dane nie są trzymane w pamięci, a przynajmniej nie na poziomie MySQL. Wykorzystywane są do tego standardowe mechanizmy cache dyskowego używanego w danym systemie operacyjnym. W przypadku InnoDB MySQL obsługuje buforowanie wszystkich danych – wielkość tego buforu określa zmienna ‘innodb_buffer_pool_size’. Różnica jest o tyle istotna, że odwołanie się do systemowego cache jest bardziej kosztowne, niż odwołanie się do buforów w obrębie samego MySQL.
Wolne odzyskiwanie danych z backupu – MyISAM historycznie patrząc był znacznie szybszy jeśli chodzi o tworzenie tabel ze zrzutów. Zestaw mysqldump + cat dump.sql | mysql baza zazwyczaj szybciej funkcjonował na silniku MyISAM. MySQL odtwarza indeksy na dwa sposoby – poprzez sortowanie (szybszy) i z wykorzystaniem cache indeksów (key cache – wolniejszy). W MySQL 5.0 i 5.1 InnoDB nie potrafi zastosować szybszego algorytmu, przez co odzyskanie z backupu jest wyraźnie wolniejsze, szczególnie gdy ilość danych to kilkadziesiąt GB. Problem ten został rozwiązany przez programistów Innobase, a rozwiązanie to zostało wykorzystane też przez programistów Percony. W tym momencie użytkownicy InnoDB plugin oraz XtraDB także mogą korzystać z szybkiego tworzenia indeksów. Dotyczy to tak zwanych secondary indexes – indeks główny, ze względu na to, że jest klastrowany, musi zostać wygenerowany przez kopiowanie danych, a nie sortowanie.
MyISAM w niektórych sytuacjach jest szybszy jeśli chodzi o operacje dotyczące modyfikacji danych. Oczywiście, dzieje się to głównie wtedy, gdy ilość tabel jest na tyle duża, że blokowanie na poziomie tabel nie stanowi znacznego ograniczenia. InnoDB jest silnikiem transakcyjnym, zapewniającym integralność danych. Spełnienie tych wymagań wiąże się ze sporym narzutem, co przekłada się na niższą wydajność silnika. Można jednak to zmienić – jeśli w danych zastosowaniach nie konieczne jest zachowanie integralności danych (a tylko w takich sytuacjach sens ma porównywanie z MyISAM, które integralności nie zachowuje w ogóle), można zluzować część wymagań. Służy do tego zmienna innodb_flush_logs_at_trx_commit. Zmiana jej na ustawienie mniej bezpieczne (np. możliwa jest strata 1 sekundy transakcji w przypadku padu serwera fizycznego) skutkować może nawet dziesięciokrotnym wzrostem wydajności.
Paxton
Banned User
Zes sie na kopiowal. Jesli chodzi o wymagania OTS, to specjalnej roznicy miedzy tymi dwoma silnikami nie bedzie, ale szedl bym w strone InnoDB jesli chodzi o OTS, jednak jesli chodzi o portal internetowy, gdzie duzo danych jest wyciaganych z bazy, poszedl bym w strone MyISAM. Jesli chodzi o InnoDB Plugin, czy chociaz by inne 'akceleratory' to nie widze w tym zadnego sensu, bo baza danych nie jest jakos specjalnie stresowana przez OTS, czy AAC, a przynajmniej nie tyle zeby trzeba bylo jakies specjalne rozszerzenia instalowac. Nie wiem jakie koob masz powod do uzycia InnoDB plugin, ale mi to do OTS nie pasuje.
Druga sprawa, po przeczytaniu artykulu od Lanceq, to nasuwa mi sie pytanie, i wg. mnie teoria, ze 'teoretycznie' zapis servera powinien byc szybszy na InnoDB, poprzez nie blokowanie aktualnej tabeli na ktorej jest wykonywane zapytanie, nie wiem jak dziala zapis na TFS, ale jesli zapisuje on w sposob gdzie wszystko jest zapisywane po kolei, to czy nie powinno to pomoc? Wydaje mi sie ze w swiecie OT, bardziej nam sie przyda szybsze zapisywanie danych, niz ich wyciaganie, bo to i tak jest roznica tak mala, ze przez zwyklego usera nie zauwazalna
Ale taki maly conclusion z mojej strony:
Dla AAC lepsze MyISAM
dla OTS lepsze InnoDB
no ale trzeba wybrac, wiec poszedl bym w strone InnoDB poniewaz 'traffic' na AAC jest na tyle maly ze roznica jest minimalna, i nie marnowal bym sobie czasu na instalowanie InnoDB plugin, czy jakich kolwiek innych 'dopalaczy'
Druga sprawa, po przeczytaniu artykulu od Lanceq, to nasuwa mi sie pytanie, i wg. mnie teoria, ze 'teoretycznie' zapis servera powinien byc szybszy na InnoDB, poprzez nie blokowanie aktualnej tabeli na ktorej jest wykonywane zapytanie, nie wiem jak dziala zapis na TFS, ale jesli zapisuje on w sposob gdzie wszystko jest zapisywane po kolei, to czy nie powinno to pomoc? Wydaje mi sie ze w swiecie OT, bardziej nam sie przyda szybsze zapisywanie danych, niz ich wyciaganie, bo to i tak jest roznica tak mala, ze przez zwyklego usera nie zauwazalna
Ale taki maly conclusion z mojej strony:
Dla AAC lepsze MyISAM
dla OTS lepsze InnoDB
no ale trzeba wybrac, wiec poszedl bym w strone InnoDB poniewaz 'traffic' na AAC jest na tyle maly ze roznica jest minimalna, i nie marnowal bym sobie czasu na instalowanie InnoDB plugin, czy jakich kolwiek innych 'dopalaczy'
Last edited:
Druga sprawa, po przeczytaniu artykulu od Lanceq, to nasuwa mi sie pytanie, i wg. mnie teoria, ze 'teoretycznie' zapis servera powinien byc szybszy na InnoDB, poprzez nie blokowanie aktualnej tabeli na ktorej jest wykonywane zapytanie, nie wiem jak dziala zapis na TFS, ale jesli zapisuje on w sposob gdzie wszystko jest zapisywane po kolei, to czy nie powinno to pomoc? Wydaje mi sie ze w swiecie OT, bardziej nam sie przyda szybsze zapisywanie danych, niz ich wyciaganie, bo to i tak jest roznica tak mala, ze przez zwyklego usera nie zauwazalna
Przeczytaj z wklejki Lanceq`a ostatni akapit. Teoretycznie przy dobrym configu powinno saveowac szybciej. Srednio mam czas sie bawic configiem i testowac, dlatego pytam czy ktos ma jakies doswiadczenia z innodb jako pluginem zamiast builtina mysqla.
Plugin jest od oracla z tego co wiem, wiec chyba mowi samo za siebie.
@down
http://www.mysqlperformanceblog.com/2010/01/13/innodb-innodb-plugin-vs-xtradb-on-fast-storage/
Last edited:
Paxton
Banned User
Ta, plugin jest od Sun tak samo jak Oracle. Jednak nadal wydaje mi sie, ze roznica nie bedzie duza, zrobil ktos moze jakis benchmark wczesniej? Wydaje mi sie, ze roznica bedzie tak mala, ze bedzie ja mozna nazwac 'environment difference'
@up
No i sie zgadza, OT czy AAC nie wygeneruje ci takiego zuzycia, a przy mniejszym stresie oba silniki beda mialy bardzo podobno predkosc, wiec chyba nie ma sensu.
Last edited:
Moj mysql podczas save`a jest zestresowany ;> A save w tfsie to delete/insert.
Paxton
Banned User
No tak, oba zajmuje dosyc dlugo. Wydaje mi sie ze jest to wina po prostu 'procedury' zapisywania, nie wiem dokladnie jak to wyglada ale chyba wszystko leci na raz. np, czemu nie zapisywac po kolei graczy do pamieci RAM, po woli i potem jako oddzielny thread zapisywac tego w tle, ale to juz nie moja dzialka, tym sie nie zajmuje, ale przynajmniej tak robie podczas pisania aplikacji web'owych ktore uzywaja b.duzych zasobow, wiec czemu czegos podobnego nie uzyc w TFS jesli sie da. Jesli twoja baza danych dziala na 100% podczas zapisu, jest cos zle i nie wydaje mi sie ze jest to wina konfiguracji servera, a procesu ktory uzywa tej bazy danych, ze potrafi ja tak wycisnac
Konfiguracja mysqla ma w tym wypadku ogromne znaczenie ( bufory ). Dlatego wydaje mi sie, ze mozna jeszcze urwac troche czasu sejva przy uzyciu tegoz pluginu lub xtradb ( nie testowalem ). Trzeba tylko czasu na testowanie configa ( a troche tych opcji jest ). Dlatego tez pytalem czy ktos sie wlasnie bawil w optymalizacje z uzyciem niewbudowanych storageow w mysqlu.
Paxton
Banned User
Wez jeszcze dorzuc sobie innotop dla lepszych statystyk lub tam jaki chcesz inny 'zapisywacz' i czekam na jakies benchmarki
Szperajac po google w poszukiwaniu jakis graphow z statystykami innoDB plugin, znalazlem to: Transactions on InnoDB � Blog Archive � Plug In for Performance and Scalability ciekawe, dziwi mnie to, ze przy wiekszej ilosci userow wydajnosc pozostaje.
Ok starczy tego na dzis, i tak jestem nie trzezwy psychicznie
Szperajac po google w poszukiwaniu jakis graphow z statystykami innoDB plugin, znalazlem to: Transactions on InnoDB � Blog Archive � Plug In for Performance and Scalability ciekawe, dziwi mnie to, ze przy wiekszej ilosci userow wydajnosc pozostaje.
Ok starczy tego na dzis, i tak jestem nie trzezwy psychicznie
L
Lanceq2
Guest
Wklejka nie wklejka jednak się na coś przydało ^^
- Joined
- Dec 11, 2007
- Messages
- 3,666
- Solutions
- 1
- Reaction score
- 125
- Location
- Warsaw, Poland
- GitHub
- tayandenga
- Twitch
- tayandenga
Różnica między InnoDB a MyISAM jest kolosalna przy dużych bazach danych. Na stronie tego nie zauważysz, jednak przy obciążających zapytaniach (UPDATE, INSERT), transakcje oraz dobry cache danych (przechowywanie w pamięci -> przy wspomnianych zapytaniach zapis na dysk wykonuje oddzielny wątek biorąc całe zestawy danych z pamięci) InnoDB jest o wiele szybsze ze względu na sposób przechowywania, indeksowania danych, triggery, eventy, wspomniane transakcje i brak niepotrzebnych ficzurs, które ma MyISAM.
To odnośnie postu Lanceq'a dla potomnych używających Search.
Odpowiadając na pytanie kooba: jeśli chodzi o InnoDB plugin od Oracle, to w porównaniu do natywnego InnoDB jest on niewiele wydajniejszy w naszym przypadku. Oracle zmienił trochę format zapisu AFAIK, przez co dane zajmują mniej => szybciej są odczytywane, więc dotyczy to głównie zapytań SELECT. Ale tych zapytań nie mamy wielu (nie jesteśmy naszą-klasią, czy fejsbuczkiem), a jeżeli już, to nie są one jakoś specjalnie obciążające (nie wiele jest zapytań o ile w ogóle są LEFT JOINy, itp) no i struktura tabel TFSa jest dobrze obindeksowana. Jeżeli chcemy osiągnąć dobre wyniki save, bo jest najbardziej obciążający i w sumie o to głównie chodzi, to tym bardziej niczego to nie zmienia, ponieważ te dane są cache'owane w pamięci (jak napisałem u góry większy cache => nie tylko szybszy odczyt, ale i zapis[!]), zatem wynik wiele się nie różni, a na pewno nie jest odczuwalny "w grze".
To odnośnie postu Lanceq'a dla potomnych używających Search.
Odpowiadając na pytanie kooba: jeśli chodzi o InnoDB plugin od Oracle, to w porównaniu do natywnego InnoDB jest on niewiele wydajniejszy w naszym przypadku. Oracle zmienił trochę format zapisu AFAIK, przez co dane zajmują mniej => szybciej są odczytywane, więc dotyczy to głównie zapytań SELECT. Ale tych zapytań nie mamy wielu (nie jesteśmy naszą-klasią, czy fejsbuczkiem), a jeżeli już, to nie są one jakoś specjalnie obciążające (nie wiele jest zapytań o ile w ogóle są LEFT JOINy, itp) no i struktura tabel TFSa jest dobrze obindeksowana. Jeżeli chcemy osiągnąć dobre wyniki save, bo jest najbardziej obciążający i w sumie o to głównie chodzi, to tym bardziej niczego to nie zmienia, ponieważ te dane są cache'owane w pamięci (jak napisałem u góry większy cache => nie tylko szybszy odczyt, ale i zapis[!]), zatem wynik wiele się nie różni, a na pewno nie jest odczuwalny "w grze".
