Azure SQL Managed Instance でインメモリテクノロジを使用してパフォーマンスを最適化する

適用対象:Azure SQL Managed Instance

インメモリテクノロジにより、アプリケーションのパフォーマンスを向上させることができ、また、SQL Managed Instanceのコストを削減できる可能性があります。インメモリ OLTP は、Azure SQL Managed Instance の Business Critical サービスレベルで使用できます。

インメモリテクノロジをいつ使用するか

インメモリテクノロジを使用すれば、さまざまなワークロードでパフォーマンスの向上を実現できます。

トランザクション (オンライントランザクション処理 (OLTP))。ほとんどの要求でより小さなデータセットの読み取りや更新を行います (作成/読み取り/更新/削除（CRUD）操作など)。
分析 (オンライン分析処理 (OLAP)) では、ほとんどのクエリがレポート目的で複雑な計算を行い、また、定期的にスケジュールされたプロセスが負荷 (またはバルクロード) 操作を実行したり、既存のテーブルにデータの変更を書き込んだりします。多くの場合、OLAP ワークロードは OLTP ワークロードから定期的に更新されます。
混合 (ハイブリッドトランザクション/分析処理 (HTAP))。OLTP と OLAP の両方のクエリが同じデータセットで実行されます。

インメモリテクノロジでは、メモリに処理する必要があるデータを保持し、クエリのネイティブコンパイルを使用するか、バッチ処理などの高度な処理および基になるハードウェアで利用可能な SIMD 命令を使用して、これらのワークロードのパフォーマンスを向上させることができます。

概要

Azure SQL Managed Instance は、次のインメモリテクノロジをサポートします。

インメモリ OLTP により、1 秒あたりのトランザクション数が増え、トランザクション処理の遅延が少なくなります。インメモリ OLTP が有益なシナリオには、取引やゲームなどのスループットの高いトランザクション処理、イベントまたは IoT デバイスからのデータの取り込み、キャッシュ、データの読み込み、一時テーブルやテーブル変数のシナリオなどがあります。
"クラスター化列ストアインデックス": ストレージのフットプリントを減らし (最大 10 倍)、レポートと分析のクエリのパフォーマンスを向上させます。データマートでファクトテーブルと共に使用してデータベースにより多くのデータを格納し、パフォーマンスを向上させることができます。さらに、オペレーションデータベースで履歴データと共に使用してアーカイブし、最大で 10 倍のデータのクエリを実行可能にすることができます。
HTAP 用の "非クラスター化列ストアインデックス": オペレーションデータベースに直接クエリを実行して、ビジネスのリアルタイムの情報を取得します。抽出、変換、ロード (ETL) の高コストなプロセスを実行してデータウェアハウスが設定されるまで待機する必要はありません。非クラスター化列ストアインデックスにより、OLTP データベースで高速の分析クエリを実行しながら、運用ワークロードの影響を軽減できます。
HTAP 用にメモリが最適化されたクラスター化列ストアインデックスでは、高速なトランザクション処理を実行すると同時に、同じデータに対して分析クエリを非常に迅速に行うことができます。

列ストアインデックスとインメモリ OLTP は、それぞれ 2012 年と 2014 年に SQL Server に導入されました。 Azure SQL Database、Azure SQL Managed Instance、SQL Server では、インメモリテクノロジの同一の実装が使用されています。

注

AdventureWorksLTサンプルデータベースとostress.exeを使用したインメモリ OLTP テクノロジのパフォーマンス上の利点を示す詳細なステップバイステップチュートリアルについては、Azure SQL Managed Instance のインメモリサンプルを参照してください。

インメモリテクノロジの利点

クエリとトランザクションの処理が効率化するため、インメモリテクノロジはコストの削減にも役立ちます。 Azure SQL Managed Instanceのビジネスクリティカルサービス層に一度移行すると、通常はSQLマネージドインスタンスをアップグレードせずともパフォーマンスの向上が期待できます。場合によっては、インメモリテクノロジでパフォーマンスを向上させながら価格レベルを下げられる場合さえあります。

この記事では、Azure SQL Managed Instance に固有のインメモリ OLTP と列ストアインデックスの側面について説明し、サンプルも示します。

これらのテクノロジがストレージに及ぼす影響と、データサイズの上限について説明します。
これらのテクノロジを活用するデータベースを、異なる価格レベルの間で移動する際の管理方法を説明します。
インメモリ OLTP と列ストアインデックスを使用する方法を示す 2 つのサンプルを確認します。

