SQL Database でのインメモリ テクノロジを使用したパフォーマンスの最適化Optimize performance by using In-Memory technologies in SQL Database

Azure SQL Database のインメモリ テクノロジにより、アプリケーションのパフォーマンスを向上させることができ、また、データベースのコストを削減できる可能性があります。In-Memory technologies in Azure SQL Database enable you to improve performance of your application, and potentially reduce cost of your database.

インメモリ テクノロジをいつ使用するかWhen to use In-Memory technologies

Azure SQL Database のインメモリ テクノロジを使用すれば、さまざまなワークロードでパフォーマンスの向上を実現できます。By using In-Memory technologies in Azure SQL Database, you can achieve performance improvements with various workloads:

  • トランザクション (オンライン トランザクション処理 (OLTP))。ほとんどの要求でより小さなデータ セットの読み取りや更新を行います (CRUD 操作など)。Transactional (online transactional processing (OLTP)) where most of the requests read or update smaller set of data (for example, CRUD operations).
  • 分析 (オンライン分析処理 (OLAP))。ほとんどのクエリにレポート目的の複雑な計算が含まれます。一定数のクエリでは、既存のテーブルに対するデータの読み込みや追加が行われたり (一括読み込みと呼ばれる)、テーブルからのデータの削除が行われたりします。Analytic (online analytical processing (OLAP)) where most of the queries have complex calculations for the reporting purposes, with a certain number of queries that load and append data to the existing tables (so called bulk-load), or delete the data from the tables.
  • 混合 (ハイブリッド トランザクション/分析処理 (HTAP))。OLTP と OLAP の両方のクエリが同じデータ セットで実行されます。Mixed (hybrid transaction/analytical processing (HTAP)) where both OLTP and OLAP queries are executed on the same set of data.

インメモリ テクノロジでは、メモリに処理する必要があるデータを保持し、クエリのネイティブ コンパイルを使用するか、バッチ処理などの高度な処理および基になるハードウェアで利用可能な SIMD 命令を使用して、これらのワークロードのパフォーマンスを向上させることができます。In-memory technologies can improve performance of these workloads by keeping the data that should be processed into the memory, using native compilation of the queries, or advanced processing such as batch processing and SIMD instructions that are available on the underlying hardware.

概要Overview

Azure SQL Database には、次のインメモリ テクノロジがあります。Azure SQL Database has the following In-Memory technologies:

  • インメモリ OLTP により、1 秒あたりのトランザクション数が増え、トランザクション処理の遅延が少なくなります。In-Memory OLTP increases number of transactions per second and reduces latency for transaction processing. インメモリ OLTP が有益なシナリオには、取引やゲームなどのスループットの高いトランザクション処理、イベントまたは IoT デバイスからのデータの取り込み、キャッシュ、データの読み込み、一時テーブルやテーブル変数のシナリオなどがあります。Scenarios that benefit from In-Memory OLTP are: high-throughput transaction processing such as trading and gaming, data ingestion from events or IoT devices, caching, data load, and temporary table and table variable scenarios.
  • "クラスター化列ストア インデックス": ストレージのフットプリントを減らし (最大 10 倍)、レポートと分析のクエリのパフォーマンスを向上させます。Clustered columnstore indexes reduce your storage footprint (up to 10 times) and improve performance for reporting and analytics queries. データ マートでファクト テーブルと共に使用してデータベースにより多くのデータを格納し、パフォーマンスを向上させることができます。You can use it with fact tables in your data marts to fit more data in your database and improve performance. さらに、オペレーション データベースで履歴データと共に使用してアーカイブし、最大で 10 倍のデータのクエリを実行可能にすることができます。Also, you can use it with historical data in your operational database to archive and be able to query up to 10 times more data.
  • HTAP 用の "非クラスター化列ストア インデックス": オペレーション データベースに直接クエリを実行して、ビジネスのリアルタイムの情報を取得します。抽出、変換、ロード (ETL) の高コストなプロセスを実行してデータ ウェアハウスが設定されるまで待機する必要はありません。Nonclustered columnstore indexes for HTAP help you to gain real-time insights into your business through querying the operational database directly, without the need to run an expensive extract, transform, and load (ETL) process and wait for the data warehouse to be populated. 非クラスター化列ストア インデックスにより、OLTP データベースで高速の分析クエリを実行しながら、運用ワークロードの影響を軽減できます。Nonclustered columnstore indexes allow fast execution of analytics queries on the OLTP database, while reducing the impact on the operational workload.
  • HTAP 用にメモリが最適化されたクラスター化列ストア インデックスでは、高速なトランザクション処理を実行すると同時に、同じデータに対して分析クエリを非常に迅速に行うことができます。Memory-optimized clustered columnstore indexes for HTAP enables you to perform fast transaction processing, and to concurrently run analytics queries very quickly on the same data.

