web-dev-qa-db-ja.com

データウェアハウスサーバー。 RAM / CPU仕様をどのように計算しますか？

計画中のデータウェアハウスアップグレード用のデータウェアハウスサーバーの仕様を記述しようとしています。

VMWareホストで仮想サーバーを実行すると、必要に応じてリソースを追加または削除できます。過去には、RAMと必要に応じてCPUを追加しました。需要が高まるにつれ、より多くのリソース（主にディスクとRAM）にロビー活動を行いました。

もっとお願いします。彼らは私たちにできるだけ少ないを与えます。

しかし、最近リソースについて話すときはいつでも、そもそもマシンを正しく指定していないと非難されており、開発ホストが使い果たされていると言われてきました。RAM =利用可能。

私たちは小さな地方自治体の組織であり、DWの常用ユーザーが最大50人います。通常の日常使用では問題なく動作します。 mdxクエリのパフォーマンスは良好で、レポートとダッシュボードは高速です。ユーザーは満足しています。

ただし、ETLプロセスは夜通し実行されるため、データマートを同時に処理すると、メモリ不足の兆候が見え始めています。昨夜、SSISは「メモリ不足エラー」に関する警告で失敗しました。

私たちの既存のDWサーバーは、4つのCPUと16GbのWin = 2008 R2であり、RAM SQL 2012 Stdを実行しています。max server memory12GBに設定し、OSおよびサービスなどに4GBを残します。既存のDWには3つのデータマート/ OLAPキューブがあり、さらに2つを開発しています。

+----------+----------+---------------+-----------+---------------+
| Datamart | Files GB |  Fact (Rows)  | Fact (Mb) | ETL & Process |
| OLAP cube|          |               |           | Time (hours)  |
+----------+----------+---------------+-----------+---------------+
| PBI      |       3  |  190,000      |  180      |  0.2          |
| FBI      |      30  |  26,100,000   |  10,000   |  1.5          |
| RBI      |     175  |  62,000,000   |  32,000   |  8.3          |
| ABI*     |     100  |  44,050,000   |  21,000   |  4.0          |
| EBI*     |      11  |  100,000,000  |  6,000    |  2.0          |
+----------+----------+---------------+-----------+---------------+
* Planned/Estimated

新しいサーバーは、SQL 2016 Enterpriseを実行するWin 2012になる予定です。 SQL、SSIS、SSRS、SSASを実行します。ストレージは問題ではありませんが、RAM＆CPUについてはわかりません。

SQL Server 2012のファストトラックデータウェアハウスリファレンスガイド によると、2ソケットマシンで必要な最小値は128Gbです...これは少し過剰に見えます。 SQL Server 2016をインストールするためのハードウェアおよびソフトウェアの要件 は、4GB以上のRAM SQL 2016の場合）をお勧めします。これはかなりの違いです！

だから、良い出発点は何ですか？ 32Gb？ 64Gb？開始位置（仕様）をITに正当化するにはどうすればよいですか？

サーバーリソースの計算方法に関する優れたガイドはありますか？

良い経験則はありますか？

DWコンテキストでのRAMサイジングの主要な成分/メトリックは何ですか？

  • データ量？
  • キューブの数は？
  • ETLまたはキューブの処理にかかる時間は？
  • ピーク時の処理負荷は夜間ですか、それともエンドユーザーが日中見たときのパフォーマンスですか？
sql-serverdata-warehousewindows-serversql-server-2016
8
Sir Swears-a-lot

すばらしい質問です。数年前にTechEdでこれに関するセッションを行いました。Buildingthe Fastest SQL Servers：

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DBI328

その中で、データウェアハウスの場合、SQL Serverがデータを消費するのに十分な速さでデータを提供できるストレージが必要であることを説明します。 Microsoftは、ハードウェアの詳細に入るFast Track Data Warehouseリファレンスアーキテクチャと呼ばれる一連の優れたホワイトペーパーを作成しましたが、基本的な考え方は、ストレージでは、CPUコアごとに200〜300 MB /秒のシーケンシャル読み取りパフォーマンスを提供できる必要があるということです。 CPUをビジー状態に保つため。

メモリにキャッシュできるデータが多いほど、処理速度が遅くなります。しかし、処理しているファクトテーブルをキャッシュするために必要なメモリよりも少ないメモリを使用しているため、ストレージ速度が非常に重要になります。

次のステップは次のとおりです。

  • そのビデオを見る
  • CrystalDiskMark を使用してストレージをテストします（ 方法はこちら ）
  • 4コアでは、least800MB /秒の順次読み取りスループットが必要です
  • それがない場合は、問題がなくなるまでメモリを追加することを検討してください（データベース全体をRAMにキャッシュすることは考えられないことではありません）。

処理している200GBのデータベースがあり、コアをビジー状態に保つのに十分なストレージスループットが得られないとします。 200 GBのRAMだけでなく、それ以上のRAMが必要になることも考えられないわけではありません。結局のところ、SSISとSSASは実際にメモリ内で作業を行いたいので、エンジンのデータとSSISとSSASの作業スペースを用意する必要があります。

これが、人々がSSISとSSASを別々のVMに分離しようとする理由でもあります-それらはすべて同時にメモリを必要とします。

9
Brent Ozar

SQL Server 2012のファストトラックデータウェアハウスリファレンスガイド は、時間の観点だけでなく、特にSQL Server 2016に移行する場合（本当に？電話してください）、実際には少し古くなっていますだけでなく、機能も備えています。