SQL Server でのインメモリ OLTPの詳細については、次を参照してください。

インメモリ OLTP の概要と使用シナリオ (開始するためのお客様の導入事例と情報への参照)
インメモリ OLTP のドキュメント
列ストアインデックスガイド
リアルタイム運用分析とも呼ばれる、ハイブリッドトランザクション/分析処理 (HTAP)

インメモリ OLTP

インメモリ OLTP テクノロジでは、メモリ内のすべてのデータを保持することで、非常に高速なデータアクセス操作が提供されます。また、特殊なインデックス、クエリのネイティブコンパイル、ラッチフリーのデータアクセスを使用して、OLTP ワークロードのパフォーマンスを向上させます。インメモリ OLTP データを整理する方法には、次の 2 つがあります。

メモリ最適化行ストア形式。行はそれぞれ別のメモリオブジェクトになります。これは、高パフォーマンス OLTP ワークロード用に最適化されたクラシックインメモリ OLTP 形式です。メモリ最適化行ストア形式で使用できるメモリ最適化テーブルには、次の 2 種類があります。
- 持続的テーブル (SCHEMA_AND_DATA)。メモリに配置された行が、サーバーの再起動後に保持されます。この種のテーブルは、インメモリ最適化の他の利点がある従来の行ストアテーブルのように動作します。
- "非持続的テーブル" (SCHEMA_ONLY)。再起動後に行は保持されません。この種のテーブルは一時データ用に設計されています (たとえば、一時テーブルの置換など)。つまり、データを一部の永続化されたテーブルに移動する前に迅速に読み込む必要があるテーブル (ステージングテーブルと呼ばれる) です。
メモリ最適化列ストア形式。データは列形式で整理されます。この構造は HTAP シナリオ用に設計されています。OLTP ワークロードが実行されるのと同じデータ構造で分析クエリを行う必要があります。

注

インメモリ OLTP テクノロジは、メモリに完全に格納できるデータ構造用に設計されています。インメモリデータはディスクにオフロードできないため、十分なメモリがあるSQL Managed Instanceを使用するようにしてください。詳細については、「インメモリ OLTP のデータのサイズとストレージ上限」を参照してください。

インメモリ OLTP の簡単な手引き: クイックスタート 1: T-SQL のパフォーマンスを高速化するためのインメモリ OLTP テクノロジ。

インメモリ OLTP のデータのサイズとストレージ上限

インメモリ OLTP には、ユーザーデータの格納に使用されるメモリ最適化テーブルが含まれています。これらのテーブルは、メモリに格納する必要があります。この考え方は、"インメモリ OLTP ストレージ" と呼ばれます。

Business Critical サービスレベルには、仮想コアの数によって決まる 一定量の最大インメモリ OLTP メモリが含まれまています。

インメモリ OLTP ストレージ上限では、以下が考慮されます。

メモリ最適化テーブルとテーブル変数内のアクティブなユーザーデータの行。行の古いバージョンは上限の計算に含まれません。
メモリ最適化テーブル上のインデックス。
ALTER TABLE 操作の運用上のオーバーヘッド。

上限に達した場合、クォータ不足エラーが発生し、データの挿入や更新ができなくなります。このエラーを軽減するには、データを削除するか、データベースまたはプールの価格レベルを上げます。

インメモリ OLTP のストレージ使用率を監視する方法と、ほぼ上限に達したときのアラートを構成する方法の詳細については、インメモリストレージの監視に関するページを参照してください。

ハードウェア構成または仮想コア数を変更します

ハードウェア構成やvコア数をダウングレードすると、SQL管理のインスタンスに悪影響を及ぼす可能性があります。

メモリ最適化テーブル内のデータは、ハードウェア設定と仮想コア数のメモリ内 OLTP ストレージ制限内に収まる必要があります。十分なインメモリ OLTPストレージが利用可能でない設定にスケールダウンしようとすると、操作は失敗します。

メモリ内オブジェクトが存在するかどうかを判断します

SQLマネージドインスタンス内の特定のデータベースがインメモリ OLTPをサポートしているかどうかをプログラム的に理解する方法があります。次の Transact-SQL クエリを実行できます。

SELECT DatabasePropertyEx(DB_NAME(), 'IsXTPSupported');

