次の方法で共有

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 では、インメモリ テクノロジの同一の実装が使用されています。

Note

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

  • メモリ最適化行ストア形式。行はそれぞれ別のメモリ オブジェクトになります。 これは、高パフォーマンス OLTP ワークロード用に最適化されたクラシック インメモリ OLTP 形式です。 メモリ最適化行ストア形式で使用できるメモリ最適化テーブルには、次の 2 種類があります。

    • 持続的テーブル (SCHEMA_AND_DATA)。メモリに配置された行が、サーバーの再起動後に保持されます。 この種のテーブルは、インメモリ最適化の他の利点がある従来の行ストア テーブルのように動作します。
    • "非持続的テーブル" (SCHEMA_ONLY)。再起動後に行は保持されません。 この種のテーブルは一時データ用に設計されています (たとえば、一時テーブルの置換など)。つまり、データを一部の永続化されたテーブルに移動する前に迅速に読み込む必要があるテーブル (ステージング テーブルと呼ばれる) です。

  • メモリ最適化列ストア形式。データは列形式で整理されます。 この構造は HTAP シナリオ用に設計されています。OLTP ワークロードが実行されるのと同じデータ構造で分析クエリを行う必要があります。

Note

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

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

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

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

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

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

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

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

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

ハードウェア設定または仮想コア数をダウングレードすると、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 桁小さくする必要があります。

Note

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

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

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

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

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

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

関連するコンテンツ