SQL Server 2012では、ファストトラックのベースとなっているバージョンでは、非クラスター化列ストアインデックスしか使用できませんでした。これらはメインテーブルとは別の構造であるため、データの圧縮コピーにもかかわらず、追加のストレージと処理のオーバーヘッドが発生します。

SQL Server 2014以降では、列ストアインデックスをクラスター化できます。これらは、集約/要約クエリの大規模な圧縮と潜在的なパフォーマンスの向上を提供します。これらはファクトテーブルに完全に適しているため、32 GBのファクトテーブルは8〜12 GBのようになります。 YMMV。少し風景が変わりますね。あなたのテーブル（そして空中の親指）を見ると、32 GBで十分かもしれませんが、64 GB（1 TBを要求しているようではありません）で撮影し、他のサービスと成長のための部屋を残します。これにより、最大のテーブルをメモリに保持し、拡張の余地と他のサービスの余地を確保します。圧縮について彼らに話す必要はありません。サイジングで注意しなければならないことの1つは、現在のデータのサイジングではなく、1年後のデータのサイズです。ただし、ポイントルックアップのパフォーマンスは恐ろしいかもしれませんが、SQL Server 2016に移行するときに、追加のインデックスを追加するか、常に検討することができます リアルタイム操作分析の列ストアインデックス そのためにより多くのメモリが必要になります：）

ちなみにCTPはどのように進んでいますか？現在CTP3.3には、使用したい機能のほとんどが用意されているため、試用のためのリソースはありませんが、Windows Azureの試用版を入手できます、VMを起動し、サンプルデータを作成し、圧縮、主要機能のパフォーマンス、クエリなどを無料でテストします。または、MSDNライセンスを持っている場合は、これが組み込まれています。

要約すると、最大のテーブルをメモリに入れることができるサイズ（およびその他のもの）、または簡単なトライアルをセットアップして（クラウドで無料で）、必要な証拠を取得します。 VM完了したら、割り当てを解除することを忘れないでください:)

4
wBob

おそらくローカル開発マシンでETLパッケージを開発および保守しているときに、本番環境で期待するものと同様またはそれ以上の規模のテストデータを使用する場合があります。そうでない場合は、そうすることを検討します（匿名の実際のデータまたはアルゴリズムによって生成されたテストデータ、実際のデータがまったく機密である場合）。

これが当てはまる場合は、さまざまなメモリ条件下でプロセスを実行してプロファイルを作成し、より多くのRAMが大きな違いを生むのを止めるポイントを確認できます-経験則として、そして推測に基づいて推測してください。ベンチマークとプロファイリングは、より具体的な答えを提供し、ボーナスとして、最適化が容易な明らかなボトルネックを強調する場合があります。もちろん、開発/テスト環境は本番環境と正確に一致しない場合があるため、経験を使用して結果を解釈する必要がある場合があります変更される場合があります。

データベースと同じマシンでSSISを実行している場合は、SQL Serverエンジンインスタンスがすべてのメモリを要求しないように設定されていることを確認してください。メモリが不足すると、SSISでOOMエラーが発生するだけでなく、それよりもずっと前に、バッファをディスクにスプールするときにバッファをRAMに保持できるため、パフォーマンスに重大な問題が発生する可能性があります。 SSISおよびその他のタスク用に予約する必要がある量はプロセスによって大きく異なるため、プロファイリングはこれを評価するための良い方法です。多くの場合、これを管理しやすくするためにSSISを別のマシンで実行することをお勧めしますが、ネットワークスループットやライセンスの問題を考慮する必要がある場合もあります。

更新

コメントに従って、現実的なベンチマークを実行して、パフォーマンスが低下する場所（および/またはOOMエラーと関連する問題が発生し始める場所）を判断するためのリソースがない場合、RAM is割り当てられた場合、ウェアハウスとETLプロセスの詳細な知識がなければ、物事はかなり手波になります。ウェアハウスデータベース自体の経験則：十分なRAM最も一般的に使用されるすべてのインデックス。次に、あまり一般的に使用されないデータを考慮に入れて、近い将来/中程度の将来の予想される成長を可能にするためにいくつか。

これを計算すると、fafになる可能性があります。sp_spaceUsedは、インデックスで分解しないため、sys.allocation_unitsとそのフレンドを直接クエリする必要があります。あなたが始めるためにそこにいくつかの例があります http://blog.sqlauthority.com/2010/05/09/sql-server-size-of-index-table-for-each-index -solution-2 / は、クイック検索から得られた最初のいくつかの中で最高のように見えます。

ウェアハウスDB自体を実行する必要性に加えて、同じマシンで実行する場合はRAM SSISの要件）を追加し、SQL ServerにRAMこのメモリがSSISで実際に利用できることを保証するために設定されている制限。

全体的なデータサイズから、私の腸は、32 GbがデータベースエンジンとSSISのみに推奨される絶対的な最小値であり、SQLインスタンスを最大で26に設定し、実行しているため、同じマシン上のSSRSとその他のサービスの実用的な最小値は、将来の保証付きで64Gbです（現在のデータの3分の2は、他のサービスと予約が削減された後、それに収まるはずです）。もちろん、私の直感を引用しても、インフラストラクチャの人々との議論にそれほど遠くまでは行きません...

3
David Spillett