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:
- Atomicity sprawia, że wszystkie instrukcje SQL działają jako niepodzielna jednostka.
- Consistency zapewnia spójność danych dzięki wykorzystaniu mechanizmów logowania dostępnych w InnoDB.
- Isolation odnosi się do blokowania na poziomie wiersza w InnoDB.
- 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.