列ストア インデックスは 2012 年以降、インメモリ OLTP は 2014 年以降、SQL Server 製品の一部です。Both columnstore indexes and In-Memory OLTP have been part of the SQL Server product since 2012 and 2014, respectively. Azure SQL Database と SQL Server では、インメモリ テクノロジの同一の実装が使用されています。Azure SQL Database and SQL Server share the same implementation of In-Memory technologies. 今後、これらのテクノロジの新しい機能は最初に Azure SQL Database でリリースされてから、SQL Server でリリースされます。Going forward, new capabilities for these technologies are released in Azure SQL Database first, before they are released in SQL Server.

インメモリ テクノロジの利点Benefits of In-memory technology

クエリとトランザクションの処理が効率化するため、インメモリ テクノロジはコストの低減にも役立ちます。Because of the more efficient query and transaction processing, In-Memory technologies also help you to reduce cost. 通常は、パフォーマンスの向上を実現するためにデータベースの価格レベルをアップグレードする必要はありません。You typically don't need to upgrade the pricing tier of the database to achieve performance gains. 場合によっては、インメモリ テクノロジでパフォーマンスを向上させながら価格レベルを下げられる場合さえあります。In some cases, you might even be able reduce the pricing tier, while still seeing performance improvements with In-Memory technologies.

インメモリ OLTP がパフォーマンスの著しい向上を促した例を 2 つ紹介します。Here are two examples of how In-Memory OLTP helped to significantly improve performance:

注意

インメモリ テクノロジは、Premium および Business Critical レベルの Azure SQL データベースと Premium エラスティック プールで使用できます。In-Memory technologies are available in Premium and Business Critical tier Azure SQL databases and Premium elastic pools.

次のビデオでは、Azure SQL Database でのインメモリ テクノロジ使用によるパフォーマンス向上の可能性について説明します。The following video explains potential performance gains with In-Memory technologies in Azure SQL Database. 表示されるパフォーマンスの向上は、常にさまざまな要因 (ワークロードとデータの性質、データベースのアクセス パターンなど) に依存していることに注意してください。Remember that the performance gain that you see always depends on many factors, including the nature of the workload and data, access pattern of the database, and so on.

この記事では、Azure SQL Database に固有のインメモリ OLTP と列ストア インデックスの側面について説明し、サンプルも示します。This article describes aspects of In-Memory OLTP and columnstore indexes that are specific to Azure SQL Database and also includes samples:

  • これらのテクノロジがストレージに及ぼす影響と、データ サイズの上限について説明します。You'll see the impact of these technologies on storage and data size limits.
  • これらのテクノロジを活用するデータベースを、異なる価格レベルの間で移動する際の管理方法を説明します。You'll see how to manage the movement of databases that use these technologies between the different pricing tiers.
  • インメモリ OLTP と列ストア インデックスを Azure SQL Database で使用する方法を示す 2 つのサンプルを確認します。You'll see two samples that illustrate the use of In-Memory OLTP, as well as columnstore indexes in Azure SQL Database.

詳細については、次を参照してください。For more information, see:

インメモリ OLTPIn-memory OLTP

