SSDの登場は、データベースの最適化に何か影響がありますか？
今日、SQL Serverの最適化に関する本を閲覧していたところ、アイデアの一部はストレージの線形モデルに基づいているようでした。 SSDは完全に異なるストレージモデルを持っているので、データベースのチューニングまたは最適化についての考え方に関して、SSDは何らかの形でゲームを変えますか？
パフォーマンス
SSDは高性能です。SSDはシークする必要がなく、スループットは非常に優れています。ディスクを処理するほとんどのソフトウェアは、ディスクが最適化されている限り、同期シークの数を減らすように最適化されています。そうすることで、彼らは多くの複雑さを導入します。永続的ストレージへの高速でシークレスな書き込みの出現により、新しいデータストレージシステムでは、このような複雑さは必要なくなりました。
耐久性
SSDは現在高い故障率を持っています。 SSDは故障します。 SSDは、磁気ディスクよりもはるかに高い速度で故障します。レプリケーション、バックアップなどでこれに対処する必要があります。これにより、独自の複雑なセットが導入されます。
ストレージの価格の全体的な削減には、はるかに大きな影響があります。
SQLを導入する前は、DBAがデータのトラックとシリンダーの配置を慎重に計画しなければならない、超最適化された階層データベースとネットワークデータベースがありました。
SQLデータベースは効率がはるかに低くなります。しかし、今ではディスクは安価で巨大で高速なので、ほとんど気にしません。
NoSQL（「ドキュメント」）データベースは、SQL論理スキーマと、ファイルまたはテーブルスペースなどの基礎となる物理スキーマとの間に論理から物理へのマッピングの同じ機能がないため、SQLよりも効率が多少低くなる可能性があります。そして、ほとんど気にしません。
SSDのパフォーマンスの向上は、NoSQLデータベースの使用によって引き起こされた、システム全体の設計方法の変更によって失われる可能性があります。
SSD向けに何かを最適化する際の主な問題は、SSDがデータを書き込む方法に関係しています。従来のハードドライブは通常、約512バイトの小さなセクターにデータを格納し、実際にはそのレベル以下のセクターを直接操作できます。
SSDには、書き込みに関していくつかの欠点があります。
- 約4〜8KBの最小ブロック書き込みサイズ。
- 書き込みは、通常256KBのページ全体でのみ実行できます。
- 空のブロックのみに書き込むことができます。
書き込み増幅 と呼ばれる典型的な悪夢のシナリオは、いくつかのブロックがすでに使用されているディスク上の場所に1バイトを書き込む場合です。そこに書き込むには、最初に256KBページ全体をメモリにコピーし、ブロック全体を消去し、ページの1バイトを変更してから、変更された256KBページ全体を書き戻す必要があります。したがって、1バイトを書き込むために、約半分のメガバイトの「トラフィック」がありました。
SSD、コントローラ、さらにはオペレーティングシステムレベルで実装されたこの問題には多くの最適化がありますが、DBMSはこれらの最適化を特定の動作に合わせて調整することで間違いなく恩恵を受けることができます。
ただし、DBMSレベルでの設計/実装の決定に大きく依存するため、これはデータベースユーザー（アプリケーションでデータベースを使用する場合など）が考慮する必要のあるものではありません。
ServerFault ブログから収集したものから、データベースサーバーにはハードウェアが必要です。スタック交換サイトのデータベースサーバーはSSDを実行しており（ http://blog.serverfault.com/post/our-storage-decision/ を参照）、クエリの最適化はまだ非常に多いと思います必要。 CPUとメモリは、データベースクエリとIOの影響を受けます。
ただし、データベースのパフォーマンスはIOに大きく依存するため、SSDが確実に役立ちます。
はい、誰もが述べた理由で。
私は、Oracle、SQL ServerなどのRDBMSの大きなチャンクが分離を適切に処理できる場合に「オプション」から除外されると言っているポッドキャストを聞いていました。 SSDドライブかどうかを検出し、それに応じて最適化します。
データのキャッシングと書き込みに組み込まれている余分なコードがたくさんありますが、それらはもはやもはや必要ありません。
さらに興味深いのは、RAMSANとそのバリアントです。基本的に、内蔵のX時間UPSを備えたRAMチップで構成されたハードディスクドライブと、長期的なHDDストレージへのバックグラウンド書き込み機能。