Kann ein massiver MySQL-Datenimport auf einer SSD diese beschädigen?

Ich muss eine ganze Menge Daten (~ 100 Millionen Zeilen, ~ 100 Mal) in eine MySQL-Datenbank importieren. Derzeit ist es auf meiner Festplatte gespeichert, und der Engpass bei meinem Import scheint die Schreibgeschwindigkeit der Festplatte zu sein.

Ich habe gehört, dass SSDs keine massiven fortlaufenden Schreibvorgänge mögen und dass dies dazu neigt, sie zu beschädigen. Was denkst du? Ist das wirklich ein Problem bei modernen SSDs?

Es ist wirklich keine einfache Antwort darauf.

SSDs interessieren sich weniger für kontinuierliche Schreibvorgänge als dafür, wie oft ein bestimmter Sektor überschrieben wird. Als SSDs herauskamen, war etwas wie SQL ein schlechtes Wort, da das Betriebssystem das Laufwerk im Allgemeinen wie eine herkömmliche Festplatte behandelte und Ausfälle sehr häufig auftraten.

Seitdem sind die Laufwerke größer, billiger, zuverlässiger, für mehr Lese- und Schreibvorgänge gedacht und die Betriebssysteme sind intelligenter geworden.

SSDs in SQL sind nicht nur verbreitet, sondern werden auch häufig empfohlen. Fühlen Sie sich frei, die DBA-Schwestersite zu lesen .

Ich gehe davon aus, dass der SQL-Server ordnungsgemäß mit redundanten Datenträgern aufgebaut ist. Wenn nicht, dann rechnen Sie trotzdem mit einem Ausfall.

Lesevorgänge sind in Ordnung, und bei SSDs können die Bits gelesen werden, ohne dass sich dies nachteilig auswirkt.

Schreiben ist eine andere Sache. Das Löschen eines Bits wirkt sich auf die Integrität des Bits aus, und nach vielen sequenziellen Schreibvorgängen akzeptiert das Bit keine neuen Schreibvorgänge mehr. Es kann jedoch noch gelesen werden.

Lassen Sie mich nur sagen, dass die Schreibbeschränkungen für neue Enterprise-Laufwerke enorm sind. Nehmen Sie das neue Samsung 845DC Pro. Es gilt eine Garantie von 5 Jahren für 10 Schreibvorgänge pro Tag. Ich würde mir vorstellen, dass es doppelt so viel bringt. Um das in Zahlen zu fassen, das sind 14.600 TB, die über einen Zeitraum von 5 Jahren mit dem 800-GB-Modell geschrieben wurden.
Oder 2920 TB pro Jahr
oder 8 TB pro Tag für fünf Jahre .

Zeigen Sie mir eine Festplatte mit einer Garantie, die so viel Gebrauch abdeckt. Ich bin mir nicht mal sicher, ob Sie an einem Tag 8 TB auf eine Festplatte schreiben können: - (50 MB / s durchschnittlicher Durchsatz * 60 (Sekunden) * 60 (Minuten) * 24 (Stunden) = 4.320.000 MB / Tag = 4,32 TB / Tag) Es stellt sich heraus, dass Sie nicht können (auf einer durchschnittlichen Fahrt).

Solange Sie ein Laufwerk wie dieses verwenden, das auf V-NAND (oder einem ebenso langlebigen SLC) basiert und nicht auf TLC oder einem schlechten MLC-Flash, sollten Sie in Ordnung sein. Und auf jeden Fall sind RAID 10 und Backups aus einem bestimmten Grund Ihr Freund. Und zumindest wenn das SSD-Schreiblimit zu einem Problem wird, können Sie die in den fehlerhaften Bits gespeicherten Daten trotzdem lesen.

SSDs sind außerdem günstiger zu betreiben, kühler, leiser und Enterprise-Modelle sind besonders widerstandsfähig gegen Stromprobleme. Keine Angst mehr vor einem Head-Crash und natürlich eine enorme Leistungssteigerung für Ihre Datenbankzugriffsanforderungen.

