SQLのパフォーマンスを向上させるには、より高速なハードディスクではなく、RAM
SQLサーバーのパフォーマンスを向上させるには、RAID 5などで可能な限り高速なハードディスクを購入するようにと言われます。
それで、RAID 5と超高容量の高速ハードディスク（ちなみに安くはありません）にすべてのお金を費やす代わりに、大量のRAMを手に入れるのではないかと考えていました。 SQLサーバーがデータベースをメモリにロードすることはわかっています。メモリは、どのハードディスクよりもはるかに高速です。
RAM===========サーバーに100 GBの容量を用意しない場合は、RAID 1を搭載した通常のSCSIハードディスクを使用してください。それほど安くて高速ではないでしょうか？
あなたの分析は結構です-ある程度まで-それは物事を絶対的に速くするでしょう。ただし、他のいくつかの問題を考慮する必要があります。
誰もが十分なメモリを購入できるわけではありません。数テラバイトのデータがある場合、しばらくしてディスクに置く必要があります。データが少ない場合は、どれでも十分高速です。
データベースの書き込みパフォーマンスはディスクによって引き続き制約されるため、データが実際に格納されたという約束を守ることができます。
データセットが小さい場合、またはディスク上に永続化する必要がない場合は、アイデアに問題はありません。 VoltDB のようなツールは、RDBMS実装での古い仮定が純粋なメモリ内パフォーマンスを制約するオーバーヘッドを減らすために機能しています。
（余談ですが、データベースのパフォーマンスにRAID-5を使用するように指示している人は、ほとんどの場合最良の選択ではないため、この件について聞くのは素晴らしい人ではありません-読み取りパフォーマンスは良いが、書き込みパフォーマンスが悪く、書き込みも多いRAMをキャッシングに投入して、ほとんどの読み取り側のパフォーマンス問題を解決できるため）
ショートバージョン：ワーキングセットのサイズを考慮してください。長いバージョン：データのサイズはどれくらいですか？最新のサーバーのメモリに収まる場合は、そうです。残念ながら、最大のXeonは2TBのRAM=を現時点で扱うことができ、それはもはやデータセットの大きさではありません。ワーキングセット全体をRAMに格納するのに十分な大きさのマシンを購入できない場合、あなたは財布ではなく、脳の問題を解決することを余儀なくされています。
速度が必要な場合：
- RAMを増やすので、少なくとも頻繁に使用されるインデックスはRAMに完全に適合することができます（たとえば、私が作業しているシステムでは、32GB RAM 350GBデータベースには十分です。インデックスは生データではなくRAMに必要なものだからです）
- 任意のディスクでRAID10を使用します（ディスクが高速であるほど優れています）。
- 回避 RAID5
- Mdf、ldf、およびtemp DBを個別のスピンドルセットに分割します（例：独自のRAID1セット上のtempdb、独自のRAID1またはRAID10スピンドルセット上のldf、合計4つ以上のディスクを持つRAID 10セット上のmdf）
これらの手順に従うと、SQL Serverが動作します。
次に、必要に応じてRAMを追加します...しかし、最初に上記を実行すれば、完了したことがわかるでしょう。
RAMは新しいディスク、ディスクは新しいテープです。
http://www.tbray.org/ongoing/When/200x/2006/05/24/On-Grids で。 6年前のことです。はい、私たちはデータベースシステムを使用しています。これは、データセット全体をRAMに保持し、ディスクを使用するよりも複数のマシンにシャーディングする）です。データセットをディスクに書き込みますが、上記のモットーのように、オンライン操作よりもバックグラウンドバックアップタスクに似ています。耐久性は、これらのデータベースのログのみを追加することで実現されます（MongoDBとRedisだと思いますが、もっとたくさんあります）。
この質問は、過去5〜10年にわたってデータベースアーキテクチャの多くの研究開発につながった基本的な質問に似ています。データベース全体をRAM=に保存することが可能になったため、多くのユースケースで、データベースはRAMでの作業を中心に設計する必要があります。RAMベースのストレージに古い継承アーキテクチャを適用するだけではありません。
近年、多くのより小型でより特殊な目的の言語が広く採用されているように、私たちはより特殊な目的のデータベースが必要になる時代を迎えています。
このトピックの詳細については、学術論文 建築の時代の終わり（完全な書き直しの時間） をお勧めします。それは難しい読みではありません。
この質問が特にSQL Serverに関するものかどうかは不明です。元のポスターでこれを明確にする必要があります。
ダニエル・ピットマンはこう書いている：
データセットが小さい場合、またはディスク上に永続化する必要がない場合は、あなたの考えに問題はありません。 VoltDBのようなツールは、RDBMS実装での以前の仮定によって生じた、純粋なメモリ内パフォーマンスを制約するオーバーヘッドを削減するように機能しています。
RDBMS実装での古い仮定からのオーバーヘッドの削減は、まさに VoltDB の設計目標でしたが、データサイズのアーキテクチャ上の制限なしに水平方向にスケーリングし、スナップショットを使用して完全な耐久性のためにディスクに永続化できます。コマンドロギング。
十分なRAMを備えたサーバーを入手できれば、少なくとも、データセットのホットな部分を保持できれば問題ありません。また、RAID 1と5は、最速の方法ではありません。データ-RAID 0の方が高速ですが、データベースを一掃するファイルシステム障害の確率が高いことを考慮する必要があります。これは、起こりがちなことではありません。RAID0アレイをRAID 1またはRAID 5にすることができます。十分なドライブとコントローラーがある場合。
ここでレプリケーションを試すこともできます。ディスクを多用するサーバーに書き込みを行い、複雑なクエリを実行する1つ以上のメモリを多用するサーバーに複製します。
悲しいことに、RDBMSはビッグアイアンの領域にあるように見えます。水平方向に拡張するのはそれほど簡単ではありません。
これは「あなたが何をしているかによります」の場合です。おそらく「正しい」アドバイスは、SQLを完全に回避してmemcache/redis/etcを使用することです。
余分なRAM=は、特にワーキングセット全体をRAMに読み取ることができる場合に非常に役立ちます。はい、それでもデータを書き込む必要がありますが、ほとんどの場合、その後、書き込みはディスクI/Oの競合を起こしません。
ただし、多くの場合、ディスクパフォーマンスはSQLサーバーのボトルネックであり、RAMのように後でアップグレードすることが困難です（サーバーにDIMMが完全に搭載されていない場合）。
RAID5が遅いとのコメントがたくさんありましたが、常にそうであるとは限らないので、抜本的な発言をする前に注意してください。高速のRAIDカードと多くのBBWCを備えた本当にハイエンドのサーバーは、RAID5（または4つ以上のディスクを搭載したRAID50）でRAID10よりもはるかに高速になる場合があります...
長年にわたって私は個人的に低速のRAID5アレイを経験しましたが、4台の146GでDL360 G5をベンチマークした後、SASディスクをテストした後、テストを再確認する必要がありました。実際、アレイはより高速になりましたほとんどすべてのテストでRAID10よりもRAID5を使用しました。BBWCと高速パリティ計算により、サーバーは4つのディスクをRAID10アレイよりもRAID5アレイとしてはるかに効果的に使用できました。一部のテストでは、RAID5でスループットが50％向上し、ほとんどが低速でした。遅いテストは5〜10％しかオフになりませんでした。
RAID5は遅いと全面的に言っている人には注意するべきだ、と誰もがオンラインで言うが、それは単にすべての場合に当てはまるわけではない。