データベース用にSSDを入手したいという人の話をよく耳にします。しかし、テーブルをSSDに置く代わりに、通常のハードドライブにテーブルを置いたままDBログをSSDに置きたいと思うことがよくあります。
しかし、なぜ誰かがそれをしたいのですか?
ログは順次書き込みを使用します。また、SSDのシーケンシャルIO速度は、通常のディスクよりも速くはありません。したがって、SSDにログを記録しても、パフォーマンスは向上しません。
SSDが通常のディスクよりもはるかに高速である1つの領域は、ランダムIOです。したがって、ログを通常のディスクに残したまま、テーブルをSSDに置くのが賢明なことではないでしょうか。
私は何かが足りないのですか?
ええ、データベース全体と比較した場合、トランザクションログは通常*一定ですが非常に低いスループットです。ただし、スループットは絶対的に最優先事項であり、遅延すると、データベースへのすべての更新を待機する必要があります。ログをミラーまたはRAID5に書き込むことは経済的に有益ですが、書き込みをシーケンシャルに保つことができる場合に限ります。データファイル、インデックス、ポルノ映画のコレクションなど、他のものとディスクを共有すると、パフォーマンスが危険にさらされます。
大規模な環境では、通常、同じストレージに集中化された複数データベースインスタンスがあります。もちろん、ログを同じドライブのセットにまとめるのは望ましくありません。複数の順次書き込みを組み合わせると、実際には1つの大きなランダムのような書き込みになるためです。
1つのオプションは、各ログシーケンスに個別のミラー(2つのディスク)を専用にすることです。ただし、別のオプション(場合によっては経済的に実行可能)は、物事をシンプルに保ち、すべてのログファイルに単一のSSDを使用することです。これにより、デバイスとデータパスが分離され、ランダムなパフォーマンスが向上します。実際、複数のログのいずれもデータベースを遅らせることはありません。私はそのようなセットアップを見たことがありますが、それはお勧めしません(SSDの不揮発性は私には脆弱すぎる概念です)。
[*]-一部のエンジンは、やり直しログと元に戻す情報を組み合わせて複雑にします(例:MS SQL Server)
常にログを不揮発性ストレージ(プラッターまたはフラッシュ)にフラッシュする必要があります。DRAMベースのSSDは、ハードディスクよりも高速に書き込むことができます。
トランザクションログは、パフォーマンスのためにほとんどの場合メモリにキャッシュする必要があるため、読み取り速度は実際には入りません。
したがって、トランザクションログをSSDに配置することで、より高い書き込みスループットを得ることができるはずです。
余談ですが、MySQL innodbトランザクションログをtmpfsに配置することを試みたことがあり、ディスクと比較してパフォーマンスが10〜20%向上しました。