Eksperymentowałem trochę z tą koncepcją w poprzedniej pracy, gdzie potrzebowaliśmy szybkiej metody kopiowania schematów między serwerami MySQL.
Rzeczywiście, po wstawieniu do tabel, które mają indeksy drugorzędne, występuje obciążenie wydajnościowe. Wstawki muszą aktualizować indeks klastrowy (czyli tabelę), a także aktualizować indeksy pomocnicze. Im więcej indeksów ma tabela, tym większe obciążenie powoduje wstawianie.
InnoDB ma funkcję o nazwie bufor zmian co trochę pomaga, opóźniając aktualizacje indeksu, ale w końcu muszą zostać scalone.
Wstawianie do tabeli bez indeksów wtórnych jest szybsze, więc kuszące jest próba odroczenia tworzenia indeksu do czasu załadowania danych, jak to opisujesz.
Percona Server, gałąź MySQL, eksperymentował z mysqldump --optimize-keys opcja. Kiedy używasz tej opcji, zmienia wyjście mysqldump na CREATE TABLE bez indeksów, następnie INSERT wszystkich danych, a następnie ALTER TABLE, aby dodać indeksy po załadowaniu danych. Zobacz https://www.percona.com/doc/ percona-server/NAJNOWSZY/management/innodb_expanded_fast_index_creation.html
Ale z mojego doświadczenia wynika, że poprawa wydajności netto była niewielka. Wstawienie dużej liczby wierszy nadal zajmuje trochę czasu, nawet w przypadku tabel bez indeksów. Następnie przywracanie musi uruchomić ALTER TABLE, aby zbudować indeksy. W przypadku dużego stołu zajmuje to trochę czasu. Kiedy policzysz czas INSERT plus dodatkowy czas na budowanie indeksów, jest to tylko kilka (niskich jednocyfrowych) procent szybciej niż wstawianie w tradycyjny sposób, do tabeli z indeksami.
Kolejną zaletą tworzenia indeksów w ramach przetwarzania końcowego jest to, że indeksy są przechowywane w bardziej zwarty sposób, więc jeśli potrzebujesz zaoszczędzić miejsce na dysku, jest to lepszy powód, aby użyć tej techniki.
Uważam, że przywrócenie wydajności przez równoczesne ładowanie kilku tabel jest o wiele bardziej korzystne dla wydajności. .
- Nowe narzędzie MySQL 8.0 mysqlpump obsługuje zrzut wielowątkowy.
- Narzędzie o otwartym kodzie źródłowym mydumper
obsługuje zrzut wielowątkowy, a także posiada narzędzie do wielowątkowego przywracania o nazwie
myloader. Najgorszą wadą mydumper/myloader jest to, że dokumentacja praktycznie nie istnieje, więc musisz być nieustraszonym, zaawansowanym użytkownikiem, aby dowiedzieć się, jak go uruchomić.
Inną strategią jest użycie mysqldump --tab aby zrzucić pliki CSV zamiast skryptów SQL. Masowe ładowanie plików CSV jest znacznie szybsze niż wykonywanie skryptów SQL w celu przywrócenia danych. Cóż, zrzuca plik SQL dla definicji tabeli i CSV dla danych do zaimportowania. Tworzy osobne pliki dla każdej tabeli. Musisz ręcznie odtworzyć tabele, ładując wszystkie pliki SQL (to jest szybkie), a następnie użyć mysqlimport
aby załadować pliki danych CSV. Narzędzie mysqlimport ma nawet --use-threads opcja wykonywania równoległego.
Przetestuj dokładnie z różną liczbą równoległych wątków. Z mojego doświadczenia wynika, że 4 wątki są najlepsze. Przy większej równoległości InnoDB staje się wąskim gardłem. Ale Twoje wrażenia mogą być inne, w zależności od wersji MySQL i wydajności sprzętu serwerowego.
Najszybszą metodą przywracania jest użycie fizycznego narzędzia do tworzenia kopii zapasowych, najpopularniejszą jest Percona XtraBackup . Pozwala to na szybkie tworzenie kopii zapasowych i jeszcze szybsze przywracanie. Kopie zapasowe plików są dosłownie gotowe do skopiowania na miejsce i użycia jako plików obszaru tabel na żywo. Minusem jest to, że musisz zamknąć serwer MySQL, aby wykonać przywracanie.
