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

28

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?

Christophetd
źródło
Tak długo, jak pozostawisz (powiedzmy) 2-3 GB poza obszarem partycjonowania z powodu nadmiernej obsługi administracyjnej, myślę, że jesteś z tym bezpieczny. Nie widzę w tym tak dużego problemu. Większość dysków SSD ma już część dysku, która nie jest dostępna dla systemu operacyjnego. Ta przestrzeń jest wykorzystywana do wyrównywania zużycia i nadmiernej kontroli, w przypadku gdy dysk twardy jest zbyt pełny. Te dodatkowe GB zapewnią więcej miejsca na dysku SSD do dystrybucji danych w celu uniknięcia szkód. Jeśli jesteś hardkorowy i chcesz to zrobić, możesz dowiedzieć się, ile układów pamięci ma Twój SSD i dać 1 GB na chip. 10 żetonów to 10 niepodzielonych na partycje GB.
Ismael Miguel
5
Za tyle, ile jest to warte, rutynowo importujemy znacznie więcej danych niż to. Jedna z naszych tabel zawiera znacznie więcej danych niż importujesz, a my mamy kilkaset tabel. Używamy dysków SSD. Oczekuję, że nic ci nie będzie.
ChrisInEdmonton
4
W dzisiejszych czasach dyski SSD są wystarczająco inteligentne, aby same radziły sobie z wyrównywaniem zużycia, nawet bez obsługi systemu operacyjnego (chociaż system operacyjny prosi o przepisanie tego samego bloku, kontroler dysku SSD za każdym razem zapisuje w innym bloku), więc wszystko będzie dobrze.
7
Czerwony śledź. Częstotliwość awarii dysków SSD nie jest powodem do zmartwień - wystarczy, że będą one trwać dłużej niż równoważna rdza.
Sobrique,
2
Ludzie martwią się zbytnio o swoje dyski SSD. Zasadniczo nigdy nie zdołasz „zniszczyć” dysku SSD przez przypadek, a nawet robienie tego celowo może wymagać tygodni lub miesięcy ciągłego zapisu. Nawet jeśli go „zniszczysz”, nadal dostarczy dane jako tylko do odczytu. Przestań się martwić i po prostu z niego skorzystaj. Równie dobrze możesz zapytać, w jaki sposób głowica odczytu / zapisu dysku twardego ulega zużyciu przez przyspieszenie.
mic_e

Odpowiedzi:

27

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.

Austin T French
źródło
5
„Jeśli nie, to i tak spodziewaj się niepowodzenia”. Jeśli serwer nie używać zbędnych dysków, nadal zdecydowanie spodziewać awarii w pewnym momencie, i plan dla niego. Po prostu w przypadku nadmiarowości awaria pojedynczego urządzenia pamięci masowej ma znacznie mniejsze prawdopodobieństwo doprowadzenia do przestoju systemu.
CVn
@ MichaelKjörling tak, właśnie. Moim zdaniem „poprawnie zbudowany” zakłada również kopie zapasowe bazy danych w przypadku awarii ... Ale czasami nawet to, co powinno być OK, aby pozostało niewypowiedziane, należy powiedzieć, dzięki.
Austin T Francuski
19

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.

Ctrl-alt-dlt
źródło
12
Czy mogę zapytać, dlaczego głosowanie negatywne?
Ctrl-alt-dlt
Możesz zapytać, ale najwyraźniej nie otrzymasz.
Pozew funduszu Moniki z
12

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ą.

James Mertz
źródło
1
RAID1 zrobiłby bardzo niewiele dla rodzaju obrażeń, o których mówisz. Poziom zużycia prawdopodobnie będzie deterministyczny, co oznacza, że ​​będą się ścierać dokładnie w tym samym tempie i w ten sam sposób, powodując błędy występujące prawie dokładnie w tych samych miejscach.
Aron
z powiązanego artykułu: „elektronika na dysku SSD ulegnie awarii na długo przed zużyciem NAND”… czekaj, co?
Michael
4

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).

AaronLS
źródło
3

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.

Damon
źródło
2
Sektory to tradycyjnie 1 KiB? Proszę o cytowanie. Na dyskach obrotowych powszechne są dwa rozmiary sektorów: 512 bajtów (tradycyjne, jak na moich dyskach twardych 4 TB, w kompatybilnych z IBM datach sięgają około 1981 roku) i 4096 bajtów („Format zaawansowany”). Jednostki alokacji na poziomie systemu plików mogą różnić się rozmiarem, ale to zupełnie inna sprawa i jest to wyłącznie konstrukcja systemu plików, aby utrzymać alokację struktur danych do rozsądnego rozmiaru w systemach plików, które nie rozwijają ich dynamicznie w razie potrzeby ; poza tym wątpię, aby ustalone rozmiary bloków 1 KiB były bardzo powszechne w praktyce.
CVn
@ MichaelKjörling: Dziękujemy za bardzo cenny wkład. Oczywiście przeczytałeś i zrozumiałeś odpowiedź, prawda? Istotnym faktem jest to, że dyski SSD mają rozmiary bloków fizycznych, które są znacznie większe, niezależnie od wielkości sektora logicznego (które widziałem gdzieś od 500 do 4096 bajtów, nawet o rozmiarach innych niż moc dwóch). Nie trzeba cytować.
Damon
1

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.

Hennes
źródło
Wiem, że użycie dowolnego dysku o maksymalnej pojemności 7/24 może go uszkodzić ... Moje pytanie brzmi: czy jest bezpieczny przez ograniczony czas (powiedzmy kilka razy 2-3 godziny)
christophetd
@christophetd - To zależy. Zaktualizuj swoje pytanie, aby oszacować ilość danych. To bardziej o procent dysku. Najgorsze jest pisanie 20 GB na godzinę na dysku SSD o pojemności 80 GB niż 20 GB na dysku SSD o pojemności 1 TB.
Ramhound
Z tej samej uwagi: Przeważnie pusty dysk oznacza, że ​​wiele „pustych” komórek flash jest wykorzystywanych do wyrównywania zużycia. (a większy dysk z taką samą ilością danych jest większy w tym samym czasie).
Hennes
1

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.

MonkeyZeus
źródło
-2

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.

serv-inc
źródło
2
Ta odpowiedź tak naprawdę nie zawiera żadnych istotnych informacji, które nie zostały jeszcze powiedziane, poza tym jest to w zasadzie komentarz z zawartym w niej linkiem.
Ramhound
@Ramhound: czy mógłbyś wyrazić zgodę na komentarz (dziękuję, btw), a także to, aby oznaczyć go jako przestarzałe? Czy nadal uważasz, że informacje już powiedziane / nieistotne?
serv-inc
Chociaż nie jest to już link, szczerze mówiąc, sama informacja techniczna tak naprawdę nie dotyczy pytania użytkownika w odniesieniu do prowadzenia bazy danych na dysku SSD I
Ramhound
@Ramhound: dla mnie wydawało się, że chodzi o import, a nie ucieczkę. Sądząc po opiniach, wydaje się, że masz rację
serv-inc