W czasach, gdy ktoś mówił MySQL, był tylko MySQL. Możesz wybrać różne wersje (4.0, 4.1), ale sprzedawca był ten sam. Zmieniło się to wokół MySQL 5.0/5.1, kiedy Percona zdecydowała się wydać własny smak MySQL - Percona Server. Nieco później MariaDB dołączyła do MariaDB 5.1 i zabawa (lub zamieszanie) wzrosła. Jakiej wersji powinienem użyć? Jaka jest różnica między MySQL 5.1, Percona Server 5.1 i MariaDB 5.1? Który jest szybszy? Który jest bardziej stabilny? Który z nich ma lepszą funkcjonalność? Z czasem sytuacja się pogorszyła, ponieważ w każdym ze smaków wprowadzano coraz więcej zmian. Ten wpis na blogu będzie naszą próbą podsumowania kluczowych cech, które je wyróżniają. Postaramy się również podpowiedzieć Ci, który smak może być najlepszy dla danego typu projektu. Zaczynajmy.
Oracle MySQL
Kiedyś był to MySQL, teraz to upstream. Większość prac rozwojowych zaczyna się tutaj, każda wersja, począwszy od 5.6, rozwiązuje niektóre wewnętrzne spory i zapewnia lepszą wydajność. Nowe funkcje są również dodawane regularnie. MySQL 5.6 przyniósł nam (między innymi) GTID oraz wstępną implementację replikacji równoległej. Dało nam to również możliwość wykonania większości ALTERów w trybie online. Rzućmy okiem na funkcje najnowszej wersji MySQL - MySQL 5.7
Funkcje MySQL 5.7
Jedną z głównych zmian są zmiany w procesie wdrażania — zamiast różnych skryptów wystarczy uruchomić mysqld --initialize, aby skonfigurować MySQL od zera. Kolejna bardzo ważna zmiana - replikacja równoległa oparta na zegarze logicznym. Wreszcie, możemy używać replikacji równoległej we wszystkich przypadkach - bez względu na to, czy używasz wielu schematów, czy nie. Kolejnym ulepszeniem replikacji jest replikacja wieloźródłowa – urządzenie podrzędne 5.7 może mieć wiele nadrzędnych – jest to świetna funkcja, jeśli chcesz zbudować podrzędną agregację i, powiedzmy, łączyć dane z wielu oddzielnych klastrów.
InnoDB zaczął obsługiwać typy przestrzenne, pulę buforów InnoDB można wreszcie zmienić w czasie wykonywania, ALTER online zostało ulepszone, aby obsługiwać więcej przypadków, takich jak partycjonowanie i ALTER bez operacji.
MySQL zaczął natywnie obsługiwać typy danych JSON wraz z kilkoma nowymi funkcjami, które koncentrują się na dodawaniu funkcjonalności wokół JSON. Bezpieczeństwo Twoich danych jest w dzisiejszych czasach bardzo ważne, MySQL 5.7 obsługuje szyfrowanie danych w spoczynku dla obszarów tabel typu plik na tabelę. Dodano również pewne ulepszenia do obsługi SSL (SSL zostanie skonfigurowany, jeśli klucze są na miejscu, dołączony jest skrypt, który można wykorzystać do tworzenia certyfikatów). Z perspektywy zarządzania użytkownikami dodano konfigurację okresu istnienia hasła, co powinno nieco ułatwić projektowanie zasad wygasania haseł.
Inną funkcją, która ma pomóc administratorom baz danych, jest schemat „sys”, zestaw widoków zaprojektowanych w celu ułatwienia korzystania ze schematu wydajności. Jest domyślnie dołączony do MySQL 5.7.
Wreszcie, MySQL Group Replication (i ostatecznie MySQL InnoDB Cluster) została dodana do MySQL 5.7. Działa jako wtyczka i jest dołączona do ostatnich wersji gałęzi 5.7, ale to już odrębny temat. Krótko mówiąc, replikacja grup umożliwia zbudowanie „wirtualnie” synchronicznego klastra.
To zdecydowanie nie jest pełna lista funkcji - jeśli interesują Cię wszystkie z nich, możesz zapoznać się z dokumentacją MySQL 5.7.
Serwer Percona
Na początku był zestaw poprawek do kodu źródłowego MySQL, które dodały kilka ulepszeń wydajności i funkcjonalności. W pewnym momencie Percona zdecydowała się wydać własną kompilację MySQL, która zawierała te poprawki. Z czasem dostępnych stało się więcej zasobów programistycznych, więc dodano coraz więcej funkcji.
Ogólnie rzecz biorąc, możesz zobaczyć Percona Server jako najnowszą wersję MySQL z wieloma poprawkami/ulepszeniami. Z czasem niektóre ulepszenia funkcji Percona Server są zastępowane funkcjami z wcześniejszych wersji - zawsze, gdy Oracle opracuje funkcję, która zastępuje jedną z funkcji dodanych w Percona Server. Dopóki implementacja jest na równi, Percona usuwa swój własny kod na rzecz kodu z wcześniejszego. To sprawia, że Percona Server jest w zasadzie zastępczym zamiennikiem Oracle MySQL. Jednym z obszarów, w którym dokonano znaczących ulepszeń wydajności, jest InnoDB. Został zmodyfikowany na tyle znacząco, by nazwać go XtraDB. Obecnie jest w pełni kompatybilny z InnoDB, ale nie zawsze tak było. Na przykład niektóre funkcje Percona Server 5.5 nie były kompatybilne z MySQL 5.5. Dotyczy to również nowszych wersji Percona Server. Co ważne, domyślnie Percona Server ma wyłączone wszystkie niezgodne funkcje - ułatwia to jego przetestowanie i powrót do bazy danych MySQL firmy Oracle, jeśli zajdzie taka potrzeba. Biorąc pod uwagę powyższe, nadal należy zachować ostrożność, planując migrację z Percona Server do MySQL – ktoś mógł włączyć jedną z niekompatybilnych funkcji.
Warto podkreślić, że Percona dąży do ponownego wdrożenia funkcji korporacyjnych na rynku wyższego szczebla. W przypadku MySQL przykładem jest implementacja puli wątków lub wtyczki uwierzytelniającej PAM. Rzućmy okiem na niektóre funkcje serwera Percona.
Funkcje Percona Server 5.7
Jedną z głównych cech XtraDB jest ulepszona skalowalność puli buforów – chociaż jest coraz mniej rywalizacji ze względu na pracę, którą Oracle wykonuje w każdej wersji MySQL, zespół inżynierów Percony stara się jeszcze bardziej zwiększyć wydajność i usunąć dodatkowe muteksy, które mogą ograniczać wydajność. Dodatkowo, więcej danych jest zapisywanych w monitorze InnoDB (dostępne przez SHOW ENGINE INNODB STATUS) dotyczących rywalizacji w InnoDB - np. dodano sekcję dotyczącą semaforów.
Kolejny zestaw ulepszeń został wprowadzony w obszarze I/O. W InnoDB możesz ustawić metodę opróżniania tylko dla obszarów tabel InnoDB, co powoduje podwójne buforowanie dla dzienników przeróbek InnoDB. XtraDB umożliwia użycie O_DIRECT również dla tych plików. Dodaje również więcej danych dotyczących punktów kontrolnych do wyjścia SHOW ENGINE INNODB STATUS. Oprócz tego zaimplementowano równoległy bufor podwójnego zapisu i wielowątkowe urządzenie do przepłukiwania LRU, aby zmniejszyć rywalizację w operacjach we/wy w ramach InnoDB.
Pula wątków to kolejna funkcja udostępniona przez Percona Server. W Oracle MySQL jest dostępny tylko w wersji Enterprise. Tutaj możesz bezpłatnie skorzystać z implementacji Percony. Ogólnie rzecz biorąc, pula wątków zmniejsza rywalizację, obsługując dużą liczbę połączeń z aplikacji poprzez ponowne wykorzystanie istniejących połączeń z bazą danych.
Dwie kolejne funkcje są bezpośrednimi zamiennikami funkcji z wersji Enterprise MySQL. Jednym z nich jest wtyczka uwierzytelniania PAM, opracowana przez firmę Percona, która umożliwia korzystanie z wielu różnych opcji uwierzytelniania, takich jak LDAP, RSA SecurID lub inne metody obsługiwane przez PAM. Druga funkcja jest również związana z bezpieczeństwem - wtyczka dziennika audytu. Utworzy plik z zapisem działań podjętych na serwerze bazy danych.
Od czasu do czasu Percona wprowadza znaczące ulepszenia do innych silników pamięci masowej, takie jak zmiany wprowadzone w silniku MEMORY, które umożliwiły użycie danych typu VARCHAR lub BLOB.
Dość znaczącym ulepszeniem było również wprowadzenie blokad zapasowych. W Oracle i MariaDB jedyną metodą zablokowania tabeli w celu uzyskania spójnej kopii zapasowej było użycie FLUSH TABLES WITH READ LOCK (FTWRL). Jest dość ciężki i zmusza MySQL do zamknięcia wszystkich otwartych tabel. Z drugiej strony blokady kopii zapasowych wykorzystują lżejsze podejście do blokad metadanych. W wielu przypadkach mocno obciążonego serwera z uruchomionym FTWRL trwa zbyt długo (i blokuje serwer zbyt długo), aby można go było uznać za wykonalne, podczas gdy blokady kopii zapasowych umożliwiają wykonanie kopii zapasowej za pomocą mysqldump lub xtrabackup.
Percona jest również otwarta na przenoszenie funkcji od innych dostawców. Jednym z takich przykładów jest port MariaDB ROZPOCZNIJ TRANSAKCJĘ ZE SPÓJNYMI ZDJĘCIAMI. Ta funkcja jest również związana z kopiami zapasowymi - z jej pomocą możesz wykonać spójną logiczną kopię zapasową (przy użyciu mysqldump) bez uruchamiania FLUSH TABLE WITH READ LOCK.
Wreszcie trzy cechy poprawiające obserwowalność - po pierwsze:statystyki użytkowników. Jest to dość lekka funkcja, która zbiera dane o użytkownikach, indeksach, tabelach i wątkach. Pozwala znaleźć nieużywane indeksy lub określić, który użytkownik odpowiada za obciążenie serwera. Obecnie jest częściowo zbędny w stosunku do schematu performance_schema, ale jest nieco lżejszy i powstał w czasach MySQL 5.0 - 5.1, gdzie nikt nawet nie śnił o schemacie performance_schema.
Po drugie - ulepszony log powolnych zapytań. Ponownie został dodany w czasach, w których najwyższa szczegółowość parametru long_query_time wynosiła 1 sekundę. Dzięki temu dodaniu uzyskałeś mikrosekundową ziarnistość i kilka dodatkowych danych dotyczących statystyk InnoDB na zapytanie lub jego ogólnej charakterystyki wydajności. Czy stworzył tabelę tymczasową? Czy używał indeksu? Czy zostało zapisane w pamięci podręcznej zapytań MySQL?
Trzecia funkcja, o której wspomnieliśmy kilka razy powyżej — Percona Server udostępnia znacznie więcej danych w SHOW ENGINE INNODB STATUS niż poprzednie. Zdecydowanie pomaga lepiej zrozumieć obciążenie pracą i wyłapać więcej problemów, zanim się rozwiną.
Oczywiście nie jest to pełna lista - jeśli interesują Cię więcej szczegółów, możesz sprawdzić dokumentację Percona Server.
MariaDB
MariaDB zaczynała jako rozwidlenie MySQL, ale część oryginalnego zespołu programistów MySQL dołączyła do MariaDB, szybko skupiła się na dodawaniu funkcji. W MariaDB 5.3 do optymalizatora dodano wiele funkcji:Batch Key Access, MultiRange Read, Index Condition Pushdown, aby wymienić tylko kilka. Umożliwiło to MariaDB osiągnięcie doskonałości w niektórych obciążeniach, z którymi miałby problemy MySQL lub Percona Server. Do tej pory niektóre z tych funkcji były dodawane do MySQL (głównie w MySQL 5.6), ale niektóre są nadal unikalne dla MariaDB.
Kolejną ważną funkcją wprowadzoną przez MariaDB był Global Transaction ID. Niewiele później Oracle wypuściło własną implementację, ale MariaDB była pierwszą, która ją miała. Podobna historia jest z inną funkcją replikacji - replikacją wieloźródłową:MariaDB miała ją przed Oracle. Teraz, niedawno wydana MariaDB 10.2 zawiera również funkcje, które zostaną udostępnione w MySQL 8.0, który wciąż jest w fazie rozwoju. Mówimy na przykład o rekurencyjnych typowych wyrażeniach tabelowych lub funkcjach okien.
Funkcje MariaDB 10.2
Jak wspomnieliśmy, MariaDB 10.2 wprowadza funkcje okien i rekurencyjne wyrażenia tabelowe - ulepszenia SQL, które powinny pomóc programistom w pisaniu bardziej wydajnych zapytań SQL.
Bardzo ważną zmianą jest to, że MariaDB 10.2 korzysta z InnoDB. Do 10.1 XtraDB był używany jako domyślna pamięć masowa. To niestety sprawia, że funkcje dodane w najnowszej wersji XtraDB są niedostępne dla użytkowników MariaDB 10.2.
Wprowadzono ulepszenia w wirtualnych kolumnach — więcej ograniczeń zostało zniesionych w wersji 10.2.
Na koniec dodano obsługę wielu wyzwalaczy dla tego samego zdarzenia — teraz możesz utworzyć kilka, na przykład, wyzwalaczy ON UPDATE w tej samej tabeli.
Deweloperzy powinni skorzystać z obsługi JSON, wraz z kilkoma funkcjami, które są z nią powiązane. Powinni też polubić nowe funkcje, które pozwalają na eksport danych przestrzennych do formatu GeoJSON. Mówiąc o JSON, wprowadzono ulepszenia w danych wyjściowych EXPLAIN FORMAT=JSON - pokazano więcej danych.
Jeśli chodzi o bezpieczeństwo, dodano obsługę OpenSSL 1.1 i LibreSSL.
Oczywiście ta lista nie jest kompletna i jeśli jesteś zainteresowany tym, co zostało dodane do MySQL 10.2, możesz zapoznać się z dokumentacją.
Oprócz nowych funkcji MariaDB 10.2 korzysta z funkcji zaimplementowanych w poprzednich wersjach. Omówimy najważniejsze.
Najważniejsze funkcje MariaDB 10.1
Przede wszystkim MariaDB od wersji 10.1 jest dostarczana w pakiecie z klastrem Galera - nie ma potrzeby instalowania dodatkowych bibliotek, wszystko jest gotowe do użycia.
MariaDB 10.1 wprowadziła implementację szyfrowania danych w spoczynku. W porównaniu z funkcją zaimplementowaną w MySQL firmy Oracle, MariaDB ma ją bardziej rozbudowaną. Nie tylko szyfruje obszary tabel, ale także szyfruje logi przeróbek, pliki tymczasowe i logi binarne. Wiąże się to z pewnymi problemami — narzędzia CLI, takie jak mysqldump lub xtrabackup, nie mają dostępu do dzienników binarnych i mogą mieć problemy z tworzeniem kopii zapasowych zaszyfrowanych instancji (dotyczy to zwłaszcza xtrabackup — całkiem niedawno MariaDB stworzyła fork xtrabackup o nazwie MariaDB Backup, który obsługuje dane w spoczynku szyfrowanie).
OK, więc jakiego smaku powinienem użyć?
Jak to zwykle bywa, prawidłowa odpowiedź brzmiałaby:„To zależy” :-) . Podzielimy się kilkoma naszymi obserwacjami, które mogą, ale nie muszą, pomóc Ci w podjęciu decyzji, ale na koniec to do Ciebie należy przeprowadzenie testów porównawczych i znalezienie opcji, która najlepiej sprawdzi się w Twoim środowisku i aplikacji.
Przede wszystkim porozmawiajmy o przepływie. Oracle wypuszcza nową wersję - powiedzmy MySQL 5.7. Pod względem wydajności jest to w tej chwili najszybszy smak MySQL na rynku. Dzieje się tak, ponieważ tylko Oracle ma wystarczające zasoby, aby pracować nad ulepszeniem InnoDB w tym zakresie. W ciągu kilku miesięcy (w przypadku wersji 5.7 było to 4 miesiące) Percona wypuszcza Percona Server 5.7 z zestawem ulepszeń - w zależności od rodzaju obciążenia może on zapewnić jeszcze lepszą wydajność niż poprzednik. Wreszcie MariaDB przyjmuje nową wersję nadrzędną i buduje na niej swoją nową wersję.
Tak to wyglądało w kalendarzu (nadal mówimy o MySQL 5.7).
MySQL 5.7 GA:21 października 2015
Percona Server 5.7 GA:23 lutego 2016
MariaDB 10.2 GA:23 maja 2017
Zwróć uwagę, ile czasu zajęło MariaDB wydanie wersji opartej na MySQL 5.7 - wszystkie poprzednie wersje były oparte na MySQL 5.6 i oczywiście zapewniały wydajność niższą niż MySQL 5.7. Z drugiej strony MariaDB 10.2 została wydana z InnoDB zastępującą XtraDB. Chociaż prawdą jest, że Oracle w większości wypełnił lukę w wydajności między MySQL a Percona Server, nadal jest to po prostu „w większości”. W rezultacie MariaDB 10.2 może zapewniać wydajność niższą niż Percona Server w niektórych przypadkach (i lepszą w innych przypadkach - ze względu na pracę optymalizatora wykonaną w MariaDB 5.3, z których część nie została jeszcze odtworzona w MySQL).
Pod względem funkcji jest bardziej złożony. MariaDB dodaje wiele funkcji, więc jeśli jesteś zainteresowany niektórymi z nich, zdecydowanie możesz rozważyć użycie MariaDB. Jest to też minus. Percona Server miał wiele funkcji odróżniających go od wcześniejszego MySQL, ale kiedy Oracle zaczął wdrażać je w MySQL, Percona zdecydowała się zdeprecjonować swoje implementacje na rzecz korzystania z implementacji wcześniejszej. Zmniejszyło to ilość kodu, który różni się między MySQL i Percona Server, ułatwia utrzymanie kodu Percona Server i, co najważniejsze, sprawia, że Percona Server jest w 100% kompatybilny z MySQL.
Niestety nie dotyczy to MariaDB. MariaDB jako pierwsza wprowadziła GTID, to prawda, ale po tym, jak Oracle opracowało swoją wersję GTID, MariaDB zdecydowała się pozostać przy własnej implementacji. Na tym blogu nie można decydować, która implementacja jest lepsza, ale w rezultacie musimy zarządzać dwoma różnymi, niekompatybilnymi systemami GTID - obciąża to każde narzędzie, które zarządza replikacją i zmniejsza interoperacyjność. Pozostając przy replikacji - zatwierdzanie grupowe i replikacja równoległa:zarówno Oracle, jak i MariaDB mają własne implementacje i jeśli pracujesz z nimi obydwoma, musisz nauczyć się ich obu, aby zastosować wymagane strojenie - pokrętła są różne i działają w inny sposób. Podobnie jest z obsługą kolumn wirtualnych - dwie różne, nie w 100% kompatybilne implementacje, które w rezultacie uniemożliwiły łatwe zrzucenie danych z MariaDB i załadowanie do Oracle's MySQL (i vice versa), ponieważ składnia jest nieco inna. Jeśli więc zdecydujesz się użyć wersji MariaDB dla jakiejś zupełnie nowej funkcji, możesz się z nią utknąć, nawet jeśli chcesz migrować z powrotem do MySQL, aby korzystać z implementacji Oracle. W najlepszym przypadku przeprowadzenie migracji wymagałoby znacznie więcej wysiłku. Oczywiście, jeśli będziesz cały czas przebywać w jednym środowisku, może to nie wpłynąć na ciebie poważnie. Ale nawet wtedy brak kompatybilności będzie dla ciebie zauważalny, choćby tylko wtedy, gdy będziesz czytać blogi w Internecie i znajdować rozwiązania, które nie pasują do twojego stylu MySQL.
Podsumowując - jeśli jesteś zainteresowany utrzymaniem kompatybilności z MySQL, prawdopodobnie najlepszym rozwiązaniem będzie Percona Server (lub oczywiście sam MySQL). Jeśli interesuje Cię wydajność, tak długo, jak Percona Server jest zbudowany na najnowszym MySQL, może to być droga do zrobienia. Oczywiście możesz chcieć przetestować MariaDB i sprawdzić, czy Twoje obciążenie nie może skorzystać z niektórych optymalizacji, które wciąż są unikalne dla MariaDB. Pod względem operacyjnym prawdopodobnie dobrze jest trzymać się jednego ze środowisk (Oracle/Percona lub MariaDB), w zależności od tego, które będzie dla Ciebie lepsze. MySQL lub Percona Server mają tę zaletę, że są częściej używane i nieco łatwiej jest je zintegrować z narzędziami zewnętrznymi (ponieważ nie wszystkie narzędzia obsługują wszystkie funkcje MariaDB). Jeśli chcesz skorzystać z nowej i lśniącej funkcji, która właśnie została zaimplementowana w MariaDB, powinieneś ją rozważyć, pamiętając o wszelkich potencjalnych problemach ze zgodnością i możliwym niższą wydajnością.
Mamy nadzieję, że ten wpis na blogu dał ci kilka pomysłów na temat różnych wyborów, jakie mamy w świecie MySQL i różnych punktów widzenia, z których możesz je porównać. Pod koniec dnia Twoim zadaniem będzie podjęcie decyzji, co jest najlepsze dla Twojej konfiguracji. Może nie jest to łatwe, ale mimo to powinniśmy być wdzięczni, że mamy wybór i możemy wybrać to, co działa dla nas najlepiej.
