SQLのパフォーマンスを向上させるために、高速なハードディスクを搭載するのではなく、単に大量のRAMを搭載してみませんか

人々は、SQLサーバーのパフォーマンスを向上させるために、RAID 5などで可能な限り高速なハードディスクを購入すると言っています。

だから私は、RAID 5と超大型の高速ハードディスク（ちなみに安くはない）にすべてのお金を使う代わりに、なぜ大量のRAMを手に入れないのかと考えていました。SQLサーバーがデータベースをメモリにロードすることがわかっています。メモリは、どのハードディスクよりも高速です。

サーバーに100 GBのRAMを詰めてみませんか？次に、RAID 1を備えた通常のSCSIハードディスクを使用します。これは、はるかに安くて高速ではありませんか？

あなたの分析は、それが絶対に物事を速くするという点で素晴らしいです-ポイントに- ただし、まだいくつかの他の問題を考慮する必要があります。

1. 誰もが十分なメモリを購入できるわけではありません。複数テラバイトのデータがある場合は、しばらくディスク上に置く必要があります。データがあまりない場合は、何でも十分に高速です。

2. データベースの書き込みパフォーマンスはディスクによって制限されるため、データが実際に保存されたという約束を守ることができます。

小さいデータセットがある場合、またはディスク上に保持する必要がない場合は、アイデアに問題はありません。VoltDBのようなツールは、RDBMS実装の古い仮定がメモリ内の純粋なパフォーマンスを制約するオーバーヘッドを削減するために機能しています。

（余談ですが、データベースのパフォーマンスにRAID-5を使用するように言っている人は、ほとんどの場合最良の選択ではないので、おそらくこのテーマを聞くのに適した人ではありません。ほとんど常に読み取りのパフォーマンスの問題を解決するためにキャッシュにRAMを投入できるためです。

ショートバージョン：ワーキングセットのサイズを考慮してください。ロングバージョン：データの大きさは？最新のサーバーのメモリに収まる場合、はい、あなたは絶対に正しいです。残念なことに、最大のXeonは現在2TBのRAMに対応できますが、それはもはやデータセットの大きなものではありません。ワーキングセット全体をRAMに収めるのに十分な大きさのマシンを購入できない場合、ウォレットではなく脳の問題を解決せざるを得ません。

速度が必要な場合：

• 少なくとも頻繁に使用されるインデックスがRAMに完全に収まるようにRAMを増やします（たとえば、作業中のシステムでは、350GBデータベースには32GB RAMで十分です。インデックスは生データではなく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での作業を中心に設計する必要があります。

近年、多くの小規模でより特殊な言語が広く採用されているように、より特殊なデータベースが必要とされる時代に突入しています。

このトピックの詳細を読むには、学術論文The End of a Architectural Era（It's Time for a Complete Rewrite）をお勧めします。読むのは難しくありません。

この質問がSQL Serverに関するものであるかどうかは不明です。元のポスターはこれを明確にする必要があります。

ダニエル・ピットマンはこう書いている：

小さいデータセットがある場合、またはディスク上に永続化する必要がない場合は、考えに問題はありません。VoltDBのようなツールは、RDBMSの実装における古い仮定が純粋なメモリ内パフォーマンスを制限するオーバーヘッドを減らすために機能しています。

RDBMS実装の古い仮定からオーバーヘッドを削減することはVoltDBの設計目標でしたが、データサイズのアーキテクチャ上の制限なしに水平にスケーリングし、スナップショットとコマンドロギングを使用して完全な耐久性のためにディスクに永続化できます。

少なくともデータセットのホット部分を保持するのに十分なRAMを備えたサーバーを取得できれば、問題ありません。また、RAID 1と5はデータを整理する最速の方法ではありません-RAID 0はより高速ですが、データベースを一掃するファイルシステム障害の可能性が高いことを考慮する必要があります-起こるのは良いことではありません。十分なドライブとコントローラーがあれば、RAID 0アレイを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アレイを経験しましたが、2009年までに4つの146G SASディスクでDL360 G5のベンチマークを行った後、テストを再確認する必要がありました。実際、ほぼすべてのテストで、アレイはRAID10よりもRAID5の方が高速でした。BBWCと高速パリティ計算により、サーバーはRAID10よりもRAID5アレイとして4つのディスクをより効果的に使用できます。一部のテストでは、RAID5でスループットが50％向上しましたが、速度が低下したテストはほとんどありませんでした。遅いテストは5〜10％オフでした。

RAID5は遅い、と誰もがオンラインで言っているが、すべての場合に当てはまるとは言えないという声明を出す人々に警告します。

あなたが選択するキャンディのミックスバッグを持っています、そして本当にあなたが望む味が何であるかに依存します。

1. DBには、クエリをキャッシュする構成と、このキャッシュが存在する場所（メモリまたはハードドライブ）があります。
2. RAID 5は常に最速とは限りませんが、RAID 0（JBOD）はストライプで高速です。RAID5もストライプであるため、考え方はほぼ同じです。
3. RAID 1は速度を向上させるものではなく、単なるミラーです。
4. SQLのパフォーマンスはインデックス作成に基づいており、最初に確認するものです。リレーショナルデータベースでは非常に重要です。
5. すべてのインデックスを作成しないでください。インデックス作成が過剰になると、インデックス作成の速度が低下する可能性があります。
6. SQL結合を使用すると、データベースが遅くなることがあります。プログラミングを使用して最小限のインデックス結果のセットをループすると、速度が向上します。
7. 仮想サーバーは、お金を払わなければ速度の悪夢です。

現金をフォークする前に、知識に投資するだけです（無料）。1.データベースの構成を学習し、現在の構成を確認して最適化します。2.プログラミングおよびsqlステートメント、関連する操作を模倣する簡単なスクリプトを使用した単体テストを見てください。問題だと思われることすらありません。単純なスクリプトがSQL結合を使用して時間がかかる場合、それを分割し、同じことを行うためにプログラムされたループで同じことを行います。これはメモリが助けになりました。3.ホスティングプランとサーバーを見てください。Linuxコンソールでps auxを使用して、メモリとプロセッサを消費しているものがあるかどうかを確認します。

Absolutes Hard Driveは速度を向上させますが、仮想サーバーの領域ではユーザー次第ではありません。メモリは、サービスの期間を設定しない限り、速度を改善しません。ストライプ化されたRAID（0,5）、RPM、および高速バスを使用した同期読み取り/書き込みが役立ちます。優れたl1、l2、l3キャッシュを備えたコアプロセッサは、ボトルネックの処理に役立ちます。Xeonで聞くことができます！

全体として、サイズとスケーラビリティを念頭に置く必要があります。少量のストレージニーズから始めるように見えるかもしれませんが、データは非常に迅速かつ指数関数的に成長します。DBは、可能な限り小さいサイズに分割されたデータであるアトミックデータを使用するのが最適です。サイズが小さいため、データウェアハウス内をより速く移動します。次に、DB構造も考慮します。将来的には、外部のDBにリンクする可能性があります。そのため、構造も重要です。このシナリオでは、データの半分がデータマートの外部にある場合、クエリにはほとんど違いがありません。データを照会する場合、保存されたデータをRAMに保持しないことがポイントです。むしろ、クエリはデータへのアクセスとデータの返送において迅速でなければなりません。

• データにRAID 5を常に使用するとは限りません。これは、バックアップについて以前に言及したことの他に、データとその重要性に依存します。RAID 1を使用できます。
• クエリの範囲内のすべてのサーバーをアップグレードして、速度を改善する必要があります。データの多くは制御できないため、データマート外のどこかでボトルネックになります。（自分でアップグレードする場合）