Una massiccia importazione di dati MySQL su un SSD può danneggiarlo?

Devo importare molti dati (~ 100 milioni di righe, ~ 100 volte) in un database MySQL. Attualmente, è memorizzato sul mio disco rigido e il collo di bottiglia della mia importazione sembra essere la velocità di scrittura del disco rigido.

Ho sentito che agli SSD non piacciono le enormi scritture continue e che tende a danneggiarli. Cosa pensi? È davvero un problema con i moderni SSD?

Non è davvero una risposta semplice a questo.

Gli SSD non si preoccupano delle scritture continue tanto quanto quante volte un particolare settore viene sovrascritto. Quando sono usciti gli SSD per la prima volta, qualcosa come SQL era una parolaccia in quanto il sistema operativo in generale trattava l'unità come un HDD tradizionale e gli errori erano molto frequenti.

Da allora, le unità sono diventate più grandi, più economiche, più affidabili, destinate a più letture / scritture e i sistemi operativi sono diventati più intelligenti.

Gli SSD in SQL non sono solo comuni, ma spesso incoraggiati. Sentiti libero di consultare il sito gemello DBA .

Il mio pensiero è farlo, supponendo che il server SQL sia stato creato correttamente con dischi ridondanti. In caso contrario, aspettatevi comunque un fallimento alla fine.

Le letture vanno bene e gli SSD possono avere i loro bit letti senza alcun effetto dannoso.

Le scritture sono un'altra questione. L'eliminazione di un bit influisce sull'integrità del bit e dopo molte scritture sequenziali, il bit smetterà di accettare del tutto nuove scritture. Tuttavia può ancora essere letto.

Consentitemi di dire che i limiti di scrittura sulle nuove unità aziendali sono enormi. Prendi il nuovo 845DC Pro di Samsung. È valido per 10 scritture di unità al giorno per 5 anni in garanzia. Immagino che farà il doppio di quel numero. Per dirla in numeri, sono 14.600 TB scritti in 5 anni sul modello da 800 GB.
O 2920 TB all'anno,
o 8 TB al giorno, per cinque anni .

Fammi vedere un disco rigido con una garanzia che copre così tanto uso. Non sono nemmeno sicuro che potresti scrivere 8 TB su un HDD in un giorno: - (50 Mb / s throughput medio * 60 (secondi) * 60 (minuti) * 24 (ore) = 4.320.000 MB / giorno = 4.32 TB / giorno) Si scopre che non è possibile (su un disco medio).

Fintanto che usi un'unità come questa, basata su V-NAND (o SLC altrettanto durevole), non una basata su TLC o flash MLC difettoso, dovresti andare bene. E comunque, RAID 10 e i backup sono i tuoi amici per un motivo. E almeno se il limite di scrittura SSD diventa un problema, è ancora possibile leggere i dati memorizzati nei bit difettosi.

Gli SSD sono anche più economici da gestire, i modelli più freddi, più silenziosi e aziendali sono particolarmente resistenti ai problemi di alimentazione. Niente più timori di crash di testa e, naturalmente, un enorme aumento delle prestazioni per le esigenze di accesso al database.

Scrivere su SSD non è necessariamente male. È la scrittura e la riscrittura di un singolo blocco che fa male. Significa che se si scrive un file, eliminarlo, quindi scriverlo di nuovo o apportare ripetutamente piccole modifiche a un file. Ciò causa l'usura degli SSD. I database rientrerebbero sicuramente in questa categoria.

Tuttavia, secondo questo articolo , petabyte di dati sono stati scritti su SSD e sono ancora utilizzabili. Ciò è probabilmente dovuto ai progressi nell'indossare il livellamento :

Indossa tentativi di livellamento per aggirare queste limitazioni organizzando i dati in modo tale che le cancellazioni e le riscritture siano distribuite uniformemente sul supporto. In questo modo, nessun singolo blocco di cancellazione fallisce prematuramente a causa di un'alta concentrazione di cicli di scrittura.

Nella tua situazione particolare vorrei che i database risiedessero sull'SSD per la velocità, ma facessero il backup su base giornaliera. Potresti anche considerare di ottenere due SSD in un array RAID 1 . La probabilità che due SSD falliscano contemporaneamente è bassa.

Nota: gli array RAID NON sono backup !!!! Non importa se si utilizza un array RAID o meno, disporre di un backup. Non importa se si utilizza un SSD o meno, disporre di un backup.

Supponiamo che la tua importazione non comporti aggiornamenti o eliminazioni. Quindi stai facendo tutti gli inserimenti. Questo dovrebbe solo scrivere nuovi dati nel registro delle transazioni.

Ciò significa che quando i dati vengono aggiunti, vengono sempre scritti in un nuovo settore. Potrebbero esserci alcuni buffer / swap che vengono sfornati / scritti più volte, ma ignorando ciò, tutti quegli inserti porterebbero teoricamente a non più di una scrittura per settore . A seconda dell'implementazione di MySQL e del tipo di inserto in blocco che si sta eseguendo, è possibile generare un secondo set di scritture in seguito quando il registro delle transazioni è integrato nel file di dati principale (sto andando a conoscenza di diversi motori DB e supponendo che MySQL sia in qualche modo simile nel modo in cui i log delle transazioni vengono scaricati).

