Czy masowy import danych MySQL na dysk SSD może go uszkodzić?

Muszę zaimportować całkiem sporo danych (~ 100 milionów wierszy, ~ 100 razy) do bazy danych MySQL. Obecnie jest on przechowywany na moim dysku twardym, a wąskim gardłem mojego importu wydaje się być szybkość zapisu na dysku twardym.

Słyszałem, że dyski SSD nie lubią masowych ciągłych zapisów i że mają tendencję do ich niszczenia. Co myślisz? Czy to naprawdę problem na nowoczesnych dyskach SSD?

To naprawdę nie jest prosta odpowiedź na to.

Dyski SSD nie dbają o ciągłe zapisy, tyle ile razy dany sektor jest nadpisywany. Kiedy pojawiły się dyski SSD, coś w rodzaju SQL było złym słowem, ponieważ system operacyjny ogólnie traktował dysk jak tradycyjny dysk twardy, a awarie występowały bardzo często.

Od tego czasu dyski stały się większe, tańsze, bardziej niezawodne, przeznaczone do większej ilości odczytu / zapisu, a systemy operacyjne stały się bardziej inteligentne.

Dyski SSD w SQL są nie tylko powszechne, ale często zalecane. Zachęcamy do przejrzenia siostrzanej strony DBA .

Myślę o tym, zakładając, że serwer SQL jest poprawnie zbudowany z redundantnymi dyskami. Jeśli nie, to i tak spodziewaj się niepowodzenia.

Odczyty są w porządku, a na dyskach SSD można odczytać ich bity bez żadnego szkodliwego efektu.

Pisanie to inna sprawa. Usunięcie bitu wpływa na integralność bitu i po wielu sekwencyjnych zapisach, bit całkowicie przestanie akceptować nowe zapisy. Można go jednak nadal czytać.

Powiem tylko, że limity zapisu na nowych dyskach dla przedsiębiorstw są ogromne. Weź nowy Samsung 845DC Pro. Jest dobry na 10 zapisów dysku dziennie przez 5 lat gwarancji. Wyobrażam sobie, że zrobi to dwa razy tyle. Podsumowując, jest to 14 600 TB zapisanych w ciągu 5 lat w modelu 800 GB.
Lub 2920 TB rocznie,
lub 8 TB dziennie przez pięć lat .

Pokaż mi dysk twardy z gwarancją obejmującą tak wiele zastosowań. Nie jestem nawet pewien, czy mógłbyś zapisać 8 TB na HDD w ciągu jednego dnia: - (50 MB / s średnia przepustowość * 60 (sekund) * 60 (minut) * 24 (godziny) = 4320 000 MB / dzień = 4,32 TB / dzień) Okazuje się, że nie możesz (na przeciętnym dysku).

Dopóki używasz takiego napędu, opartego na V-NAND (lub równie trwałym SLC), a nie takiego opartego na TLC lub złej pamięci flash MLC, wszystko powinno być w porządku. Poza tym RAID 10 i kopie zapasowe są z jakiegoś powodu twoim przyjacielem. A przynajmniej jeśli limit zapisu SSD stanie się problemem, nadal możesz odczytać dane zapisane w wadliwych bitach.

Dyski SSD są również tańsze w obsłudze, chłodniejsze, cichsze, a modele korporacyjne są szczególnie odporne na problemy z zasilaniem. Nigdy więcej obaw związanych z awariami głowy i oczywiście ogromny wzrost wydajności dla potrzeb dostępu do bazy danych.

Zapisywanie na dyskach SSD niekoniecznie jest złe. Pisanie i przepisywanie pojedynczego bloku jest złe. Oznacza to, że jeśli piszesz plik, usuń go, a następnie napisz go ponownie lub wprowadzaj niewielkie zmiany w pliku w kółko. Powoduje to zużycie dysków SSD. Bazy danych zdecydowanie pasowałyby do tej kategorii.

