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

28

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?

christophetd
quelle
Solange Sie (sagen wir) 2-3 GB außerhalb des partitionierten Bereichs für Über-Provisioning belassen, sind Sie damit sicher. Ich sehe nicht so viele Probleme damit. Die meisten SSDs haben bereits einen Teil der Festplatte, auf den das Betriebssystem keinen Zugriff hat. Dieser Bereich wird zum Ausgleichen von Abnutzung und zum Überprovisionieren verwendet, falls die Festplatte zu voll ist. Diese zusätzlichen GB bieten der SSD mehr Platz für die Verteilung der Daten, um Schäden zu vermeiden. Wenn Sie ein Hardcore-Unternehmen sind und dies fortsetzen möchten, können Sie herausfinden, wie viele Speicherchips Ihre SSD enthält, und 1 GB pro Chip angeben. 10 Chips sind 10 nicht partitionierte GB.
Ismael Miguel
5
Für das Wenige, das es wert ist, importieren wir routinemäßig weitaus mehr Daten. Eine einzelne unserer Tabellen enthält viel mehr Daten als Sie importieren, und wir haben ein paar hundert Tabellen. Wir verwenden SSDs. Ich gehe davon aus, dass es dir gut geht.
ChrisInEdmonton
4
Heutzutage sind SSDs so intelligent, dass sie auch ohne Unterstützung des Betriebssystems mit dem Abnutzungsgrad umgehen können (auch wenn das Betriebssystem fordert, denselben Block neu zu schreiben, schreibt der SSD-Controller jedes Mal transparent in einen anderen Block), ist dies in Ordnung.
7
Ablenkungsmanöver. Die Ausfallrate von SSDs ist kein Grund zur Sorge - sie reicht aus, um länger zu halten als der entsprechende Rost.
Sobrique,
2
Die Leute machen sich viel zu viele Sorgen um ihre SSDs. Grundsätzlich wird es Ihnen nie gelingen, Ihre SSD versehentlich zu "zerstören", und selbst wenn Sie dies absichtlich tun, kann dies Wochen oder Monate dauern. Selbst wenn Sie es "zerstören", werden die Daten weiterhin als schreibgeschützt bereitgestellt. Hör auf dir Sorgen zu machen und benutze es einfach. Sie können sich auch fragen, wie sich der Schreib- / Lesekopf Ihrer Festplatte durch die Beschleunigungen abnutzt.
mic_e

Antworten:

27

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.

Austin T Französisch
quelle
5
"Wenn nicht, dann rechnen Sie trotzdem mit einem Ausfall." Wenn der Server nicht redundante Festplatten verwendet, noch erwarten , dass auf jeden Fall einen Ausfall an einem gewissen Punkt, und plant für sie. Es ist nur so, dass ein Ausfall eines einzelnen Speichergeräts bei vorhandener Redundanz mit wesentlich geringerer Wahrscheinlichkeit zu Systemausfallzeiten führt.
ein CVn
@ MichaelKjörling ja genau. "Richtig gebaut" setzt meines Erachtens auch Backups der Datenbank im Fehlerfall voraus ... Aber manchmal muss auch das gesagt werden, was in Ordnung sein sollte, um ungesagt zu bleiben, danke.
Austin T Französisch
19

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.

Ctrl-alt-dlt
quelle
12
Kann ich fragen warum das downvote?
Ctrl-alt-dlt
Sie können fragen, aber Sie werden anscheinend nicht erhalten.
Fund Monicas Klage
12

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.

James Mertz
quelle
1
RAID1 würde für die Art des Schadens, von dem Sie sprechen, nur sehr wenig bewirken. Das Verschleißniveau ist wahrscheinlich deterministisch, was bedeutet, dass sie sich mit genau der gleichen Rate und Weise abnutzen, wodurch Fehler fast genau an der gleichen Stelle auftreten.
Aron
aus dem verlinkten Artikel: "Die Elektronik in der SSD wird lange vor dem NAND-Verschleiß ausfallen" ... warte, was?
Michael
4

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

AaronLS
quelle
3

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.

Damon
quelle
2
Sektoren sind traditionell 1 KiB? Bitte zitieren. Bei Rotationslaufwerken sind zwei Sektorgrößen üblich: 512 Byte (traditionell, wie bei meinen 4-TB-HDDs, bei IBM-kompatiblen Festplatten etwa aus dem Jahr 1981) und 4096 Byte ("Advanced Format"). Die Größe der Zuordnungseinheiten auf Dateisystemebene kann variieren, dies ist jedoch eine völlig andere Angelegenheit. Es handelt sich lediglich um ein Dateisystemkonstrukt, mit dem die Zuordnung der Datenstrukturen auf eine angemessene Größe in Dateisystemen beschränkt wird, in denen sie nicht dynamisch nach Bedarf erweitert werden ; außerdem bezweifle ich, dass feste 1 KiB-Blockgrößen in der Praxis sehr verbreitet sind.
ein CVn
@ MichaelKjörling: Danke für deinen sehr wertvollen Input. Sie haben die Antwort natürlich gelesen und verstanden, nicht wahr? Die relevante Tatsache ist, dass SSDs physische Blockgrößen haben, die ungeachtet der logischen Sektorgröße (die ich irgendwo zwischen 500 und 4096 Bytes gesehen habe, sogar Größen ohne Zweierpotenz) viel größer sind. Kein Zitat erforderlich.
Damon
1

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.

Hennes
quelle
Mir ist bewusst, dass die Verwendung einer Festplatte mit maximaler Kapazität von 7/24 diese beschädigen würde ... Meine Frage ist, ob sie für eine begrenzte Zeit sicher ist (sagen wir mehrmals 2-3 Stunden)
christophetd
@christophetd - Es kommt darauf an. Aktualisieren Sie Ihre Frage, um die Datenmenge zu schätzen. Es ist mehr über den Prozentsatz des Laufwerks. Das Schreiben von 20 GB pro Stunde auf eine 80-GB-SSD ist am schlechtesten als das Schreiben von 20 GB pro Stunde auf eine 1-TB-SSD.
Ramhound
Zur gleichen Anmerkung: Ein größtenteils leeres Laufwerk bedeutet, dass viele der "leeren" Flash-Zellen für den Verschleißausgleich verwendet werden. (und ein größeres Laufwerk mit der gleichen Datenmenge ist in% der Zeit leerer).
Hennes
1

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.

MonkeyZeus
quelle
-2

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.

serv-inc
quelle
2
Diese Antwort liefert eigentlich keine relevanten Informationen, die nicht gesagt wurden. Außerdem handelt es sich im Grunde genommen um einen Kommentar mit einem darin enthaltenen Link.
Ramhound
@Ramhound: würdest du dein ok für deinen kommentar geben (danke übrigens) und das auch, um als obsolet markiert zu werden? Oder hältst du die Info noch für gesagt / irrelevant?
Serv-Inc
Es ist zwar kein Link mehr, aber die technischen Informationen selbst
treffen
@Ramhound: Mir schien es um den Import zu gehen, nicht um das Laufen. Den Abstimmungen nach zu urteilen, scheint es, als ob Sie Recht haben
serv-inc