インメモリ OLTP テクノロジでは、メモリ内のすべてのデータを保持することで、非常に高速なデータ アクセス操作が提供されます。In-memory OLTP technology provides extremely fast data access operations by keeping all data in memory. また、特殊なインデックス、クエリのネイティブ コンパイル、ラッチフリーのデータ アクセスを使用して、OLTP ワークロードのパフォーマンスを向上させます。It also uses specialized indexes, native compilation of queries, and latch-free data-access to improve performance of the OLTP workload. インメモリ OLTP データを整理する方法には、次の 2 つがあります。There are two ways to organize your In-Memory OLTP data:

  • メモリ最適化行ストア形式。行はそれぞれ別のメモリ オブジェクトになります。Memory-optimized rowstore format where every row is a separate memory object. これは、高パフォーマンス OLTP ワークロード用に最適化されたクラシック インメモリ OLTP 形式です。This is a classic In-Memory OLTP format optimized for high-performance OLTP workloads. メモリ最適化行ストア形式で使用できるメモリ最適化テーブルには、次の 2 種類があります。There are two types of memory-optimized tables that can be used in the memory-optimized rowstore format:
    • 持続的テーブル (SCHEMA_AND_DATA)。メモリに配置された行が、サーバーの再起動後に保持されます。Durable tables (SCHEMA_AND_DATA) where the rows placed in memory are preserved after server restart. この種のテーブルは、インメモリ最適化の他の利点がある従来の行ストア テーブルのように動作します。This type of tables behaves like a traditional rowstore table with the additional benefits of in-memory optimizations.
    • "非持続的テーブル" (SCHEMA_ONLY)。再起動後に行は保持されません。Non-durable tables (SCHEMA_ONLY) where the rows are not-preserved after restart. この種のテーブルは一時データ用に設計されています (たとえば、一時テーブルの置換など)。つまり、データを一部の永続化されたテーブルに移動する前に迅速に読み込む必要があるテーブル (ステージング テーブルと呼ばれる) です。This type of table is designed for temporary data (for example, replacement of temp tables), or tables where you need to quickly load data before you move it to some persisted table (so called staging tables).
  • メモリ最適化列ストア形式。データは列形式で整理されます。Memory-optimized columnstore format where data is organized in a columnar format. この構造は HTAP シナリオ用に設計されています。OLTP ワークロードが実行されるのと同じデータ構造で分析クエリを行う必要があります。This structure is designed for HTAP scenarios where you need to run analytic queries on the same data structure where your OLTP workload is running.

注意

インメモリ OLTP テクノロジは、メモリに完全に格納できるデータ構造用に設計されています。In-Memory OLTP technology is designed for the data structures that can fully reside in memory. インメモリ データはディスクにオフロードできないため、十分なメモリがあるデータベースを使用するようにしてください。Since the In-memory data cannot be offloaded to disk, make sure that you are using database that has enough memory. 詳細については、「インメモリ OLTP のデータのサイズとストレージ上限」を参照してください。See Data size and storage cap for In-Memory OLTP for more details.

インメモリ OLTP の簡単な手引き:クイック スタート 1:T-SQL のパフォーマンスの高速化のためのインメモリ OLTP テクノロジ (作業の開始に役立つ別の記事)A quick primer on In-Memory OLTP: Quickstart 1: In-Memory OLTP Technologies for Faster T-SQL Performance (another article to help you get started)

テクノロジについての詳細なビデオ:In-depth videos about the technologies:

特定のデータベースがインメモリ OLTP をサポートしているかどうかをプログラムによって確認する方法があります。There is a programmatic way to understand whether a given database supports In-Memory OLTP. 次の Transact-SQL クエリを実行できます。You can execute the following Transact-SQL query:

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

クエリが 1 を返す場合、インメモリ OLTP はこのデータベースでサポートされています。If the query returns 1, In-Memory OLTP is supported in this database. 次のクエリは、データベースを Standard/Basic にダウングレードする前に削除しておく必要のあるオブジェクトをすべて特定します。The following queries identify all objects that need to be removed before a database can be downgraded to 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

インメモリ OLTP のデータのサイズとストレージ上限Data size and storage cap for In-Memory OLTP

インメモリ OLTP には、ユーザー データの格納に使用されるメモリ最適化テーブルが含まれています。In-Memory OLTP includes memory-optimized tables, which are used for storing user data. これらのテーブルは、メモリに格納する必要があります。These tables are required to fit in memory. メモリは SQL Database サービスで直接管理するため、ユーザー データについてクォータの概念があります。Because you manage memory directly in the SQL Database service, we have the concept of a quota for user data. この考え方は、"インメモリ OLTP ストレージ" と呼ばれます。This idea is referred to as In-Memory OLTP storage.

サポートされている各単一データベースの価格レベルと各エラスティック プールの価格レベルには、一定量のインメモリ OLTP ストレージが含まれます。Each supported single database pricing tier and each elastic pool pricing tier includes a certain amount of In-Memory OLTP storage. DTU ベースのリソース制限 - 単一データベースDTU ベースのリソース制限 - エラスティック プール仮想コアベースのリソース制限 - 単一データベース、および 仮想コアベースのリソース制限 - エラスティック プールに関する各ページを参照してください。See DTU-based resource limits - single database, DTU-based resource limits - elastic pools,vCore-based resource limits - single databases and vCore-based resource limits - elastic pools.