Jednak zgodnie z tym artykułem petabajty danych zostały zapisane na dyskach SSD i nadal działają. Wynika to prawdopodobnie z postępów w wyrównaniu zużycia :

Noś próbę wyrównywania, aby obejść te ograniczenia, organizując dane tak, aby skasowanie i ponowne zapisywanie były równomiernie rozłożone na całym medium. W ten sposób żaden pojedynczy blok kasujący przedwcześnie nie zawiedzie z powodu wysokiego stężenia cykli zapisu.

W twojej konkretnej sytuacji chciałbym, aby bazy danych znajdowały się na dysku SSD ze względu na szybkość, ale kopie zapasowe były wykonywane codziennie. Możesz również rozważyć umieszczenie dwóch dysków SSD w macierzy RAID 1 . Prawdopodobieństwo awarii dwóch dysków SSD w tym samym czasie jest niskie.

Uwaga: Macierze RAID NIE są kopiami zapasowymi !!!! Bez względu na to, czy korzystasz z macierzy RAID, czy nie, wykonaj kopię zapasową. Bez względu na to, czy używasz dysku SSD, czy nie, wykonaj kopię zapasową.

Załóżmy, że import nie wymaga aktualizacji ani usuwania. Więc robisz wszystkie wstawki. Powinno to być tylko zapisywanie nowych danych w dzienniku transakcji.

Oznacza to, że w miarę dodawania danych są one zawsze zapisywane w nowym sektorze. Może istnieć kilka buforów / zamian, które są wielokrotnie zmieniane / zapisywane, ale ignorując to, wszystkie te wstawki teoretycznie spowodowałyby nie więcej niż jeden zapis na sektor . W zależności od sposobu implementacji MySQL i rodzaju wykonywanej wstawki zbiorczej możesz wygenerować drugi zestaw zapisów później, gdy dziennik transakcji zostanie zintegrowany z głównym plikiem danych (rozumiem różne silniki DB , i zakładając, że MySQL jest nieco podobny w sposobie opróżniania dzienników transakcji).

Chodzi o to, że nie „ubijasz” dysku SSD. Oznacza to, że nie robisz wielu modyfikacji / ruchów / usuwania / itp. które potencjalnie wielokrotnie przepisałyby te same sektory. Więc zasadniczo wygenerujesz bardzo małą liczbę zapisów na sektor i to jest naprawdę ważne.

Zakładając, że nie wypełniasz całkowicie dysku SSD, powinna istnieć wystarczająca ilość wolnego miejsca dla tych gorących punktów (takich jak bufory / zamiana), które są ubijane, aby zminimalizować zużycie dzięki algorytmom wyrównywania zużycia.

(Indeksy mogą być inną sprawą. Ponieważ indeksy klastrowe w wielu bazach danych zawierają wiele modyfikacji podczas wstawiania danych. Zwykle podczas wykonywania dużych operacji w środowisku hurtowni danych indeksy są wyłączane podczas importu zbiorczego, a następnie aktualizowane).

To nie jest problem.

Przede wszystkim dyski SSD znacznie się poprawiły w ciągu ostatnich lat. Nadmiarowe sprawdzanie i wyrównywanie zużycia (i w niewielkim stopniu polecenie TRIM, choć nie ma zastosowania w twoim przypadku) sprawiły, że są one całkiem odpowiednie jako wytrzymałe dyski ogólnego zastosowania. Nie używam niczego poza dyskiem SSD na moim komputerze programistycznym (który regularnie wykonuje dużo kompilacji), nawet nie zbliżając się do liczby cykli kasowania.

Ponadto to oświadczenie:

Dyski SSD nie lubią masowych ciągłych zapisów i mają tendencję do ich niszczenia

jest całkowicie błędny. Przeciwnie, częste małe zapisy , jeśli w ogóle, mogą spowodować uszkodzenie dysków SSD.

