SSDに大量のMySQLデータをインポートすると、SSDに損傷を与える可能性がありますか？
大量のデータ（1億行、100回まで）をMySQLデータベースにインポートする必要があります。現在、それは私のハードディスクドライブに保存されており、私のインポートのボトルネックはハードディスクドライブの書き込み速度にあるようです。
SSDは大規模な連続書き込みが嫌いで、SSDが損傷する傾向があると聞いています。どう思いますか？これは最近のSSDで本当に問題ですか？
これは簡単な答えではありません。
SSDは、特定のセクターが上書きされる回数と同じくらい、連続書き込みを気にしません。 SSDが最初に登場したとき、オペレーティングシステムは一般的にドライブを従来のHDDのように扱い、障害は非常に頻繁であったため、SQLのようなものは悪い言葉でした。
それ以来、ドライブはより大きく、より安く、より信頼性が高くなり、より多くの読み取り/書き込みが可能になり、オペレーティングシステムはよりスマートになりました。
SQLのSSDは一般的なだけでなく、多くの場合推奨されます。 DBA姉妹サイト を自由に熟読してください。
SQLサーバーが冗長ディスクを使用して適切に構築されていることを前提として、私の考えはそれを行うことです。そうでない場合は、いずれにしても、最終的には障害が発生すると予想してください。
読み取りは問題なく、SSDはビットを読み取ることができますが、悪影響はありません。
書き込みは別の問題です。ビットをクリアするとビットの整合性に影響し、たくさんのシーケンシャル書き込みの後、ビットは新しい書き込みの受け入れを完全に停止します。ただし、まだ読み取ることはできます。
新しいエンタープライズドライブの書き込み制限は非常に大きいとだけ言っておきます。 Samsungの新しい845DC Proをお試しください。保証期間は5年間、1日あたり10回のドライブ書き込みに適しています。その数の2倍になると思います。これを数字で表すと、800 GBモデルで5年間に書かれた14,600 TBです。
または年間2920 TB
または1日あたり8 TB、5年間。
その多くの使用をカバーする保証付きのハードドライブを見せてください。 1日で8 TBをHDDに書き込めるかどうかさえわかりません。-（50 MB /秒の平均スループット* 60（秒）* 60（分）* 24（時間）= 4,320,000 MB /日= 4.32 TB /日）それは（平均的なドライブで）できないことがわかります。
TLCや不良MLCフラッシュに基づくドライブではなく、V-NAND（または同等に耐久性のあるSLC）に基づくこのようなドライブを使用する限り、問題はありません。とにかく、 RAID 1 であり、バックアップは理由があって味方です。そして、少なくともSSDの書き込み制限が問題になる場合でも、障害のあるビットに格納されているデータを読み取ることができます。
SSDは実行コストも安く、温度も低く、静かで、エンタープライズモデルは特に電源の問題に耐性があります。ヘッドクラッシュの心配がなくなり、データベースアクセスのニーズに応じて巨大なパフォーマンスが向上します。
SSDへの書き込みは必ずしも悪いことではありません。悪いのは、単一のブロックの書き込みと再書き込みです。ファイルを書き込んだ場合、そのファイルを削除してから再度書き込むか、ファイルに少量の変更を何度も繰り返し行うことを意味します。これにより、SSDが摩耗します。データベースは間違いなくこのカテゴリーに当てはまります。
ただし、 この記事 によると、ペタバイトのデータがSSDに書き込まれ、引き続き動作可能です。これはおそらく wear leveling の進歩によるものです。
ウェアレベリングでは、消去と書き換えがメディア全体に均等に分散されるようにデータを配置することにより、これらの制限を回避しようとします。このようにして、書き込みサイクルの集中により、単一の消去ブロックが早期に失敗することはありません。
あなたの特定の状況では、速度を上げるためにデータベースをSSDに常駐させますが、毎日バックアップします。 RAID 1 アレイで2つのSSDを取得することも検討してください。 2つのSSDが同時に故障する可能性は低いです。
注：RAIDアレイはバックアップではありません!!!! RAIDアレイを使用するかどうかに関係なく、バックアップを作成してください。 SSDを使用するかどうかに関係なく、バックアップを作成してください。
インポートに更新も削除も含まれていないとしましょう。したがって、すべての挿入を実行しています。これは、トランザクションログに新しいデータを書き込むだけです。
つまり、データが追加されると、常に新しいセクターに書き込まれます。複数回チャーン/書き込みされるいくつかのバッファー/スワップがあるかもしれませんが、無視してくださいこれらの挿入はすべて、理論的にはセクターごとに1回の書き込みにすぎません。 MySQLの実装方法、および実行している一括挿入の種類に応じて、トランザクションログがメインデータファイルに統合されたときに、2番目の書き込みセットを生成する場合があります（さまざまなDBエンジンについて理解します） 、およびMySQLはトランザクションログがフラッシュされる方法が多少似ていると想定しています）。
つまり、SSDを「チャーン」しているわけではありません。つまり、多くの変更、移動、削除などを行っていません。同じセクターを何度も書き換える可能性があります。したがって、基本的には非常に少数のセクターあたりの書き込みを生成するだけであり、それが本当に重要なことです。
SSDを完全に満杯にしていなければ、ウェアレベリングアルゴリズムによって摩耗を最小限に抑えるためにチャーンされているホットスポット（バッファー/スワップなど）のための十分な空き領域が必要です。
（インデックスは別の問題である可能性があります。多くのDBのクラスター化インデックスには、データの挿入に伴う多くの変更が含まれます。通常、データウェアハウス環境で大きなisnertsを実行する場合、一括インポート中にインデックスをオフにして、後で更新します。）
これは問題ありません。
まず第一に、SSDは過去数年間で大幅に改善されました。オーバープロビジョニングとウェアレベリング（および少量の場合、TRIMコマンドは、ケースには適用されません）により、ヘビーデューティな汎用ディスクとして非常に適しています。消去サイクルカウントに近づくことさえせずに、開発用PC（定期的に多くのコンパイルを実行します）でSSD以外を使用していません。
さらに、この声明：
SSDは大規模な連続書き込みを好まないため、SSDを損傷する傾向があります
完全に間違っています。逆の場合は頻繁な少量の書き込みとすると、SSDに損傷を与える可能性があります。
従来のハードディスクとは異なり、SSD（または内部のNANDベースのフラッシュ）は、いくつかのセクターを論理的に含む大きなブロックで物理的に構成されています。典型的なブロックサイズは512kBですが、セクター（ファイルシステムが使用する単位）は伝統的に1kBです（20年前は512Bが一般的でしたが、異なる値が可能です）。
512kBブロックで3つのことを実行できます。読み取り、一部またはすべてのプログラム（=書き込み）、および全体の消去が可能です。消去サイクルの数には制限があり、完全なブロックしか消去できないため、消去は問題を引き起こします。
したがって、大きな書き込みはSSDに非常に適していますが、小さな書き込みはSSDに適していません。
小さな書き込みの場合、コントローラーはブロックを読み取り、コピーを変更し、別のブロックを消去して、プログラムする必要があります。キャッシングがないと、最悪の場合、512キロバイトを書き込むために512.000ブロックを消去する必要があります。最良のケース（大規模な連続書き込み）では、正確に1回の消去を行う必要があります。
MySQLデータベースへのインポートの実行は、多くの個別の挿入クエリの実行とは大きく異なります。エンジンは多くの書き込み（データとインデックスの両方）をまとめて折りたたむことができ、挿入の各ペア間で同期する必要はありません。これは、SSDと相性の良い書き込みパターンに相当します。
SSDはそれを好まない。最大書き込み速度を5〜10年間（1日24時間、週7日）維持した場合、SSDが破損する可能性があります。
Ofc。 5年後、ほとんどのサーバーは経済的な寿命に達しました。
免責事項：
第1世代の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=をディスクに書き込みます。
これによるとarticle、@ KronoSによって提供される約25ラウンドの拷問SQLに適しているはずです。