Das Schreiben auf SSDs ist nicht unbedingt schlecht. Es ist das Schreiben und Umschreiben eines einzelnen Blocks, der schlecht ist. Das heißt, wenn Sie eine Datei schreiben, löschen Sie sie und schreiben Sie sie dann erneut oder nehmen Sie kleine Änderungen an einer Datei immer wieder vor. Dies führt zu Verschleiß an den SSDs. Datenbanken würden definitiv in diese Kategorie passen.

Gemäß diesem Artikel wurden jedoch Petabytes an Daten auf SSDs geschrieben und waren weiterhin funktionsfähig. Dies ist wahrscheinlich auf Fortschritte beim Abnutzungsnivellieren zurückzuführen :

Wear Leveling versucht, diese Einschränkungen zu umgehen, indem Daten so angeordnet werden, dass Lösch- und Überschreibvorgänge gleichmäßig über das Medium verteilt werden. Auf diese Weise fällt aufgrund einer hohen Konzentration von Schreibzyklen kein einzelner Löschblock vorzeitig aus.

In Ihrer speziellen Situation würden sich die Datenbanken aus Gründen der Geschwindigkeit auf der SSD befinden, aber täglich gesichert. Sie können auch in Betracht ziehen, zwei SSDs in einem RAID 1- Array zu installieren. Die Wahrscheinlichkeit, dass zwei SSDs gleichzeitig ausfallen, ist gering.

Hinweis: RAID-Arrays sind KEINE Backups !!!! Egal, ob Sie ein RAID-Array verwenden oder nicht, erstellen Sie eine Sicherungskopie. Egal, ob Sie eine SSD verwenden oder nicht, erstellen Sie eine Sicherungskopie.

Angenommen, Ihr Import beinhaltet keine Aktualisierungen und keine Löschvorgänge. Sie machen also alle Einfügungen. Hierbei sollten nur neue Daten in das Transaktionsprotokoll geschrieben werden.

Das heißt, wenn Daten hinzugefügt werden, werden sie immer in einen neuen Sektor geschrieben. Es kann einige Puffer / Swap-Speicher geben, die mehrfach umgeschrieben werden. Wenn Sie dies jedoch ignorieren, führt dies theoretisch dazu, dass pro Sektor nicht mehr als ein Schreibvorgang ausgeführt wird . Abhängig davon, wie MySQL implementiert ist und welche Art von Masseneinfügung Sie ausführen, können Sie später einen zweiten Satz von Schreibvorgängen generieren, wenn das Transaktionsprotokoll in die Hauptdatendatei integriert wird (ich verstehe die verschiedenen DB-Engines nicht) und unter der Annahme, dass MySQL in Bezug auf das Leeren von Transaktionsprotokollen etwas ähnlich ist).

Es ist wichtig, dass Sie die SSD nicht "verwirren". Das heißt, Sie führen nicht viele Änderungen / Verschiebungen / Löschungen / etc. Durch. das würde möglicherweise über die gleichen Sektoren viele Male umschreiben. Sie werden also im Wesentlichen nur eine sehr kleine Anzahl von Schreibvorgängen pro Sektor generieren , und darauf kommt es wirklich an.

Angenommen, Sie füllen die SSD nicht vollständig aus, sollte genügend freier Speicherplatz für die Hotspots (wie Puffer / Swap) vorhanden sein, die aufgewühlt werden, um den Verschleiß durch Abnutzungsausgleichsalgorithmen zu minimieren.

(Indizes können eine andere Sache sein. Da Clustered-Indizes in vielen DBs beim Einfügen von Daten eine Menge Änderungen erfordern. Wenn Sie in einer Data-Warehouse-Umgebung große isnerts ausführen, deaktivieren Sie normalerweise die Indizes während des Massenimports und aktualisieren sie anschließend.)

Dies ist kein Problem.

Erstens haben sich SSDs in den letzten Jahren stark verbessert. Überprovisionierung und Verschleißausgleich (und zu einem geringen Teil der TRIM-Befehl, der in Ihrem Fall jedoch nicht anwendbar ist) haben sie als Hochleistungs-Allzweck-Festplatten geeignet gemacht. Ich verwende auf meinem Entwicklungs-PC (der regelmäßig viel kompiliert) nur SSD, ohne die Anzahl der Löschzyklen zu überschreiten.

Weiter diese Aussage:

SSDs mögen keine massiven fortlaufenden Schreibvorgänge und diese können sie beschädigen