W przeciwieństwie do tradycyjnych dysków twardych dyski SSD (a raczej pamięć wewnętrzna oparta na NAND) są fizycznie zorganizowane w dużych blokach, które logicznie zawierają kilka sektorów. Typowy rozmiar bloku to 512 kB, podczas gdy sektory (które są jednostką używaną przez system plików) mają tradycyjnie 1 kB (możliwe są różne wartości, dwie dekady temu 512B było powszechne).
Z blokiem 512 kB można zrobić trzy rzeczy. Można go odczytać, część lub całość można zaprogramować (= zapisać do), a całość można usunąć. Kasowanie jest problematyczne, ponieważ istnieje ograniczona liczba cykli kasowania i można usunąć tylko cały blok.

Dlatego duże zapisy są bardzo przyjazne dla SSD, podczas gdy małe zapisy nie.

W przypadku małych zapisów kontroler musi wczytać blok, zmodyfikować kopię, usunąć inny blok i zaprogramować go. Bez buforowania, w najgorszym możliwym przypadku, trzeba by usunąć 512 000 bloków, aby zapisać 512 kilobajtów. W najlepszym możliwym przypadku (duży, ciągły zapis) musisz wykonać dokładnie 1 kasowanie.

Wykonanie importu do bazy danych MySQL różni się znacznie od wykonania wielu osobnych zapytań dotyczących wstawiania. Silnik jest w stanie zwinąć wiele zapisów (zarówno danych, jak i indeksów) razem i nie musi synchronizować między każdą parą wstawek. Jest to o wiele bardziej przyjazny dla SSD wzór zapisu.

Dyski SSD tego nie lubią. Jeśli utrzymasz maksymalną prędkość zapisu przez 5-10 lat (24 godziny na dobę, 7 dni w tygodniu), możesz skończyć z uszkodzonym dyskiem SSD.

Ofc. Po 5 latach większość serwerów osiągnęła ekonomiczny okres użytkowania.

Oświadczenie:
Nie próbuj tego z dyskami SSD pierwszej generacji. Te, które były mniej wytrzymałe.

Jeśli naprawdę chcesz poznać szczegóły, musisz odpowiedzieć na następujące pytanie:

Średnio ile bajtów jest w każdym rzędzie?

Jeśli możesz mi powiedzieć, że jest 10 kolumn, każda kolumna jest varchar (100), a kodowanie to UTF-8, to w najgorszym przypadku mogę zgadywać, że masz 4000 bajtów danych na wiersz i dodaję więcej bajtów dla metadane, więc powiedzmy 4200 bajtów?

Twój torturowany SQL oblicza 4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytesdane zapisane na dysku

42 000 000 000 000/1000 = 42 000 000 000 KB

42 000 000 000/1000 = 42 000 000 MB

42 000 000/1000 = 42 000 GB

42 000/1000 = 42 TB

W tym teoretycznym najgorszym scenariuszu zapisujesz 42 TB na dysku

Zgodnie z tym artykułem , dostarczonym przez @KronoS, powinieneś być dobry na około 25 rund tortur SQL.

Jak powiedział plakat tego zapisu na dyskach SSD , naprawdę szkodliwe jest wielokrotne zapisywanie małych porcji danych.

• bity są przechowywane w komórkach {1,2,3}. Mają one ograniczoną żywotność.
• komórki są pogrupowane w strony [2-16] KB (najmniejsza możliwa do zapisania jednostka)
• strony są pogrupowane w bloki (128–256 stron) (najmniejsza usuwalna jednostka)
• aby strona została przepisana, najpierw --- i cały jej blok --- należy usunąć

Dlatego zaleca się

• nigdy nie pisz mniej niż stronę na raz,
• buforuj małe zapisy i
• oddzielne żądania odczytu i zapisu
• „Duży zapis jednowątkowy jest lepszy niż wiele małych równoczesnych zapisów”

Tak więc naprawdę duża kwota wydaje się o wiele lepsza.