インメモリ OLTP ストレージ上限では、以下が考慮されます。The following items count toward your In-Memory OLTP storage cap:

  • メモリ最適化テーブルとテーブル変数内のアクティブなユーザー データの行。Active user data rows in memory-optimized tables and table variables. 古い行バージョンはこの上限では考慮されません。Note that old row versions don't count toward the cap.
  • メモリ最適化テーブル上のインデックス。Indexes on memory-optimized tables.
  • ALTER TABLE 操作の運用上のオーバーヘッド。Operational overhead of ALTER TABLE operations.

上限に達した場合、クォータ不足エラーが発生し、データの挿入や更新ができなくなります。If you hit the cap, you receive an out-of-quota error, and you are no longer able to insert or update data. このエラーを軽減するには、データを削除するか、データベースまたはプールの価格レベルを上げます。To mitigate this error, delete data or increase the pricing tier of the database or pool.

インメモリ OLTP のストレージ使用率を監視する方法と、ほぼ上限に達したときのアラートを構成する方法の詳細については、インメモリ ストレージの監視に関するページを参照してください。For details about monitoring In-Memory OLTP storage utilization and configuring alerts when you almost hit the cap, see Monitor In-Memory storage.

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

エラスティック プールでは、インメモリ OLTP ストレージはプール内のすべてのデータベースで共有されます。With elastic pools, the In-Memory OLTP storage is shared across all databases in the pool. したがって、1 つのデータベースでの使用が他のデータベースに影響を及ぼす可能性があります。Therefore, the usage in one database can potentially affect other databases. これに対する軽減策は次の 2 つです。Two mitigations for this are:

  • データベースに対し、プール全体の eDTU または仮想コア数よりも少ない Max-eDTU または MaxvCore を構成します。Configure a Max-eDTU or MaxvCore for databases that is lower than the eDTU or vCore count for the pool as a whole. これにより、プール内のすべてのデータベースでインメモリ OLTP のストレージ使用率について、この eDTU に対応する上限が設定されます。This maximum caps the In-Memory OLTP storage utilization, in any database in the pool, to the size that corresponds to the eDTU count.
  • 0 より大きい Min-eDTU または MinvCore を構成します。Configure a Min-eDTU or MinvCore that is greater than 0. これにより、プール内の各データベースに、構成された Min-eDTU または vCore に対応する利用可能なインメモリ OLTP ストレージの量が確保されます。This minimum guarantees that each database in the pool has the amount of available In-Memory OLTP storage that corresponds to the configured Min-eDTU or vCore.

インメモリ OLTP テクノロジを使用するデータベースのサービス レベルの変更Changing service tiers of databases that use In-Memory OLTP technologies

データベースまたはインスタンスはいつでも、General Purpose から Business Critical (または Standard から Premium) など、より高いレベルにアップグレードすることができます。You can always upgrade your database or instance to a higher tier, such as from General Purpose to Business Critical (or Standard to Premium). 使用可能な機能とリソースが増えるだけです。The available functionality and resources only increase.

しかし、レベルをダウングレードすると、データベースに悪影響を与えることがあります。But downgrading the tier can negatively impact your database. データベースにインメモリ OLTP オブジェクトが含まれている場合に、Business Critical から General Purpose (または Premium から Standard または Basic) にダウングレードすると、影響が特に大きくなります。The impact is especially apparent when you downgrade from Business Critical to General Purpose (or Premium to Standard or Basic) when your database contains In-Memory OLTP objects. ダウングレードした後は、メモリ最適化テーブルは (引き続き表示されたとしても) 使用できません。Memory-optimized tables are unavailable after the downgrade (even if they remain visible). エラスティック プールの価格レベルを下げる場合、またはインメモリ テクノロジを使用しているデータベースを Standard または Basic のエラスティック プールに移動する場合にも同じ考慮事項が該当します。The same considerations apply when you're lowering the pricing tier of an elastic pool, or moving a database with In-Memory technologies, into a Standard or Basic elastic pool.

重要

General Purpose、Standard または Basic レベルでは、インメモリ OLTP はサポートされていません。In-Memory OLTP isn't supported in the General Purpose, Standard or Basic tier. したがって、インメモリ OLTP オブジェクトがあるデータベースを、Standard や Basic レベルに移動することはできません。Therefore, it isn't possible to move a database that has any In-Memory OLTP objects to the Standard or Basic tier.

データベースを Standard または Basic にダウングレードする前に、すべてのメモリ最適化テーブルとテーブルの種類に加えて、すべてのネイティブ コンパイル T-SQL モジュールを削除してください。Before you downgrade the database to Standard/Basic, remove all memory-optimized tables and table types, as well as all natively compiled T-SQL modules.

