SSDに大量のMySQLデータをインポートすると破損する可能性がありますか？

大量のデータ（〜1億行、〜100回）をMySQLデータベースにインポートする必要があります。現在、ハードディスクドライブに保存されており、インポートのボトルネックはハードディスクドライブの書き込み速度にあるようです。

SSDは大量の連続書き込みを好まないこと、およびSSDを損傷する傾向があると聞きました。どう思いますか？これは本当に最新のSSDの問題ですか？

これは本当に簡単な答えではありません。

SSDは、特定のセクターが上書きされる回数ほど連続書き込みを気にしません。SSDが最初に登場したとき、オペレーティングシステムは一般的にドライブを従来のHDDのように扱い、障害は非常に頻繁だったため、SQLのようなものは悪い言葉でした。

それ以来、ドライブはより大きく、より安く、より信頼性が高くなり、より多くの読み取り/書き込みが可能になり、オペレーティングシステムはよりスマートになりました。

SQLのSSDは一般的であるだけでなく、しばしば推奨されます。DBA姉妹サイトを自由にご覧ください。

私の考えは、SQLサーバーが冗長ディスクで適切に構築されていると仮定して、それを行うことです。そうでない場合は、とにかく最終的に障害が発生することが予想されます。

読み取りは正常であり、SSDは有害な影響なしにビットを読み取ることができます。

書き込みは別の問題です。ビットをクリアすると、ビットの整合性に影響し、大量の順次書き込みの後、ビットは新しい書き込みの受け入れを完全に停止します。しかし、それはまだ読むことができます。

新しいエンタープライズドライブの書き込み制限は非常に大きいとだけ言っておきましょう。サムスンの新しい845DC Proをお試しください。保証付きで5年間、1日10回のドライブ書き込みに適しています。その数の2倍になると思います。これを数字にまとめると、800 GBモデルで5年間で14,600 TBが書き込まれます。
または、5年間
、1年あたり2920 TB、または1日あたり8 TB 。

そのような使用をカバーする保証付きのハードドライブを見せてください。1日に8 TBをHDDに書き込むことができるかどうかもわかりません：-（50 MB / sの平均スループット* 60（秒）* 60（分）* 24（時間）= 4,320,000 MB /日= 4.32 TB /日）（平均的なドライブでは）できないことがわかります。

TLCや不良なMLCフラッシュに基づくドライブではなく、V-NAND（または同等の耐久性のあるSLC）に基づくこのようなドライブを使用する限り、問題ありません。とにかく、RAID 10とバックアップはあなたの友人です。少なくともSSDの書き込み制限が問題になる場合でも、障害のあるビットに保存されているデータを読み取ることができます。

また、SSDはより安価で実行でき、より涼しく、静かで、エンタープライズモデルは電力の問題に対して特に耐性があります。ヘッドクラッシュの心配はもうありません。もちろん、データベースアクセスのニーズに対するパフォーマンスの大幅な向上です。

SSDへの書き込みが必ずしも悪いわけではありません。悪いのは、単一のブロックの書き込みと書き換えです。ファイルを書き込む場合は、そのファイルを削除してから再度書き込むか、ファイルに何度も少量の変更を加えるという意味です。これにより、SSDが摩耗します。データベースは間違いなくこのカテゴリに該当します。

ただし、この記事によると、ペタバイトのデータがSSDに書き込まれ、引き続き動作可能です。これはおそらく、ウェアレベリングの進歩によるものです。

ウェアレベリングは、消去と再書き込みがメディア全体に均等に分散されるようにデータを配置することにより、これらの制限を回避しようとします。この方法では、書き込みサイクルの集中が原因で、単一の消去ブロックが早期に失敗することはありません。

あなたの特定の状況では、高速化のためにデータベースをSSDに常駐させますが、毎日バックアップします。また、RAID 1アレイで2つのSSDを取得することも検討できます。2つのSSDが同時に故障する可能性は低いです。

注：RAIDアレイはバックアップではありません!!!! RAIDアレイを使用するかどうかに関係なく、バックアップを作成してください。SSDを使用するかどうかに関係なく、バックアップを作成してください。

インポートには更新も削除も含まれないと仮定しましょう。したがって、すべての挿入を行っています。これは、トランザクションログに新しいデータを書き込むだけです。

つまり、データが追加されると、常に新しいセクターに書き込まれます。何度かチャーン/書き込みされるバッファー/スワップが存在する場合がありますが、それを無視すると、これらの挿入はすべて、理論的にはセクターごとに1つしか書き込みできません。MySQLの実装方法と実行する一括挿入の種類に応じて、後でトランザクションログがメインデータファイルに統合されたときに、2番目の書き込みセットを生成する場合があります（さまざまなDBエンジンについては理解していません） 、MySQLのトランザクションログのフラッシュ方法はやや似ていると仮定しています）。

