Podczas tworzenia bazy danych często pomijanym, ale krytycznym czynnikiem wydajności jest silnik pamięci masowej (zwłaszcza w miarę wzrostu bazy danych). W wielu przypadkach pokusą jest po prostu zaakceptowanie wartości domyślnych i kontynuowanie rozwoju projektu. Może to prowadzić do nieoczekiwanego negatywnego wpływu na wydajność, kopie zapasowe i integralność danych na późniejszym etapie cyklu życia aplikacji, na przykład gdy Twój zespół wdraża analitykę i pulpity nawigacyjne MySQL.
Aby uniknąć tych potencjalnych pułapek, przyjrzymy się bliżej niektórym z najczęściej używanych silników pamięci masowej obsługiwanych przez MySQL (od wersji 5.7).
Obsługiwane silniki pamięci masowej
Jakie mam opcje?
Domyślnie MySQL 5.7 obsługuje dziesięć silników pamięci masowej (InnoDB, MyISAM, Memory, CSV, Archive, Blackhole, NDB, Merge, Federated i Example). Aby zobaczyć, które z nich są dostępne i obsługiwane przez Twój serwer, użyj tego polecenia:
mysql> POKAŻ SILNIKI\G
Spowoduje to wyświetlenie listy silników pamięci masowej z informacją, które są dostępne, niedostępne lub które są obecnie ustawione na domyślne. Kolumna „Wsparcie:” wyświetli odpowiednio „TAK”, „NIE” lub „DOMYŚLNIE”.
W niektórych aplikacjach może zaistnieć potrzeba posiadania różnych silników pamięci masowej dla różnych tabel w tej samej bazie danych. To jest przykład, dlaczego musisz dokładnie zaplanować model danych dla swojej aplikacji. Jednak w większości przypadków potrzebny będzie tylko jeden silnik pamięci masowej.
Możliwości silnika pamięci masowej
W czym są dobrzy?
Przyjrzyjmy się bliżej niektórym z najczęściej używanych silników pamięci masowej. To da nam wyobrażenie o tym, do czego został zaprojektowany każdy silnik i jak najlepiej można go wykorzystać do realizacji naszych celów biznesowych.
InnoDB: Domyślna opcja w MySQL 5.7, InnoDB to solidny silnik pamięci masowej, który oferuje:
- Pełna zgodność z ACID
- Zatwierdzanie, wycofywanie i odzyskiwanie po awarii
- Blokowanie na poziomie wiersza
- Ograniczenia integralności referencyjnej KLUCZY OBCYCH
- Zwiększ współbieżność wielu użytkowników (poprzez odczyty bez blokowania)
Dzięki powyższej funkcjonalności, którą oferuje InnoDB, jest oczywiste, dlaczego jest to domyślny silnik w MySQL. Jest to silnik, który działa dobrze i oferuje wiele wymaganych atrybutów, których potrzebuje każda baza danych. Jednak wyczerpujące omówienie wszystkich jego możliwości wykracza poza zakres tego artykułu. Jest to silnik, który najprawdopodobniej będzie używany w większości aplikacji.
MyISAM: Funkcjonalność, która wyróżnia MyISAM, to jego zdolność do:
- pełnotekstowe indeksy wyszukiwania
- Blokowanie na poziomie stołu
- brak obsługi transakcji
Chociaż jest to szybki silnik pamięci masowej, najlepiej nadaje się do użytku w aplikacjach o dużym natężeniu odczytu i najczęściej odczytywanych, takich jak hurtownie danych i aplikacje internetowe, które nie wymagają obsługi transakcji ani zgodności z ACID.
NDB (lub NDBCLUSTER):Jeśli baza danych będzie działać w środowisku klastrowym, NDB jest preferowanym silnikiem przechowywania. Najlepiej, gdy potrzebujesz:
- Przetwarzanie rozproszone
- Wysoka redundancja
- Wysoka dostępność
- Najwyższy możliwy czas pracy
Zwróć uwagę, że obsługa NDB nie jest zawarta w dystrybucji standardowych plików binarnych MySQL Server 5.7. Będziesz musiał zaktualizować do najnowszej wersji binarnej MySQL Cluster. Jeśli jednak programujesz w środowisku klastrowym, prawdopodobnie masz niezbędne doświadczenie, aby poradzić sobie z tymi zadaniami.
CSV: Przydatny silnik pamięci masowej, gdy dane muszą być udostępniane innym aplikacjom korzystającym z danych w formacie CSV. Tabele są przechowywane jako pliki tekstowe z wartościami oddzielonymi przecinkami. Chociaż ułatwia to udostępnianie danych skryptom i aplikacjom, jedną wadą jest to, że pliki CSV nie są indeksowane. Dlatego dane powinny być przechowywane w tabeli InnoDB aż do etapu importu/eksportu procesu.
Czarna dziura: Ten silnik akceptuje, ale nie przechowuje danych. Podobnie do UNIX /dev/null, zapytania zawsze zwracają pusty zestaw. Może to być przydatne w środowisku rozproszonej bazy danych, w którym nie chcesz przechowywać danych lokalnie ani w sytuacjach testowych wydajności lub innych.
Archiwum: Jak sama nazwa wskazuje, ten silnik doskonale nadaje się do rzadko używanych danych historycznych. Tabele nie są indeksowane, a kompresja następuje po wstawieniu. Transakcje nie są obsługiwane. Użyj tego silnika pamięci do archiwizacji i odzyskiwania danych z przeszłości.
Sfederowane: Ten silnik przechowywania służy do tworzenia jednej, lokalnej, logicznej bazy danych poprzez połączenie kilku różnych fizycznych serwerów MySQL. Żadne dane nie są przechowywane na serwerze lokalnym, a zapytania są automatycznie wykonywane na odpowiednim serwerze zdalnym. Jest idealny do rozproszonych środowisk data mart i może znacznie poprawić wydajność podczas korzystania z MySQL do raportowania analitycznego.
Wyznaczanie silnika pamięci
Jak zmienić używany silnik pamięci masowej?
Używany aparat magazynu jest ustalany podczas tworzenia tabeli. Jak wspomniano wcześniej, InnoDB jest domyślnym silnikiem przechowywania w MySQL w wersji 5.5 i nowszych. Jeśli chcesz użyć innego, najlepiej zrobić to w instrukcji CREATE TABLE. Załóżmy na przykład, że zidentyfikowałeś tabelę, która wymaga użycia silnika przechowywania CSV. Twoja nadmiernie uproszczona instrukcja CREATE TABLE może wyglądać tak:
mysql> CREATE TABLE Shared_Data (
-> Data_ID INTEGER NIE NULL,
-> Nazwa VARCHAR(50) NOT NULL,
-> Opis VARCHAR(150)
-> ) ENGINE=’CSV’;
Po czym jak zwykle wykonalibyśmy instrukcję INSERT:
mysql> INSERT INTO Shared_Data VALUES
-> (1,'urządzenie pierwsze', 'najnowsza wersja najlepszej technologii'),
-> (2,'urządzenie drugie', 'najszybsze urządzenie na rynku');
Po pomyślnym sprawdzeniu katalogu bazy danych powinien znajdować się w nim plik „Shared_Data.CSV”, który zawiera rekordy wstawione do tabeli Shared_Data.
Tę samą metodologię można zastosować do dowolnego z wielu silników pamięci masowej obsługiwanych przez MySQL. Chociaż możliwa jest zmiana silnika przechowywania po utworzeniu tabeli za pomocą ALTER TABLE oświadczenie, najlepszą praktyką jest odpowiednie zaplanowanie i ustawienie tego na początku.
Zamykanie
MySQL ma wiele opcji
Jak widać, MySQL oferuje obsługę silników pamięci masowej zaprojektowanych do obsługi bardzo różnych zadań w wielu różnych środowiskach. Określenie, których silników należy używać i kiedy ich używać, może pomóc nam uniknąć niepotrzebnych komplikacji i problemów z wydajnością w miarę skalowania naszych aplikacji.
Niezależnie od tego, czy potrzebujesz 99,999% czasu bezawaryjnej pracy i niezawodności w rozproszonym klastrze obliczeniowym, czy potrzebujesz obsługi transakcji zgodnej z ACID z ograniczeniami FOREIGN KEY, MySQL ma silnik pamięci masowej dostosowany do Twoich potrzeb.
Jak zawsze, właściwe planowanie i identyfikacja celów i wymagań projektu to najlepszy sposób na dokładne określenie, które silniki pamięci masowej są najlepiej dopasowane do Twojej aplikacji. Mamy nadzieję, że ten artykuł służy jako przydatny punkt wyjścia do pomocy w tym zakresie.
Ten artykuł pierwotnie pojawił się tutaj. Opublikowane ponownie za zgodą. Tutaj możesz przesłać swoje skargi dotyczące praw autorskich.
