Nie tylko NoSQL czy MongoDB nadaje się do dużych zestawów danych.

Wydajny i niezawodny, ale wymagający dostrojenia

Panuje obiegowa opinia, że relacyjne bazy danych generalnie nie są dobrym wyborem do obróbki big data i oczywiście jest w tym trochę racji – w końcu nie po to zostały one stworzone. Systemy zarządzania bazami danych oparte na NoSQL, takie jak MongoDB, z pewnością są dobrym wyborem w przypadku dużych zbiorów danych. Jednak wbrew powszechnemu przekonaniu nie należy tak szybko wykluczać MySQL - w niektórych scenariuszach MySQL (lub MariaDB) może okazać się nawet lepszym rozwiązaniem dla dużych zbiorów danych niż ich odpowiedniki NoSQL. Oto skrócona lista powodów, dla których tak uważamy:

• Jeden z silników pamięci masowej MySQL, InnoDB, jest wydajnym i niezawodnym silnikiem pamięci masowej.
• InnoDB ma określone parametry, które pozwalają programistom zajmującym się MySQL lub MySQL DBA na maksymalne wykorzystanie silnika - na przykład na przeznaczenie 60–80% pamięci RAM dostępnej na serwerze dla samego InnoDB.
• InnoDB można również dostosować do ACID. Zgodność z ACID może okazać się pomocna w łagodzeniu skutków uszkodzeń bazy danych, które mogą wynikać chociażby z przerw w dostawie prądu.

Silnik

MySQL czy MariaDB mają wiele silników, z których można wybierać. To co trzeba wiedzieć to fakt, że MyISAM był domyślnym silnikiem pamięci masowej MySQL aż do MySQL 5.5. Kiedy MySQL 5.5 został wydany w 2010 roku, InnoDB zastąpił MyISAM w roli domyślnego silnika dla MySQL. InnoDB i MyISAM są obecnie najczęściej używane w świecie MySQL i wystarczą do big data.

InnoDB obsługuje model ACID, a także blokowanie na poziomie wiersza i klucze obce. Od MySQL 5.6 InnoDB radzi sobie z indeksami pełnotekstowymi i przenośnymi przestrzeniami tabel, a od wersji 5.7 niestraszne mu też indeksy przestrzenne. W big data stabilność i szybkość bazy mają priorytetowe znaczenie a InnoDB na to pozwoli – wystarczy oprzeć się na modelu ACID, zoptymalizować parę ustawień w my.cnf i zrestartować serwer.

ACID

Model ACID oznacza atomowość, spójność, izolację i trwałość - zestaw takich właściwości bazy danych, które mają zagwarantować poprawność danych pomimo błędów czy przerw w zasilaniu:

1. Atomicity sprawia, że wszystkie instrukcje SQL działają jako niepodzielna jednostka.
2. Consistency zapewnia spójność danych dzięki wykorzystaniu mechanizmów logowania dostępnych w InnoDB.
3. Isolation odnosi się do blokowania na poziomie wiersza w InnoDB.
4. Durability to zdolność InnoDB do utrzymywania pliku logów.

Model ACID można włączyć lub wyłączyć modyfikując wartość zmiennej innodb_flush_log_at_trx_commit w pliku my.cnf. Domyślna opcja 1 sprawia, że InnoDB jest zgodny z ACID podczas gdy 0 i 2 wyłącza zgodność ale znacznie zwiększa prędkość zapisu. Jeśli chcesz używać MySQL w swoim projekcie Big Data, prawdopodobnie najlepiej będzie zachować opcję domyślną.

Użyj parametrów InnoDB, aby zoptymalizować prędkość bazy danych MySQL

Innodb_buffer_pool_size jest jednym z najważniejszych parametrów architektury InnoDB. Zadaniem tego bufora jest składowanie danych i indeksów w tabelach InnoDB. Im większy jest ten bufor, tym więcej danych i indeksów może przechowywać w pamięci podręcznej, co jest szczególnie ważne w przypadku dużych zbiorów danych.

Oczywiście pamięć RAM jest z natury ograniczona, dlatego konieczne jest pozostawienie pewnej ilości miejsca na inne procesy systemowe - zalecana optymalna wartość dla innodb_buffer_pool_size to około 60–80% dostępnej pamięci systemu.

innodb_buffer_pool_size jest również ściśle powiązany z parametrem innodb_log_file_size - im obszerniejsze są twoje logi tym krótszy czas odzyskiwania w przypadku awarii. Dla uzyskania optymalnej wydajności przy pracy z dużymi zbiorami danych warto ustawić ten parametr na około jedną czwartą wartości innodb_buffer_pool_size.

Pulę buforów InnoDB można również podzielić na wiele instancji za pomocą parametru innodb_buffer_pool_instances. Może to poprawić operacje wejścia / wyjścia dysku. Innodb_log_buffer_size definiuje rozmiar bufora w bajtach, którego InnoDB używa do zapisywania w plikach logów. Domyślna wartość tego parametru to 8 MB. Większy bufor logów umożliwia uruchamianie dużych transakcji bez zapisywania logów na dysku przed zatwierdzeniem transakcji.