要は、SSDを「かき回す」ことではありません。つまり、多くの変更/移動/削除/などを行っていません。同じセクターを何度も書き換える可能性があります。したがって、本質的にはセクターごとに非常に少数の書き込みのみを生成することになり、それが本当に重要なことです。

SSDが完全にいっぱいになっていないと仮定すると、ウェアレベリングアルゴリズムによって摩耗を最小限に抑えるために撹拌されているホットスポット（バッファー/スワップなど）に十分な空きスペースが必要です。

（インデックスは別の問題かもしれません。多くのDBのクラスター化インデックスは、データの挿入時に多くの変更を伴うため、通常、データウェアハウス環境で大きなisnertを実行する場合、一括インポート中にインデックスをオフにしてから更新します。）

これは問題ではありません。

まず第一に、SSDはここ数年で大きく改善されました。オーバープロビジョニングとウェアレベリング（および、ごく少量ですが、TRIMコマンドは、ケースには適用されませんが）により、ヘビーデューティーの汎用ディスクとして非常に適しています。私は開発用PCでSSD以外は何も使用していません（定期的に多くのコンパイルを実行します）。消去サイクルカウントに近づくことさえありません。

さらに、このステートメント：

SSDは大量の連続書き込みを好まないため、SSDが損傷する傾向がある

まったく間違っています。逆に、頻繁に小さな書き込みを行うと、SSDが損傷する可能性があります。

従来のハードディスクとは異なり、SSD（または内部のNANDベースのフラッシュ）は、論理的にいくつかのセクターを含む大きなブロックに物理的に編成されています。典型的なブロックサイズは512kBですが、セクター（ファイルシステムが使用する単位）は伝統的に1kBです（20年前は512Bが一般的でしたが、異なる値が可能です）。
512kBブロックで3つのことができます。読み取り、その一部、またはすべてをプログラム（=書き込み）でき、全体を消去できます。消去は、消去サイクルの数に制限があり、完全なブロックのみを消去できるため、問題です。

したがって、大きな書き込みはSSDに非常に適していますが、小さな書き込みはそうではありません。

小さな書き込みの場合、コントローラーはブロックを読み取り、コピーを変更し、別のブロックを消去して、プログラムする必要があります。キャッシングなしでは、最悪の場合、512.000ブロックを消去して512キロバイトを書き込む必要があります。可能な限り最良のケース（大規模な連続書き込み）では、正確に1回消去する必要があります。

MySQLデータベースへのインポートを行うことは、多くの個別の挿入クエリを行うこととは大きく異なります。エンジンは大量の書き込み（データとインデックスの両方）をまとめて折りたたむことができ、挿入の各ペア間で同期する必要はありません。これは、はるかにSSDに優しい書き込みパターンに相当します。

SSDはそれを好まない。最大書き込み速度を5〜10年（1日24時間、週7日）維持すると、SSDが破損する可能性があります。

Ofc。5年後、ほとんどのサーバーは経済的な寿命に達しました。

免責事項：
第一世代のSSDでこれを試さないでください。堅牢性が低いもの。

詳細を理解することに本当に興味がある場合は、次の質問に答える必要があります。

各行の平均バイト数は？

10列があり、各列がvarchar（100）であり、エンコーディングがUTF-8であると言うことができる場合、最悪の場合、行ごとに4,000バイトのデータがあり、さらにいくつかのバイトを追加するシナリオを推測できますメタデータなので、4,200バイトと言えますか？

拷問SQL 4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytesは、ディスクに書き込まれたデータを計算します

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

この理論上の最悪のシナリオでは、42 TBをディスクに書き込みます。

@KronoSが提供するこの記事によると、約25ラウンドの拷問SQLに対応できるはずです。

SSDに関するこの記事の投稿者が述べたように、本当に有害なのは小さなデータの塊を何度も書くことです。

• ビットは{1,2,3}ビットセルに格納されます。これらの寿命は限られています。
• セルは[2-16] KBページにグループ化されます（書き込み可能な最小単位）
• ページは（128-256ページ-）ブロック（最小の消去可能単位）にグループ化されます
• ページを書き換えるには、最初にページ全体を消去する必要があります。

それが推奨される理由です

• 一度に1ページ未満を書かないでください。
• 少量の書き込みをバッファする
• 個別の読み取り要求と書き込み要求
• 「大規模なシングルスレッド書き込みは、多くの小さな同時書き込みよりも優れています」

ですから、一度に本当に大量のほうがはるかに良いようです。