Business Critical レベルのリソースのスケール ダウン:メモリ最適化テーブルのデータは、データベースのレベルや Managed Instance に関連付けられているか、あるいはエラスティック プールで使用可能な、インメモリ OLTP ストレージ内に格納する必要があります。Scaling-down resources in Business Critical tier: Data in memory-optimized tables must fit within the In-Memory OLTP storage that is associated with the tier of the database or Managed Instance, or it is available in the elastic pool. レベルをスケールダウンしようとしたり、使用できるインメモリ OLTP ストレージが十分ではないプールにデータベースを移動しようとしたりすると、操作が失敗します。If you try to scale-down the tier or move the database into a pool that doesn't have enough available In-Memory OLTP storage, the operation fails.

インメモリ列ストアIn-memory columnstore

インメモリ列ストア テクノロジを使用することで、テーブルに大量のデータを格納してクエリを実行することができます。In-memory columnstore technology is enabling you to store and query a large amount of data in the tables. 列ストア テクノロジでは列ベースのデータ ストレージ形式とバッチ クエリ処理が使用され、OLAP ワークロードでは、従来の行指向型ストレージと比較して最大で 10 倍のクエリ パフォーマンスが得られます。Columnstore technology uses column-based data storage format and batch query processing to achieve gain up to 10 times the query performance in OLAP workloads over traditional row-oriented storage. また、非圧縮データのサイズと比較して最大で 10 倍のデータ圧縮を実現できます。You can also achieve gains up to 10 times the data compression over the uncompressed data size. データの整理に使用できる列ストア モデルには、次の 2 種類があります。There are two types of columnstore models that you can use to organize your data:

  • クラスター化列ストア。列形式で、テーブル内のすべてのデータが整理されます。Clustered columnstore where all data in the table is organized in the columnar format. このモデルでは、テーブル内のすべての行が列形式で配置され、データを高圧縮し、テーブルでの高速な分析クエリとレポートを実行することができます。In this model, all rows in the table are placed in columnar format that highly compresses the data and enables you to execute fast analytical queries and reports on the table. データの性質によっては、データのサイズが 10 倍から 100 倍小さくなる可能性があります。Depending on the nature of your data, the size of your data might be decreased 10x-100x. また、クラスター化列ストア モデルでは、大量のデータを高速で取り込むことができます (一括読み込み)。これは、100,000 行を超えるデータの大きなバッチがディスクに格納される前に圧縮されるためです。Clustered columnstore model also enables fast ingestion of large amount of data (bulk-load) since large batches of data greater than 100K rows are compressed before they are stored on disk. このモデルは、従来のデータ ウェアハウス シナリオに最適です。This model is a good choice for the classic data warehouse scenarios.
  • 非クラスター化列ストア。データは従来の行ストア テーブルに格納され、インデックスは、分析クエリに使用される列ストア形式となります。Non-clustered columnstore where the data is stored in traditional rowstore table and there is an index in the columnstore format that is used for the analytical queries. このモデルではハイブリッド トランザクション分析処理 (HTAP) が可能であり、従来のワークロードでパフォーマンスのリアルタイム分析を実行できます。This model enables Hybrid Transactional-Analytic Processing (HTAP): the ability to run performant real-time analytics on a transactional workload. OLTP クエリは、小さな行セットにアクセスするために最適化されている行ストア テーブルで実行されますが、OLAP クエリは、スキャンと分析により適した選択肢である列ストア インデックスで実行されます。OLTP queries are executed on rowstore table that is optimized for accessing a small set of rows, while OLAP queries are executed on columnstore index that is better choice for scans and analytics. Azure SQL Database クエリ オプティマイザーでは、クエリに基づき、動的に行ストアまたは列ストアを選択します。Azure SQL Database Query optimizer dynamically chooses rowstore or columnstore format based on the query. 非クラスター化列ストア インデックスではデータのサイズは小さくなりません。これは、元のデータセットが変更されずに元の行ストア テーブルで保持されるためです。Non-clustered columnstore indexes don't decrease the size of the data since original data-set is kept in the original rowstore table without any change. しかし、追加の列ストア インデックスのサイズは、同等の B ツリー インデックスより 1 桁小さくする必要があります。However, the size of additional columnstore index should be in order of magnitude smaller than the equivalent B-tree index.

注意

