SQL Server におけるインメモリ OLTP のハードウェアに関する考慮事項

  • [アーティクル]

インメモリ OLTP では、従来のディスク ベース テーブルと異なる方法でメモリとディスクを使用します。 インメモリ OLTP で見られるパフォーマンスの向上は、使用するハードウェアによって異なります。 この記事では、全般的なハードウェアについてのいくつかの考慮事項について説明します。また、インメモリ OLTP で使用するハードウェアについての汎用的なガイドラインを提供します。

Note

この記事は、2013 年 8 月 1 日に Microsoft SQL Server 2014 チームによって発行されたブログです。 このブログの Web ページは廃止されます。

SQL Server インメモリ OLTP

CPU

インメモリ OLTP では、高スループットの OLTP ワークロードをサポートするハイエンド サーバーは必要ありません。 CPU ソケットを 2 つ備えたミッドレンジ サーバーを使用することをおすすめします。 インメモリ OLTP によって実現されるスループットの向上により、2 つのソケットでもビジネス ニーズを十分満たすことができます。

インメモリ OLTP で同時マルチスレッド (SMT) を有効にすることをおすすめします。 一部の OLTP ワークロードでは、SMTを使用する場合、最大 40% のパフォーマンスの向上が見られました。

メモリ

メモリ最適化テーブルはすべて、完全にメモリ内に存在します。 そのため、データベースに対して実行されるワークロードに耐えられる、テーブル自体にとって十分な物理メモリを備える必要がありますが、実際に必要なメモリの量はワークロード次第です。出発点としては、データ サイズの約 2 倍の十分に使用可能なメモリが必要です。 ワークロードで従来のディスク ベース テーブルも処理される場合、バッファー プール用の十分なメモリも必要です。

所定のメモリ最適化テーブルで使用されるメモリの量を判断するには、次のクエリを実行します。

select object_name(object_id), * from sys.dm_db_xtp_table_memory_stats;

結果に、メモリ最適化テーブルとそのインデックスに使用されるメモリが示されます。 テーブル データには、ユーザー データとともに、トランザクションの実行でこれまでどおり必要であったり、システムでまだクリーンアップされていないすべての古い行のバージョンが含まれます。 ハッシュ インデックスで使用されるメモリは一定で、テーブル内の行数には左右されません。

インメモリ OLTP を使用する際は、データベース全体がメモリに収まる必要がないことを留意する必要があります。 ホット データ (つまり、メモリ最適化テーブル) のサイズが 256 GB を超えない限り、数 TB 規模のデータベースを使用しても、インメモリ OLTP のメリットを享受できます。 単一データベースについて SQL Server で管理できるチェックポイント データ ファイルの最大数は、各ファイルを 128 MB とすると 4,000 です。 理論上は最大 512 GB となりますが、SQL Server がチェックポイント ファイルのマージに対応し、ファイルの制限である 4,000 に達しないようにするために、256 GB までがサポートされます。 この制限はメモリ最適化テーブルのみに適用されます。同じ SQL Server データベース内の従来のディスク ベース テーブルには、このようなサイズ制限はありません。

非持続的メモリ最適化テーブル (NDT)、つまり DURABILITY=SCHEMA_ONLY が設定されたメモリ最適化テーブルは、ディスクに保存されません。 NDT はチェックポイント ファイルの数により制限されませんが、256 GB のみがサポートされます。 この記事の残りの部分で説明するログとデータ ドライブに関する考慮事項は、持続性のないテーブルには適用されません。このようなテーブルでは、データがメモリ内にのみ存在するためです。

ログ ドライブ

メモリ最適化テーブルに関連するログ レコードは、その他の SQL Server のログ レコードと共に、データベースのトランザクション ログに書き込まれます。

トランザクションが長期間待機する必要がなくログ I/O の競合を回避できる、低遅延のドライブにログ ファイルを配置することが常に重要です。 システムは、最も低速なコンポーネント (アムダールの法則) と同じ速度で実行されます。 インメモリ OLTP を実行するときに、ログ I/O デバイスがボトルネックにならないようにする必要があります。 低待機時間の、少なくとも SSD の記憶装置を使用することをお勧めします。

メモリ最適化テーブルでは、インデックス操作も UNDO レコードもログに記録されないため、使用されるログ帯域幅はディスク ベース テーブルよりも少なくなります。 これは、ログ I/O の競合を軽減するのに役立ちます。

データ ドライブ

チェックポイント ファイルを使用したメモリ最適化テーブルの持続には、ストリーミング I/O が使用されます。 そのため、これらのファイルでは、低遅延または高速なランダム I/O のドライブは不要です。 代わりに、これらのドライブの主な要因は、ホスト バス アダプター (HBA) の順次 I/O と帯域幅の速度になります。 そのため、チェックポイント ファイル用の SSD は必要ありません。順次 I/O の速度が要件を満たしている限り、これらは高パフォーマンスのスピンドル (SAS など) に配置できます。

速度要件を決定する上で最も重要な要因が、サーバー再起動時のRTO [目標復旧時間] です。 データベースの復旧中に、メモリ最適化テーブルのすべてのデータをディスクからメモリに読み込む必要があります。 データベースの復旧は、I/O サブシステムの順次読み込みの速度で行わるため、ディスクがボトルネックになります。

厳密な RTO の要件を満たすには、MEMORY_OPTIMIZED_DATA ファイル グループに複数のコンテナーを追加することで、複数のディスクにチェックポイント ファイルを展開することをおすすめします。 SQL Server では、複数のドライブからのチェックポイント ファイルの並列読み込みをサポートしています。つまり、復旧は、ドライブの集計速度で行われます。

ディスクの容量の点では、2 倍から 3 倍のサイズのメモリ最適化テーブルを利用可能にすることをおすすめします。

関連するコンテンツ