ist völlig falsch. Das Gegenteil ist der Fall. Häufige kleine Schreibvorgänge können SSDs beschädigen.

Im Gegensatz zu herkömmlichen Festplatten sind SSDs (oder besser gesagt der NAND-basierte Flash-Speicher) physisch in großen Blöcken organisiert, die logischerweise mehrere Sektoren enthalten. Eine typische Blockgröße ist 512 KB, während Sektoren (die Einheit, die das Dateisystem verwendet) traditionell 1 KB groß sind (andere Werte sind möglich, vor zwei Jahrzehnten waren 512 KB üblich).
Mit einem 512kB-Block können drei Dinge erledigt werden. Es kann gelesen werden, ein Teil davon oder alles kann programmiert (= geschrieben) werden und das Ganze kann gelöscht werden. Das Löschen ist problematisch, da es nur eine begrenzte Anzahl von Löschzyklen gibt und Sie nur einen vollständigen Block löschen können.

Daher sind große Schreibvorgänge sehr SSD-freundlich, kleine dagegen nicht.

Bei kleinen Schreibvorgängen muss der Controller einen Block einlesen, die Kopie ändern, einen anderen Block löschen und programmieren. Ohne Caching müssten im schlimmsten Fall 512.000 Blöcke gelöscht werden, um 512 Kilobyte zu schreiben. Im bestmöglichen Fall (großes, kontinuierliches Schreiben) müssen Sie genau 1 Löschvorgang ausführen.

Der Import in eine MySQL-Datenbank unterscheidet sich erheblich von vielen separaten Einfügeabfragen. Die Engine kann viele Schreibvorgänge (sowohl Daten als auch Indizes) zusammenfassen und muss nicht zwischen den beiden Einfügungen synchronisiert werden. Dies entspricht einem wesentlich SSD-freundlicheren Schreibmuster.

SSDs mögen es nicht. Wenn Sie die maximale Schreibgeschwindigkeit für 5-10 Jahre (24 Stunden pro Tag, 7 Tage pro Woche) beibehalten, kann es vorkommen, dass die SSD defekt ist.

Ofc. Nach 5 Jahren haben die meisten Server ihr wirtschaftliches Ende erreicht.

Haftungsausschluss:
Versuchen Sie dies nicht mit der allerersten SSD-Generation. Die waren weniger robust.

Wenn Sie wirklich daran interessiert sind, die Details herauszufinden, müssen Sie die folgende Frage beantworten:

Wie viele Bytes befinden sich durchschnittlich in jeder Zeile?

Wenn Sie mir sagen können, dass es 10 Spalten gibt, jede Spalte varchar (100) ist und die Codierung UTF-8 ist, dann kann ich im schlimmsten Fall davon ausgehen, dass Sie Daten im Wert von 4.000 Byte pro Zeile haben und einige weitere Bytes hinzufügen Metadaten also sagen wir 4.200 Bytes?

Ihr Torture SQL berechnet 4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytesdie auf die Festplatte geschriebenen Daten

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 diesem theoretischen Worst-Case-Szenario schreiben Sie 42 TB auf die Festplatte

Laut diesem Artikel , der von @KronoS bereitgestellt wird, sollten Sie für weitere 25 Runden Ihres Torture-SQL gut sein.

Wie auf dem Poster zu diesem Artikel über SSDs stand , ist es wirklich schädlich, immer wieder kleine Datenblöcke zu schreiben.

• Bits werden in {1,2,3} -Bit-Zellen gespeichert. Diese haben eine begrenzte Lebensdauer.
• Zellen sind in [2-16] KB-Seiten gruppiert (kleinste beschreibbare Einheit)
• Seiten sind in (128-256 Seiten-) Blöcke gruppiert (kleinste löschbare Einheit)
• Damit eine Seite neu geschrieben werden kann, muss sie - und ihr gesamter Block - zuerst gelöscht werden

Deshalb wird es empfohlen

• schreibe niemals weniger als eine Seite auf einmal,
• kleine Schreibvorgänge puffern und
• getrennte Lese- und Schreibanforderungen
• "Ein großer Single-Threaded-Schreibvorgang ist besser als viele kleine gleichzeitige Schreibvorgänge"

Eine wirklich große Menge auf einmal scheint also viel besser zu sein.