Azure SQL Database でのインメモリ テクノロジを使用したパフォーマンスの最適化

  • [アーティクル]

適用対象: Azure SQL Database

インメモリ テクノロジにより、アプリケーションのパフォーマンスを向上させることができ、また、データベースのコストを削減できる可能性があります。

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

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

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

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

概要

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

  • インメモリ 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 Database のインメモリ サンプルを参照してください。

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

クエリとトランザクションの処理が効率化するため、インメモリ テクノロジはコストの削減にも役立ちます。 通常は、パフォーマンスの向上を実現するためにデータベースの価格レベルをアップグレードする必要はありません。 場合によっては、インメモリ テクノロジでパフォーマンスを向上させながら価格レベルを下げられる場合さえあります。

インメモリ OLTP を利用することで、クォーラム ビジネス ソリューションで DTU を 70% 向上させながら、ワークロードを倍増させることができました。 詳細については、Azure SQL Database のインメモリ OLTP に関するブログ記事を参照してください。

Note

インメモリ OLTP は、Azure SQL Database の Premium (DTU) サービス レベルと Business Critical (仮想コア) レベルで使用できます。 Hyperscale サービス レベルでは、インメモリ OLTP オブジェクトのサブセットがサポートされます。 詳細については、「Hyperscale の制限事項」を参照してください。

列ストア インデックスは、Basic レベルを除くすべてのサービス レベルで使用でき、サービス目標が S3 未満の場合は Standard レベルで使用できます。 詳細については、「列ストア インデックスを含むデータベースのサービス レベルの変更」を参照してください。

この記事では、Azure SQL Database に固有のインメモリ OLTP と列ストア インデックスの側面について説明し、以下を確認できるサンプルも含まれています。

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

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

インメモリ OLTP

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

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

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

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

Note

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

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

インメモリ OLTP には、ユーザー データの格納に使用されるメモリ最適化テーブルが含まれています。 これらのテーブルは、メモリに格納する必要があります。 各サービス目標には、メモリ最適化テーブルのメモリ クォータまたは上限 (In-Memory OLTP ストレージと呼ばれます) があります。

サポートされる各単一データベース サービス目標と各エラスティック プール サービス目標には、一定量のインメモリ OLTP ストレージが含まれます。

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

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

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

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

エラスティック プールについて

エラスティック プールでは、インメモリ OLTP ストレージはプール内のすべてのデータベースで共有されます。 したがって、1 つのデータベースでの使用が他のデータベースに影響を及ぼす可能性があります。 これに対する軽減策は次の 2 つです。

  • データベースに対し、プール全体の eDTU または仮想コア数よりも少ない Max eDTU または Max vCore を構成します。 また、この最大値は、プール内の任意のデータベースのインメモリ OLTP ストレージ使用率を比例的に制限します。
  • 0 より大きい Min eDTU または Min vCore を構成します。 これにより、プール内の各データベースに、構成された Min eDTU または Min vCore に対応する利用可能なインメモリ OLTP ストレージの量が確保されます。

インメモリ OLTP テクノロジを使用するデータベースのサービス レベルの変更

インメモリ OLTP は、Azure SQL Database の General Purpose レベル、Standard レベル、または Basic レベルでは、サポートされていません。 したがって、インメモリ OLTP オブジェクトがあるデータベースをこれらのいずれかのレベルにスケーリングすることはできません。 データベースをこれらのサービス レベルのいずれかにスケーリングする場合は、すべてのメモリ最適化テーブルとテーブル型、およびネイティブ コンパイル T-SQL モジュールをすべて削除するか、ディスク ベースのオブジェクトと通常の T-SQL モジュールに変換します。

Business Critical データベースまたは Premium データベースをスケールダウンする場合、メモリ最適化テーブル内のデータは、データベースまたはエラスティック プールの宛先サービス目標で使用できるインメモリ OLTP ストレージ内に収まる必要があります。 データベースまたはエラスティック プールをスケールダウンしようとしたり、データベースをエラスティック プールに移動しようとしたときに、宛先サービス目標に十分な使用可能なインメモリ OLTP ストレージがない場合、操作が失敗します。

インメモリ OLTP オブジェクトが存在するかどうかを確認する

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

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

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

次のクエリは、データベースを Hyperscale、General Purpose、Standard または Basic レベルにスケーリングする前に削除しておく必要のあるオブジェクトをすべて特定します。

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 ツリー インデックスよりも桁違いに小さくなります。

Note

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

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

列ストア インデックスはメモリに完全に収まる必要はありません。 そのため、インデックス サイズの唯一の上限は、DTU ベースの購入モデルおよび仮想コアベースの購入モデルに関する記事で記述されているデータベース全体の最大サイズです。

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

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

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

列ストア インデックスを含むデータベースのサービス レベルの変更

DTU 購入モデルを使用していて、データベースに列ストア インデックスが含まれている場合、S3 サービス目標の下にデータベースをスケーリングすると、アプリケーションが動作しなくなる可能性があります。 列ストア インデックスは、Hyperscale、Business Critical、Premium サービス レベル、および S3 以降を使用している場合は Standard サービス レベルでのみサポートされます。 Standard または Basic サービス レベルのデータベースでは、列ストア インデックスはサポートされていません。 サポートされていないサービス レベルまたはサービス目標にデータベースをスケーリングすると、列ストア インデックスは使用できなくなります。 DML ステートメントを実行すると、システムによりインデックスは維持されますが、インデックスは使用されません。 後でサポートされているサービス レベルまたはサービス目標にスケーリングを戻すと、列ストア インデックスはまたすぐに利用できるようになります。

クラスター化列ストア インデックスがある場合、データベースがサポートされていないサービス レベルまたはサービス目標にスケーリングされると、テーブル全体が使用できなくなります。 スケーリング操作の前に、クラスター化列ストア インデックスをすべて削除し、行ストア クラスター化インデックスまたはヒープに置き換えます。

関連するコンテンツ