メモリ内列ストア テクノロジでは、メモリでの処理に必要なデータのみが保持されますが、メモリに収まりきらないデータはディスク上に格納されます。In-memory columnstore technology keeps only the data that is needed for processing in the memory, while the data that cannot fit into the memory is stored on-disk. そのため、メモリ内列ストア構造のデータの量が、使用可能なメモリの量を超える場合があります。Therefore, the amount of data in In-memory columnstore structures can exceed the amount of available memory.

テクノロジについての詳細なビデオ:In-depth video about the technology:

列ストア インデックスのデータ サイズとストレージData size and storage for columnstore indexes

列ストア インデックスはメモリに収まる必要がありません。Columnstore indexes aren't required to fit in memory. そのため、インデックス サイズの唯一の上限は、DTU ベースの購入モデルおよび仮想コアベースの購入モデルに関する記事で記述されているデータベース全体の最大サイズです。Therefore, the only cap on the size of the indexes is the maximum overall database size, which is documented in the DTU-based purchasing model and vCore-based purchasing model articles.

クラスター化列ストア インデックスを使用する場合、ベース テーブル ストレージでは列圧縮が使用されます。When you use clustered columnstore indexes, columnar compression is used for the base table storage. この圧縮により、ユーザー データのストレージ フットプリントが大幅に削減されるため、データベースにより多くのデータを格納できます。This compression can significantly reduce the storage footprint of your user data, which means that you can fit more data in the database. これは、列アーカイブ圧縮でさらに拡張できます。And the compression can be further increased with columnar archival compression. 実行できる圧縮の量はデータの性質に依存しますが、10 倍の圧縮は珍しくありません。The amount of compression that you can achieve depends on the nature of the data, but 10 times the compression is not uncommon.

たとえば、最大サイズが 1 テラバイト (TB) のデータベースがあり、列ストア インデックスを使用して 10 倍の比率で圧縮した場合、データベースに合計 10 TB のユーザー データを書き込むことができます。For example, if you have a database with a maximum size of 1 terabyte (TB) and you achieve 10 times the compression by using columnstore indexes, you can fit a total of 10 TB of user data in the database.

非クラスター化列ストア インデックスを使用する場合、ベース テーブルは従来の行ストア形式のままで格納されます。When you use nonclustered columnstore indexes, the base table is still stored in the traditional rowstore format. そのため、ストレージはクラスター化列ストア インデックスほど大きく節約されません。Therefore, the storage savings aren't as big as with clustered columnstore indexes. ただし、多数の従来の非クラスター化インデックスを 1 つの列ストア インデックスに置き換えても、テーブルのストレージ フットプリントにおける節約全体を確認できます。However, if you're replacing a number of traditional nonclustered indexes with a single columnstore index, you can still see an overall savings in the storage footprint for the table.

列ストア インデックスを含むデータベースのサービス レベルの変更Changing service tiers of databases containing Columnstore indexes

ターゲット レベルが S3 より低い場合、Basic または Standard に単一データベースをダウングレードできないことがあります。Downgrading single database to Basic or Standard might not be possible if your target tier is below S3. 列ストア インデックスは Business Critical/Premium 価格レベルと Standard レベル、S3 以上でのみサポートされています。Basic レベルではサポートされません。Columnstore indexes are supported only on the Business Critical/Premium pricing tier and on the Standard tier, S3 and above, and not on the Basic tier. サポートされていないレベルにデータベースをダウングレードすると、列ストア インデックスは使用できなくなります。When you downgrade your database to an unsupported tier or level, your columnstore index becomes unavailable. システムには列ストア インデックスが維持されますが、インデックスは使用されません。The system maintains your columnstore index, but it never leverages the index. 後でサポートされているレベルに戻すと、列ストア インデックスはまたすぐに利用できるようになります。If you later upgrade back to a supported tier or level, your columnstore index is immediately ready to be leveraged again.

クラスター化された列ストア インデックスがある場合、ダウングレード後はテーブル全体が使用できなくなります。If you have a clustered columnstore index, the whole table becomes unavailable after the downgrade. そのため、サポートされていないレベルにデータベースをダウングレードする前に、クラスター化された 列ストア インデックスをすべて削除することをお勧めします。Therefore we recommend that you drop all clustered columnstore indexes before you downgrade your database to an unsupported tier or level.

注意

Managed Instance では、すべてのレベルの列ストア インデックスがサポートされます。Managed Instance supports ColumnStore indexes in all tiers.

次の手順Next steps

その他のリソースAdditional resources

詳細情報Deeper information

アプリケーションの設計Application design

ツールTools