Porównanie baz danych
MySQL: domyślna baza danych, ale wciąż na nią zarabiamy
MySQL to baza danych, na której działa większość sieci, nie dlatego, że jest ekscytująca, ale dlatego, że jest przewidywalna: rdzeń ACID InnoDB, model replikacji, z którym stykał się każdy administrator, oraz ekosystem paneli, wtyczek i założeń aplikacji zbudowany na wierzchu. Poważna praca polega na domyślnych ustawieniach konfiguracji, dyscyplinie replikacji i wiedzy, gdzie wersja 8 faktycznie zyskuje na swojej złożoności.
Kluczowe punkty
- InnoDB to silnik pamięci masowej, który ma znaczenie: klastrowe klucze podstawowe, blokowanie wierszy i bezpieczne odzyskiwanie ponowień; artykuły dotyczące starszej wersji MyISAM, które zalecają zamianę silników, zwykle są starsze niż rzeczywistość, w której nowoczesny stos MySQL jest w 99% InnoDB i jest z tego powodu szczęśliwszy.
- MySQL 8 zapracował na czas aktualizacji dzięki prawdziwym funkcjom: funkcjom okiennym, CTE, ulepszonemu EXPLAIN FORMAT=TREE, obsłudze JSON klasy Hermes poprzez JSON_TABLE; przepływy, które przewidywały marketing oparty na funkcjach MariaDB forks, znacznie się zawęziły.
- Replikacja to miejsce, w którym kariera się kończy lub kończy: konfiguracje oparte na GTID umożliwiają zarządzanie topologią (łańcuch, wiele źródeł), półsynchronizacja jako kompromis między wydajnością a trwałością, a opóźnienie replikacji odczytu nie musi być mierzone (kontrole w stylu pt-heartbeat lub opóźnienie oparte na performance_schema).
- Praca nad wydajnością rozpoczyna się od powolnego dziennika zapytań plus performance_schema: podsumowania instrukcji, użycie indeksu i indeksowanie w pierwszej kolejności według schematu pokonują każdą magiczną listę parametrów my.cnf; Prawdziwym pokrętłem, które ma znaczenie, jest wybór rozmiaru puli buforów w porównaniu z zestawem roboczym.
- Kopie zapasowe, które przywracają: przepływy pracy oparte na zrzutach (mysqldump --single-transaction) dla małych posiadłości, fizyczne migawki (klasa Percona xtrabackup-class) pod kątem szybkości i odzyskiwanie do określonego momentu zawsze testowane w oparciu o rzeczywisty harmonogram przestojów, a nie siatkę dokumentacji.
- Tam, gdzie domyślny status MySQL wciąż wygrywa: ekosystemy aplikacji go zakładają, panele go dostarczają (często zamieniane na MariaDB), operatorzy chmur zapewniają to tanio, a ekosystemy wtyczek CMS (szczególnie WordPress) testują najpierw pod tym względem; pozostanie domyślnym oznacza pozostanie przetestowanym.
Notatka z praktyki
Najlepsza praca nad wydajnością MySQL, jaką kiedykolwiek widziałem, nie był maratonem dostrajania konfiguracji: był to programista, który usunął trzy indeksy, które walczyły z jedną tabelą OLTP o przepustowość zapisu. Un-benchmarking zaczyna się od powolnych podsumowań zapytań, a nie od postów na blogu.
Częste pytania
MySQL 8 czy MariaDB dla nowego projektu?
Nowe projekty bez ograniczeń ekosystemowych: MariaDB to dobra opcja domyślna, ale MySQL 8 ma ekosystem dostawcy, poprawki bezpieczeństwa i mechanizmy replikacji. Porównaj funkcje, których faktycznie potrzebujesz, przeczytaj nasz artykuł mysql-vs-postgresql dotyczący pytania relacyjnego.
Czy przejście istniejącego MySQL na MariaDB wymaga zmian?
Aktualizacja wersji w formacie binarnym jest najgorsza: słownik danych MySQL 8 nie jest czytany przez MariaDB. Migracja logiczna (zrzut/ładowanie) działa, wymiana wtyczki wymaga inwentaryzacji przed zatwierdzeniem.
Replikacja półsynchroniczna: warte opóźnienia?
Zmniejsza utratę danych w trybie cichego przełączania awaryjnego; klasyczna reguła to jedna z dwóch opcji spójności/wydajności z asynchronią jako podstawą. W przypadku większości przeciążonych obciążeń właściwą odpowiedzią jest półsynchronizacja i przetestowane przełączanie awaryjne, a nie pełna synchronizacja.
Jak powstrzymać pojedynczą powolną witrynę przed zniszczeniem urządzenia?
Zasoby przypadające na użytkownika (CloudLinux db_governor na współdzielonych stosach, z przodu ograniczanie zapytań proxy) plus dyscyplina związana z wolnymi zapytaniami; sama baza danych nie ma pasów bezpieczeństwa, chyba że otoczenie tak daje.
Jak Kinetikatech pomaga w porównanie baz danych
Rozwiązywaliśmy to setki razy: Wybór silników baz danych do hostowania obciążeń, porównanie pod kątem gwarancji poprawności, wagi operacyjnej i rzeczywistych kosztów: silniki wbudowane z serwerami, MySQL z PostgreSQL, SQL z magazynami dokumentów oraz studium przypadku starszego typu, które wciąż powraca. Z Zarządzanie serwerami i Optymalizacja prędkości otrzymują Państwo pełny cykl: oceniamy, wdrażamy, monitorujemy przez całą dobę i odpowiadamy w 30 minut, gdy ma to znaczenie.