To był krok, który musieliśmy zrobić. Dość trudno było nam się zdecydować, mimo że wiedzieliśmy, iż prędzej czy później zacznie nam to sprawiać problemy — i tak właśnie się stało.
Kilka tygodni temu, zupełnie zwykłego dnia, rutynowy proces w programie do zarządzania magazynem położył nam stronę. Nie było to nic szczególnie poważnego, bo 20 sekund później strona znów działała bez problemów, ale to była kropla, która przelała czarę, i to ona skłoniła nas do zmiany silnika tabel MySQL.
Problem polegał na tym, że domyślny silnik w osCommerce, MyISAM, jest znacznie szybszy przy wykonywaniu zapytań odczytu, ale z drugiej strony blokuje tabelę na czas potrzebny do wykonania zapytania, a jeśli jest to gigantyczna tabela, do której w kolejce czeka 135 zapytań próbujących dostać się do tej samej tabeli, mamy problem i w konsekwencji strona się blokuje. Po zabiciu „blokującego” zapytania wszystko wraca do normy, ale… na jak długo? I co gorsza: co, jeśli nie będzie nas na miejscu, żeby to zauważyć?
Postanowiliśmy więc przeciąć sprawę raz na zawsze i, za rekomendacją osoby odpowiedzialnej za nasze serwery, przeszliśmy na InnoDB. W tym celu przygotowaliśmy zestaw testów i prób, które wykonaliśmy przed zmianą silnika i po niej na naszych serwerach lokalnych, a następnie w preprodukcji. Choć istniało ryzyko związane z joinami między tabelami, ich ogromna liczba w naszym kodzie nie pozwalała nam analizować ich pojedynczo i dokładnie, dlatego zdecydowaliśmy się przeprowadzić tę dość kompletną baterię testów.
Kiedy już sprawdziliśmy w preprodukcji, że wszystko działa zgodnie z oczekiwaniami, z klawiaturą w dłoni i oczami przyklejonymi do ekranu, o 5:00 rano — gdy prawie nie ma odwiedzających — zebraliśmy się na odwagę i zaczęliśmy od backupu bazy danych, a zaraz potem od zmiany silnika tabel. Najpierw najcięższe, jedna po drugiej, a później lżejsze w grupach, żeby nie obciążać wydajności dla tych kilku odważnych, którzy odwiedzali nas o tak nieludzkiej porze. W nieco ponad półtorej godziny mieliśmy już wszystko zmienione i całą baterię testów wykonaną. Żadnych błędów, żadnych problemów, nic dziwnego. Dziwne, prawda? A jednak: tym razem Murphy był po naszej stronie.
Wyniki, które uzyskaliśmy, są zgodne z oczekiwaniami: brak blokad tabel kosztem nieco gorszej wydajności w 10% przypadków. Mamy nadzieję rozwiązać to wkrótce, dzieląc na części dwie lub trzy mastodontyczne tabele, które mamy. Za kilka dni — albo tygodni — opowiem też, jak poszedł ten podział. Zachęcam was, żebyście wtedy to przeczytali, a tymczasem zostawiam kilka linków dla tych, którzy chcą zgłębić temat:
- http://www.arsys.info/programacion/myisam-o-innodb-elige-tu-motor-de-almacenamiento-mysql/
- http://dev.mysql.com/doc/refman/5.0/es/converting-tables-to-innodb.html
- http://stackoverflow.com/questions/7335515/migrating-from-myisam-to-innodb
Dodaj komentarz