ISCSI SANソリッドステートドライブを実装する場合、コストベースオプティマイザー（CBO）にどのような影響がありますか

Question

Microsoft Technetの記事では、デフォルトのファイルグループとしてセカンダリファイルグループを作成することを推奨しています（以下の参照を参照）。セカンダリファイルグループには、それぞれが別々のディスクに配置されるいくつかのファイル、たとえば4つのファイルが必要です。同僚からの追加の経験則として、ファイルの数はCPUコアの数と同じである必要があります。

私の理解では、このセットアップは、回転ディスクドライブがソリッドステートドライブよりもはるかに遅いため、複数のヘッドからデータをストリーミングすることでパフォーマンスが向上する機械式回転ディスクドライブに最適です。この理解は正しいですか？

はいの場合、私の質問は、コストベースのオプティマイザーが新しいソリッドステートドライブを考慮に入れるかどうかです。新しいソリッドステートドライブに切り替えると、回転するハードドライブのパフォーマンスのボトルネックが解消されたようです。 IT運用グループから、現在1つの仮想ドライブが割り当てられているが、データは実際には複数のソリッドステートドライブを備えたISCSISANに保存されていることが通知されました。

この質問は、この規模の大規模なデータベースに最適なセットアップは何かに答えようとすることを目的としています。

ファイルが1つだけのデフォルトのセカンダリファイルグループが必要ですか？
CPUのコア数と同じ数のファイルを含むデフォルトのセカンダリファイルグループが必要ですか？
ソリッドステートドライブを使用するときにデータベーステーブルをパーティション化することでパフォーマンスが向上しますか？

私が取り組んでいる現在のプロジェクトには、大量のログデータを格納する数テラバイトのサイズのスケーリングされたデータベースが必要です。 1週間のサンプルには約1億5000万件のレコードがあり、3年間のログを保存する必要があります。それで、私は今、データを見つけるために長時間実行されているクエリを見ています。ほぼすべての作業が非クラスター化インデックスシークに起因するようにインデックスを調整しました。オプティマイザーは、欠落しているインデックスを追加することを推奨しません。

注

Microsoft SQL Serverのライセンスは、現在CPUコアによるものです。そのため、特にパフォーマンスが向上しない場合は、問題に対してより多くのコアをスローすることに敏感です。

さらに、現在SQL Server 2014で開発中ですが、開発と本番の両方でSQL Server2017に移行する予定です。

更新1

プロジェクトは毎晩ログをロードしますが、ログはまったく変更されないため、更新または削除はほとんど（おそらくまったく）行われないと予想されます。そのため、ログは再ロードされません。それ以外はすべて、分析目的で読み取られます。

システムテーブルのPRIMARYファイルグループ。SECONDARYのデフォルトファイルグループは他のすべてのものです。これを行う理由は、この質問の下部にあるリンクで説明されています。

テーブルパーティション用に個別のファイルグループが作成されます。データベース内には、SECONDARYファイルグループ内に存在するのに十分小さいテーブルが他にもあります。1つが1億レコード（IDENTITY行番号でパーティション化）を超え、もう1つが数十億レコードになる2つのテーブルのみをパーティション化します。（時間で分割[毎月]）。

3年以上月ごとに分割する予定です。したがって、36個のパーティションがあります。毎年ファイルグループを作成し、対応する年間ファイルグループに12個のファイルを配置します。パーティション戦略は、分析目的で多くのデータスキャンが行われるため、読み取り時間を短縮することです。年間ファイルグループ戦略は、DBAが単一のファイルグループを削除することで、1年分のデータを削除できるようにするためのメンテナンスを容易にするためのものです。

参照：

デフォルトのファイルグループを設定するSQL Serverのベストプラクティス

Forrest · Accepted Answer

コストベースのオプティマイザは、（現在）ハードウェアに基づいて推定されるIOコストを変更しません。

この質問は、ご使用の環境に最適なファイルグループとパーティション化戦略に答えることを目的としています。その場合、オプティマイザーが何をするかを誰が気にしますか？問題は何がうまく機能するかですあなたの環境でそして本当の答えはそれをテストすることです。

Joe Obbish · Answer

経験則として、ファイルグループを追加して保守または管理性を向上させ、ファイルを追加してパフォーマンスを向上させます。もちろん、すべてのワークロードまたはシナリオが追加のファイルまたはファイルグループの恩恵を受けるわけではありません。いくつかの例：

多くのCPUとユーザーデータベース用の1つのデータファイルのみを備えたWindowsサーバーについて考えてみます。データファイルが1つしかないということは、LUNが1つしかないことを意味します。単一のLUNが提供できるよりも多くのI/Oを必要とするワークロードを作成することが可能です。ワークロードがI/Oによってボトルネックになっている場合は、各ファイルが独自のLUNにあるデータベースにファイルを追加することで、パフォーマンスを向上させることができます。待機統計を見ると、この状況にあるかどうかがわかります。
多くのCPUとユーザーデータベース用の1つのデータファイルのみを備えたWindowsサーバーについて考えてみます。ファイルが1つしかないために発生する論理的な競合によってボトルネックになるワークロードを作成する可能性があります。たとえば、データを変更する特定の種類のクエリはすべて、同じPFSページを一度に変更する必要があります。メモリ内の論理的な競合によってワークロードがボトルネックになっている場合は、ファイルが以前と同じLUN上にある場合でも、ファイルを追加することでパフォーマンスを向上させることができます。追加のファイルがあるということは、競合を減らす「アクティブな」PFSページがあることを意味します。詳細については、この記事を参照してください。
テーブルまたはパーティションを特定のファイルグループに割り当てることができます。ファイルに対してはそれを行うことはできません。したがって、パージしたい古いデータがあり、すべてのストレージを再利用したい場合は、ファイルグループが適している可能性があります。すべてのユーザーデータをセカンダリファイルグループに配置することには、一部の人々が誓ういくつかのメンテナンス上の利点があります。重要な点は、ファイルグループはパフォーマンスではなく管理を支援することを考えるべきであるということです。