クエリが 1 を返す場合、インメモリ OLTP はこのデータベースでサポートされています。

次のクエリは、インメモリテクノロジを使用してすべてのオブジェクトを識別します。

SELECT * FROM sys.tables WHERE is_memory_optimized=1
SELECT * FROM sys.table_types WHERE is_memory_optimized=1
SELECT * FROM sys.sql_modules WHERE uses_native_compilation=1

インメモリ列ストア

インメモリ列ストアテクノロジを使用することで、テーブルに大量のデータを格納してクエリを実行することができます。列ストアテクノロジでは列ベースのデータストレージ形式とバッチクエリ処理が使用され、OLAP ワークロードでは、従来の行指向型ストレージと比較して最大で 10 倍のクエリパフォーマンスが得られます。また、非圧縮データのサイズと比較して最大で 10 倍のデータ圧縮を実現できます。

データの整理に使用できる列ストアモデルには、次の 2 種類があります。

クラスター化列ストア。テーブル内のすべてのデータが列形式で格納されます。このモデルでは、テーブル内のすべての行が列形式で配置され、データを高圧縮し、テーブルでの高速な分析クエリとレポートを実行することができます。データの性質によっては、データのサイズが 10 倍から 100 倍小さくなる可能性があります。また、クラスター化列ストアモデルでは、大量のデータを高速で取り込むことができます (一括読み込み)。これは、100,000 行を超えるデータの大きなバッチがディスクに格納される前に圧縮されるためです。このモデルは、従来のデータウェアハウスシナリオに最適です。
非クラスター化列ストア。データは従来の行ストアテーブルに格納され、インデックスは、分析クエリに使用される列ストア形式となります。このモデルではハイブリッドトランザクション分析処理 (HTAP) が可能であり、従来のワークロードでパフォーマンスのリアルタイム分析を実行できます。 OLTP クエリは、小さな行セットにアクセスするために最適化されている行ストアテーブルで実行されますが、OLAP クエリは、スキャンと分析により適した選択肢である列ストアインデックスで実行されます。クエリオプティマイザーでは、クエリに基づき、動的に行ストアまたは列ストアを選択します。非クラスター化列ストアインデックスではデータのサイズは小さくなりません。これは、元のデータセットが変更されずに元の行ストアテーブルで保持されるためです。しかし、追加の列ストアインデックスのサイズは、同等の B ツリーインデックスより 1 桁小さくする必要があります。

注

メモリ内列ストアテクノロジでは、メモリでの処理に必要なデータのみが保持されますが、メモリに収まりきらないデータはディスク上に格納されます。そのため、メモリ内列ストア構造のデータの量が、使用可能なメモリの量を超える場合があります。

列ストアインデックスのデータサイズとストレージ

列ストアインデックスはメモリに収まる必要がありません。したがって、インデックスのサイズに対する唯一の上限は、データベース全体の最大サイズです。詳細については、Azure SQL Managed Instance のリソース制限の概要に関する説明を参照してください。 Azure SQL Managed Instance では、すべてのレベルの列ストアインデックスがサポートされます。

クラスター化列ストアインデックスを使用する場合、ベーステーブルストレージでは列圧縮が使用されます。この圧縮により、ユーザーデータのストレージフットプリントが大幅に削減されるため、データベースにより多くのデータを格納できます。これは、列アーカイブ圧縮でさらに拡張できます。実行できる圧縮の量はデータの性質に依存しますが、10 倍の圧縮は珍しくありません。

たとえば、最大サイズが 1 テラバイト (TB) のデータベースがあり、列ストアインデックスを使用して 10 倍の比率で圧縮した場合、データベースに合計 10 TB のユーザーデータを書き込むことができます。

非クラスター化列ストアインデックスを使用する場合、ベーステーブルは従来の行ストア形式のままで格納されます。そのため、ストレージはクラスター化列ストアインデックスほど大きく節約されません。ただし、多数の従来の非クラスター化インデックスを 1 つの列ストアインデックスに置き換えても、テーブルのストレージフットプリントにおける節約全体を確認できます。

フィードバック

このページはお役に立ちましたか?

Last updated on 2024-03-19

Azure SQL Managed Instance でインメモリ テクノロジを使用してパフォーマンスを最適化する

インメモリ テクノロジをいつ使用するか

概要

インメモリ テクノロジの利点