SSDの出現は、データベースの最適化に影響を与えますか?


26

今日、SQL Serverの最適化に関する本を閲覧していましたが、一定量のアイデアがストレージの線形モデルに基づいているように思われました。SSDのストレージモデルはまったく異なるため、データベースの調整や最適化についての考え方に関して、何らかの形でゲームを変えますか?


SSDので、...あなたは増加生のパフォーマンスよりも摩耗を最小限に抑えるために、より最適化する必要があるようだ
Trezoid

興味深い考えといくつかのクールな回答、+ 1
ドリュー

回答:


9

はい、彼らはゲームを変更します。回転する磁気ディスクの特性(シーク時間回転遅延など)に基づく最適化は、SSDドライブには関係ない場合があります。FITME 2010で公開された最近の論文*は、SSDの特性に基づいた新しいクエリ最適化アルゴリズムを紹介しています。

ただし、これらの変更は、おそらくデータベース開発者が効果的に実装できる低レベルの変更(たとえば、ストレージおよび検索アルゴリズムに対する)になります。おそらく、データベースユーザーにはそれほど影響しません。

* IEEE Xplore-フラッシュベースのデータベースの列指向のストレージクエリ最適化


3
はい-しかし、すべてをRAMに入れるだけで、ほとんどのデータベース最適化はすでになくなりました。64GBのRAMは、すでに変更され、SQLの専門家よりも安くものではなく、必ずそれに追加されますどのくらいのSSDなったら
マーティンベケット

3
@マーティンは同意した。一方、最近は垂直(巨大な$ 500,000 DBボックス)のスケーリングではなく、水平(クラウドなど)に向かって決定的な転換がありました。分散システムは、この種のローカル線形最適化からグローバルな非線形パフォーマンスの改善を得ることができます。多くの場合、これはより優れたコストモデルにもなります。
ラインヘンリヒス

8

性能

SSDはパフォーマンスが高く、シークする必要がなく、スループットが非常に優れています。ディスクを扱うほとんどのソフトウェアは、それらが最適化されている限り、同期シークの数を減らすために最適化されています。そうすることで、彼らは複雑さのホストを紹介します。永続的ストレージへの高速でシークレスな書き込みの出現により、新しいデータストレージシステムはそのような複雑さを必要としなくなりました。

耐久性

現在、SSDの故障率は高くなっています。SSDは失敗します。SSDは、磁気ディスクよりもはるかに高い割合で故障します。レプリケーション、バックアップなどでこれを回避する必要があります。これにより、独自の複雑なセットが導入されます。


1
あの、何?SSDの故障率は高いですか?SSDの年間故障率は、HDDに比べて大幅に低くなっています。これまでのところ、特により高度なコントローラー(たとえば、LSIのSandForce)を使用して、SSDで利用可能な書き込みを使い果たすことができた人はほとんどいません。
ミルチアチレア

5

ストレージの価格の全体的な削減は、はるかに大きな影響を及ぼします。

SQLを導入する前は、DBAがデータのトラックとシリンダーの配置を慎重に計画する必要がある、最適化された階層データベースとネットワークデータベースがありました。

SQLデータベースの効率ははるかに低くなります。しかし、ディスクは安価で、巨大で、高速であるため、ほとんど気にしません。

NoSQL( "ドキュメント")データベースは、SQL論理スキーマと、ファイルまたはテーブルスペースなどの基礎となる物理スキーマとの間に論理-物理マッピングの同じ機能がないため、SQLよりも効率がやや劣ります。そして、私たちはほとんど気にしません。

SSDのパフォーマンスの向上は、NoSQLデータベースを使用してシステム全体を設計する方法に起因する変更では失われる可能性があります。


2

SSDの最適化に関する主な問題は、データの書き込み方法に関係しています。従来のハードドライブは通常、約512バイトの小さなセクターにデータを保存し、実際にそのレベル以下でセクターを直接操作できます。

SSDには書き込みに関していくつかの欠点があります。

  • 最小ブロック書き込みサイズは約4〜8 KBです。
  • 書き込みは、通常256KBのフルページ単位でのみ実行できます。
  • 空のブロックのみに書き込むことができます。

書き込み増幅と呼ばれる典型的な悪夢のシナリオは、すでにいくつかのブロックが使用されているディスク上の場所に1バイトを書き込む場合です。そこに書き込むには、まず256KBページ全体をメモリにコピーし、ブロック全体を消去し、ページ内の1バイトを変更してから、変更された256KBページ全体を書き戻す必要があります。したがって、1バイトを書き込むために、約半メガバイトの「トラフィック」がありました。

SSD、コントローラー、さらにはオペレーティングシステムレベルで実装されるこの問題には多くの最適化がありますが、特定の動作に合わせてこれらの最適化を調整することにより、DBMSが恩恵を受けることは間違いありません。

ただし、これは、DBMSレベルでの設計/実装の決定に大きく依存するため、データベースユーザー(アプリケーションでデータベースを使用する場合など)が考慮する必要のあるものではありません。


2

ServerFaultブログから収集したものから、データベースサーバーには強力なハードウェアが必要です。スタック交換サイトのデータベースサーバーではSSDが実行されており(http://blog.serverfault.com/post/our-storage-decision/を参照)、クエリの最適化が依然として非常に必要であると思います。CPUとメモリ、データベースクエリとIOの影響を受けます。

ただし、データベースのパフォーマンスはIOに大きく依存するため、SSDが確実に役立ちます。


1

はい、誰もが述べた理由から。

Oracle、SQL ServerなどのRDBMSの大きなチャンクが適切に分離できる場合は「オプション」になり始めるというポッドキャストを聞いていました。SSDドライブかどうかを検出し、それに応じて最適化します。

キャッシングとデータの書き込みに組み込まれた余分なコードがたくさんありますが、これはもう必要ありません。

さらに興味深いのは、RAMSANとそのバリアントです。基本的に、内蔵のX時間UPSを備えたRAMチップで構成されたハードディスクドライブと、長期のHDDストレージへのバックグラウンド書き込み機能。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.