Blog IT, Blog Marketing

Stosowanie MySQL w BigData

Stosowanie MySQL w BigData

Marcin Sarna , 29.06.2021 r.

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.

QA Engineer 8000 - 13000 PLN

Praca zdalna
Aplikuj

C/C++ Developer 12000 - 18000 PLN

Wrocław
Aplikuj

Angular Developer 10000 - 15500 PLN

Praca zdalna
Aplikuj

PHP Software Engineer 17000 - 22500 PLN

Praca zdalna
Aplikuj

Embedded C++ Developer 18000 - 24000 PLN

Pszczyna
Aplikuj

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.

Najnowsze oferty pracy:

Polecane wpisy na blogu IT:

Szukasz pracownika IT?

Dostarczymy Ci najlepszych specjalistów z branży IT. Wyślij zapytanie

Wyrażam zgodę TeamQuest Sp. z o.o. na przetwarzanie moich danych osobowych w celu marketingu produktów i usług własnych TeamQuest, w tym na kontaktowanie się ze mną w formie połączenia telefonicznego lub środkami elektronicznymi.
Administratorem podanych przez Ciebie danych osobowych jest TeamQuest Sp. z o.o., z siedzibą w Warszawie (00-814), ul. Miedziana 3a/21, zwana dalej „Administratorem".
Jeśli masz jakiekolwiek pytania odnośnie przetwarzania przez nas Twoich danych, skontaktuj się z naszym Inspektorem Ochrony Danych (IOD). Do Twojej dyspozycji jest pod adresem e-mail: office@teamquest.pl.
W jakim celu i na jakiej podstawie będziemy wykorzystywać Twoje dane? Dowiedz się więcej