Każdy architekt baz danych projektujący bazę danych MySQL staje przed problemem wyboru odpowiedniego silnika pamięci masowej. Zwykle aplikacja korzysta tylko z jednego silnika:MyISAM lub InnoDB . Spróbujmy jednak być trochę bardziej elastyczni i wyobraźmy sobie, jak można używać różnych silników pamięci masowej.
Początkowy model danych
Na początek zbudujmy uproszczony model danych dla systemu CRM (zarządzania relacjami z klientami), którego użyjemy, aby zilustrować ten punkt. Projekt obejmie główne funkcje CRM:dane sprzedażowe, definicje produktów oraz informacje do analityki. Nie będzie zawierał szczegółów używanych zwykle w systemach CRM.
Jak widać, ten model danych zawiera tabele przechowujące informacje transakcyjne o nazwie sale i sale_item . Gdy klient coś kupi, aplikacja utworzy nowy wiersz w sale stół. Każdy zakupiony produkt zostanie odzwierciedlony w sale_item stół. Powiązana tabela, sale_status , służy do przechowywania możliwych statusów (tj. oczekujący, zakończony itp.).
product tabela przechowuje informacje o towarach. Definiuje każdy produkt i jego podstawowe deskryptory. W bardziej szczegółowym diagramie dodałbym więcej tabel do obsługi specyfikacji i kategoryzacji produktów. Ale dla naszych obecnych potrzeb nie jest to konieczne.
Tabela klientów przechowuje dane o klientach. Jest to integralna część każdego systemu CRM i zazwyczaj śledzi indywidualną aktywność wszystkich użytkowników. Oczywiście często zawiera naprawdę szczegółowe informacje. Ale jak już zauważyłem, nie potrzebujemy teraz tych informacji.
log tabela przechowuje, co każdy klient zrobił w aplikacji. Oraz report_sales tabela jest przeznaczona do wykorzystania w analizie danych.
Następnie opiszę silniki pamięci masowej MySQL, które mogłyby zostać wykorzystane w tym projekcie. A później omówimy, który silnik jest odpowiedni dla każdego typu stołu.
Przegląd silników pamięci masowej MySQL
Silnik pamięci masowej to moduł oprogramowania, którego MySQL używa do tworzenia, odczytywania lub aktualizowania danych z bazy danych. Nie zaleca się losowego wybierania silnika, ale wielu programistów chętnie korzysta z MyISAM lub InnoDB, chociaż dostępne są również inne opcje. Każdy silnik ma swoje wady i zalety, a właściwy dobór silnika zależy od kilku czynników. Rzućmy okiem na najpopularniejsze silniki.
- MyISAM ma długą historię z MySQL. Był to domyślny silnik baz danych MySQL przed wydaniem 5.5. MyISAM nie obsługuje transakcji i ma tylko blokowanie na poziomie tabeli. Jest używany głównie w aplikacjach intensywnie korzystających z odczytu.
- InnoDB to ogólny silnik pamięci masowej, który równoważy wysoką niezawodność i dobrą wydajność. Obsługuje transakcje, blokowanie na poziomie wiersza, odzyskiwanie po awarii i kontrolę współbieżności wielu wersji. Ponadto zapewnia ograniczenie integralności referencyjnej klucza obcego.
- Pamięć silnik przechowuje wszystkie dane w pamięci RAM. Może być używany do przechowywania odnośników wyszukiwania.
- Inna wyszukiwarka, CSV , przechowuje dane w plikach tekstowych z wartościami oddzielonymi przecinkami. Ten format jest używany głównie do integracji z innymi systemami.
- Scal to dobry wybór dla systemów raportowania, takich jak hurtownie danych. Pozwala na logiczne grupowanie zestawu identycznych tabel MyISAM, do których można się również odwoływać jako jeden obiekt.
- Archiwum jest zoptymalizowany do szybkiego wstawiania. Przechowuje informacje w kompaktowych, nieindeksowanych tabelach i nie obsługuje transakcji. Mechanizm przechowywania archiwum jest idealny do przechowywania dużych ilości rzadko używanych danych historycznych lub archiwalnych.
- Federacja silnik oferuje możliwość odseparowania serwerów MySQL lub stworzenia jednej logicznej bazy danych z wielu serwerów fizycznych. Żadne dane nie są przechowywane w lokalnych tabelach, a zapytania są automatycznie wykonywane w zdalnych (sfederowanych) tabelach.
- Czarna dziura silnik działa jak „czarna dziura”, która przyjmuje dane, ale ich nie przechowuje. Wszystkie wybory zwracają pusty zbiór danych.
- Silnik Przykład służy do pokazania, jak tworzyć nowe silniki pamięci masowej.
To nie jest pełna lista silników pamięci masowej. MySQL 5.x obsługuje dziewięć z nich prosto z pudełka oraz dziesiątki innych opracowanych przez społeczność MySQL. Więcej szczegółów na temat silników pamięci masowej można znaleźć w oficjalnej dokumentacji MySQL.
Aktualizacja projektu modelu danych
Spójrz ponownie na nasz model danych. Oczywiście różne tabele będą używane w różny sposób. sale tabela musi obsługiwać transakcje. Z drugiej strony log i report_sales tabele nie wymagają tej funkcji. Główna misja log tabela przechowuje dane z maksymalną wydajnością. Szybkie pobieranie jest głównym wymaganiem report_sales stół.
Pamiętajmy o powyższych punktach i zmodyfikujmy nasz schemat bazy danych. W Vertabelo możesz ustawić „Silnik pamięci” w Właściwościach tabeli płyta. Proszę spojrzeć na poniższe zdjęcia.
Ustawianie silnika pamięci
Zobaczmy więc zaktualizowany projekt bazy danych.
Określiłem silniki pamięci masowej dla istniejących tabel i zreorganizowałem report_sales stół. Jak widać, tabele podzielone są na trzy grupy:
- Tabele transakcji używane w głównej aplikacji
- Tabele raportów do analizy BI
- Tabela dziennika do przechowywania całej aktywności użytkownika
Porozmawiajmy o nich wszystkich osobno.
Tabele transakcji
Tabele te zawierają dane wprowadzane przez użytkowników podczas codziennych, rutynowych operacji. W naszym przypadku byłyby informacje o sprzedaży, takie jak:
- który pracownik dokonał sprzedaży
- kto kupił produkt
- co zostało sprzedane
- ile to kosztowało
W większości przypadków InnoDB jest najlepszym rozwiązaniem dla tabel transakcyjnych. Ten aparat magazynu obsługuje blokowanie wierszy, a niektórzy użytkownicy mogą ze sobą współpracować. Podobnie InnoDB umożliwia korzystanie z transakcji i kluczy obcych. Ale, jak wiesz, te świadczenia nie są bezpłatne; silnik może wykonywać wybrane instrukcje wolniej niż MyISAM i zapisywać dane z mniejszą wydajnością niż Archiwizacja.
Wszystkie opisane powyżej silniki mają pewne zabezpieczenia, więc programiści nie muszą pisać złożonych funkcji przywracania dla każdej operacji. W typowej aplikacji sprzedażowej zachowanie spójności danych jest ważniejsze niż możliwe problemy z wydajnością.
Tabele raportów
W nowym projekcie podzieliłem jeden stół na kilka mniejszych. Oszczędza to wysiłek, jeśli chodzi o zarządzanie danymi oraz konserwację tabel i indeksów. Pozwala nam również stworzyć tabelę MERGE sale_report do łączenia innych tabel raportów. W rezultacie narzędzie BI nadal pobiera dane z jednej ogromnej tabeli (do celów analitycznych), ale mamy tę zaletę, że pracujemy z mniejszymi tabelami.
Report_sale_{year} tabele są tabelami MyISAM. Ten aparat magazynu nie obsługuje transakcji i może blokować tylko tabelę jako całość. Ponieważ MyISAM nie martwi się o te złożone elementy, szybko wykonuje operacje manipulacji danymi. Ze względu na swoją strukturę plików ten silnik pamięci odczytuje dane szybciej niż bardziej popularny InnoDB.
Tabela dziennika
Mechanizm przechowywania archiwum to dobry wybór do przechowywania danych dziennika. Może szybko wstawiać wiersze i kompresować przechowywane dane. Przechowywanie informacji o działaniach użytkowników niesie ze sobą ogromne korzyści. Archiwum ma jednak pewne ograniczenia. Nie obsługuje operacji aktualizacji i powoli pobiera dane. Ale w tabeli dziennika opisane korzyści są ważniejsze niż wady.
Integracja silników pamięci masowej
Każdy system musi być zintegrowany z życiem zewnętrznym. W przypadku aplikacji mogą to być użytkownicy, którzy wypełniają tabele referencyjne i transakcyjne. Mogą to być usługi i integracja przez REST, SOAP, WCF lub coś takiego. I wreszcie, co nie mniej ważne, może to być integracja z bazą danych.
MySQL i Oracle opracowały dwa naprawdę pomocne silniki pamięci masowej:Sfederowane i CSV . Pierwszy, Sfederowany , należy używać do ładowania danych z zewnętrznej bazy danych MySQL. Drugi mechanizm pamięci masowej, CSV , umożliwia bazom danych zapisywanie rekordów w formacie CSV i odczytywanie plików oddzielonych przecinkami na antenie, bez żadnych dodatkowych wysiłków.
Jak widać, używanie różnych silników pamięci masowej do różnych celów zapewnia większą elastyczność bazy danych. Jeśli architekt baz danych podejmie decyzję po rozważeniu wszystkich zalet i wad, wynik może być naprawdę imponujący.
Czy masz doświadczenie w korzystaniu z różnych silników pamięci masowej w projektowaniu baz danych? Chciałbym zobaczyć Twoje wskazówki i sugestie. Podziel się nimi w sekcji komentarzy.