Il punto è che non stai "sfornando" l'SSD. Cioè, non stai apportando molte modifiche / mosse / eliminazioni / ecc. che potrebbe potenzialmente riscrivere più volte negli stessi settori. Quindi essenzialmente si genererà solo un numero molto piccolo di scritture per settore ed è quello che conta davvero.

Supponendo che non si stia riempiendo completamente l'SSD, dovrebbe esserci spazio sufficiente per quei punti caldi (come buffer / swap) che vengono sfornati per ridurre al minimo l'usura attraverso algoritmi di livellamento dell'usura.

(Gli indici potrebbero essere un'altra cosa. Dato che gli indici cluster in molti DB comportano molte modifiche quando vengono inseriti i dati. Di solito quando si eseguono istanze di grandi dimensioni in un ambiente di data warehouse, si disattivano gli indici durante l'importazione di massa, quindi si aggiorna dopo.)

Questo non è un problema.

Innanzitutto, gli SSD sono notevolmente migliorati negli ultimi anni. L'overprovisioning e il livellamento dell'usura (e in piccola parte, il comando TRIM, anche se non applicabile nel tuo caso) li hanno resi abbastanza adatti come dischi per uso generale di tipo pesante. Non sto usando nient'altro che SSD sul mio PC di sviluppo (che fa regolarmente molta compilazione) senza nemmeno avvicinarmi al conteggio dei cicli di cancellazione.

Inoltre, questa affermazione:

Agli SSD non piacciono le enormi scritture continue e che tende a danneggiarle

è assolutamente sbagliato. È vero il contrario, frequenti piccole scritture , se non altro, possono causare danni agli SSD.

A differenza dei tradizionali dischi rigidi, gli SSD (o meglio il flash basato su NAND all'interno) sono organizzati fisicamente in blocchi di grandi dimensioni che logicamente contengono diversi settori. Una dimensione tipica del blocco è 512kB mentre i settori (che è l'unità utilizzata dal filesystem) sono tradizionalmente 1kB (sono possibili valori diversi, due decenni fa 512B era comune).
Tre cose possono essere fatte con un blocco da 512 KB. Può essere letto da, parte di esso o tutto può essere programmato (= scritto in), e tutto può essere cancellato. La cancellazione è problematica perché c'è un numero limitato di cicli di cancellazione e puoi cancellare solo un blocco completo.

Pertanto, le scritture di grandi dimensioni sono molto compatibili con SSD, mentre le scritture di piccole dimensioni non lo sono.

Nel caso di piccole scritture, il controller deve leggere un blocco, modificare la copia, cancellare un blocco diverso e programmarlo. Senza memorizzazione nella cache, nel peggiore dei casi, è necessario cancellare 512.000 blocchi per scrivere 512 kilobyte. Nel migliore dei casi (scrittura grande e continua) è necessario eseguire esattamente 1 cancellazione.

Effettuare un'importazione in un database MySQL è molto diverso dal fare molte query di inserimento separate. Il motore è in grado di comprimere molte scritture (sia dati che indici) insieme e non deve sincronizzarsi tra ciascuna coppia di inserti. Ciò equivale a un modello di scrittura molto più compatibile con SSD.

Agli SSD non piace. Se si mantiene la massima velocità di scrittura per 5-10 anni (24 ore al giorno, 7 giorni alla settimana), si potrebbe finire con un SSD rotto.

Ofc. Dopo 5 anni la maggior parte dei server ha raggiunto la fine della sua vita economica.

Disclaimer:
non provarlo con la primissima generazione di SSD. Quelli dove erano meno robusti.

Se sei veramente interessato a capire i dettagli, avrai bisogno della risposta alla seguente domanda:

In media quanti byte ci sono in ogni riga?

Se puoi dirmi che ci sono 10 colonne, ogni colonna è varchar (100) e la codifica è UTF-8, allora posso ipotizzare nel peggiore dei casi che tu abbia 4.000 byte di dati per riga e aggiungere altri byte per meta-dati quindi diciamo 4.200 byte?

La tua tortura SQL calcola su 4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytesdei dati scritti sul disco

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

In questo scenario teorico nel peggiore dei casi scriverai 42 TB sul disco

Secondo questo articolo , fornito da @KronoS dovresti essere buono per circa 25 ulteriori round del tuo SQL di tortura.

Come diceva il poster di questo articolo su SSD , ciò che è veramente dannoso è scrivere ripetutamente piccoli pezzi di dati.

• i bit sono memorizzati in celle {1,2,3} bit. Questi hanno una durata limitata.
• le celle sono raggruppate in [2-16] pagine KB (la più piccola unità scrivibile)
• le pagine sono raggruppate in blocchi (128-256 pagine) (la più piccola unità cancellabile)
• affinché una pagina venga riscritta, prima --- e il suo intero blocco --- deve essere prima cancellato

Ecco perché si consiglia di

• mai scrivere meno di una pagina alla volta,
• buffer piccole scritture e
• richieste di lettura e scrittura separate
• "Una grande scrittura a thread singolo è migliore di molte piccole scritture simultanee"

Quindi, una quantità davvero grande in una volta sembra molto meglio.