概要と使用シナリオOverview and Usage Scenarios

適用対象: yesSQL Server yesAzure SQL Database noAzure Synapse Analytics (SQL DW) noParallel Data Warehouse APPLIES TO: yesSQL Server yesAzure SQL Database noAzure Synapse Analytics (SQL DW) noParallel Data Warehouse

インメモリ OLTP は、トランザクション処理のパフォーマンスの最適化、データの取り込み、データの読み込み、および一時的なデータのシナリオに SQL ServerSQL ServerSQL DatabaseSQL Database で使用できる高度な技術です。In-Memory OLTP is the premier technology available in SQL ServerSQL Server and SQL DatabaseSQL Database for optimizing performance of transaction processing, data ingestion, data load, and transient data scenarios. この記事では、インメモリ OLTP のテクノロジと使用シナリオの概要について説明します。This article includes an overview of the technology and outlines usage scenarios for In-Memory OLTP. この情報を参照して、インメモリ OLTP が用途に合っているかどうかを判断してください。Use this information to determine whether In-Memory OLTP is right for your application. この記事の最後には、インメモリ OLTP オブジェクトを表示する例、パフォーマンス デモの参照、次のステップに使用できるリソースの参照を掲載しています。The article concludes with an example that shows In-Memory OLTP objects, reference to a perf demo, and references to resources you can use for next steps.

この記事では、SQL ServerSQL ServerSQL DatabaseSQL Database の両方のインメモリ OLTP テクノロジについて説明します。This article covers the In-Memory OLTP technology in both SQL ServerSQL Server and SQL DatabaseSQL Database. 次のブログ記事では、SQL DatabaseSQL Database でのパフォーマンスとリソース活用における利点について、詳細に説明しています。The following blog post contains a deep dive into the performance and resource utilization benefits in SQL DatabaseSQL Database:

インメモリ OLTP の概要In-Memory OLTP Overview

インメモリ OLTP は、適切なワークロードの場合にパフォーマンスが大きく向上します。In-Memory OLTP can provide great performance gains, for the right workloads. お客様の bwin は、インメモリ OLTP を利用して、SQL Server 2016 (13.x)SQL Server 2016 (13.x) を実行する 1 台のコンピューターで毎秒 120 万要求を達成しました。One customer, bwin, managed to achieve 1.2 Million requests per second with a single machine running SQL Server 2016 (13.x)SQL Server 2016 (13.x), leveraging In-Memory OLTP. また、Quorum は、SQL DatabaseSQL Database でインメモリ OLTP を利用して、リソース使用率を 70% 下げ、ワークロードを 2 倍にしました。Another customer, Quorum, managed to double their workload while reducing their resource utilization by 70%, by leveraging In-Memory OLTP in SQL DatabaseSQL Database. 一部の事例では、最大 30 倍のパフォーマンス向上が見られていますが、向上率はワークロードによって変わります。While customers have seen up to 30X performance gain in some cases, how much gain you see depends on the workload.

それでは、このパフォーマンス向上は何に由来するのでしょうか。Now, where does this performance gain come from? 基本的に、インメモリ OLTP は、データ アクセスとトランザクションの実行を効率化し、同時に実行されるトランザクション間のロックとラッチの競合を取り除くことで、トランザクション プロセスのパフォーマンスを改善します。高速化の理由はデータがメモリ内にあるからではなく、メモリ内のデータを中心にして最適化しているためです。In essence, In-Memory OLTP improves performance of transaction processing by making data access and transaction execution more efficient, and by removing lock and latch contention between concurrently executing transactions: it is not fast because it is in-memory; it is fast because it is optimized around the data being in-memory. メモリ内のコンカレンシー処理が多い計算に関する最新の機能強化を利用するように、データ ストレージ、アクセス、処理アルゴリズムはゼロから再設計されました。Data storage, access, and processing algorithms were redesigned from the ground up to take advantage of the latest enhancements in in-memory and high concurrency computing.

現在では、データがメモリ内にあるからというだけで、障害が発生したときにデータが失われることを意味しなくなりました。Now, just because data lives in-memory does not mean you lose it when there is a failure. 既定で、すべてのトランザクションは完全に持続可能になりました。つまり、SQL ServerSQL Server の他のテーブルと同じ持続可能性の保証があります。トランザクション コミットの一部として、すべての変更はディスク上のトランザクション ログに書き込まれます。By default, all transactions are fully durable, meaning that you have the same durability guarantees you get for any other table in SQL ServerSQL Server: as part of transaction commit, all changes are written to the transaction logon disk. トランザクション コミット後のどこかの時点で障害が発生すると、データベースがオンラインに戻ったときに、コミットされたデータを利用できます。If there is a failure at any time after the transaction commits, your data is there when the database comes back online. さらに、インメモリ OLTP は、SQL ServerSQL Server の高可用性とディザスター リカバリー機能 (AlwaysOn、バックアップ/復元など) と連携します。In addition, In-Memory OLTP works with all high availability and disaster recovery capabilities of SQL ServerSQL Server, like Always On, backup/restore, etc.

データベースでインメモリ OLTP を利用するには、次に示すオブジェクトの種類から 1 つまたは複数使用します。To leverage In-Memory OLTP in your database, you use one or more of the following types of objects:

  • メモリ最適化テーブル は、ユーザー データの格納に使用されます。Memory-optimized tables are used for storing user data. テーブルは、作成時にメモリが最適化されるように宣言します。You declare a table to be memory-optimized at create time.
  • 非持続的テーブル は、キャッシュまたは中間の結果セット用の一時的なデータに使用されます (従来の一時テーブルは置き換えられます)。Non-durable tables are used for transient data, either for caching or for intermediate result set (replacing traditional temp tables). 非持続的テーブルは、DURABILITY=SCHEMA_ONLY を使用して宣言されるメモリ最適化テーブルです。つまり、これらのテーブルを変更しても、IO は発生しません。A non-durable table is a memory-optimized table that is declared with DURABILITY=SCHEMA_ONLY, meaning that changes to these tables do not incur any IO. そのため、持続性が重要ではない場合、ログ IO リソースの消費を回避することができます。This avoids consuming log IO resources for cases where durability is not a concern.
  • メモリ最適化テーブル型 は、テーブル値パラメーター (TVP) だけでなく、ストアド プロシージャの中間結果セットにも使用されます。Memory-optimized table types are used for table-valued parameters (TVPs), as well as intermediate result sets in stored procedures. メモリ最適化テーブル型は、従来のテーブル型の代わりに使用できます。These can be used instead of traditional table types. メモリ最適化テーブル型を使用して宣言したテーブル変数と TVP は、非持続的メモリ最適化テーブルの利点 (効率的なデータ アクセス、IO なし) を継承します。Table variables and TVPs that are declared using a memory-optimized table type inherit the benefits of non-durable memory-optimized tables: efficient data access, and no IO.
  • ネイティブ コンパイル T-SQL モジュール は、操作の処理に必要な CPU サイクルを減らして、個々のトランザクションにかかる時間をさらに短縮するために使用されます。Natively compiled T-SQL modules are used to further reduce the time taken for an individual transaction by reducing CPU cycles required to process the operations. Transact-SQL モジュールは、作成時にネイティブでコンパイルするように宣言します。You declare a Transact-SQL module to be natively compiled at create time. このとき、ストアド プロシージャ、トリガー、スカラー ユーザー定義関数という T-SQL モジュールをネイティブでコンパイルできます。At this time, the following T-SQL modules can be natively compiled: stored procedures, triggers, and scalar user-defined functions.

インメモリ OLTP は SQL ServerSQL ServerSQL DatabaseSQL Database に組み込まれています。In-Memory OLTP is built into SQL ServerSQL Server and SQL DatabaseSQL Database. また、これらのオブジェクトは、従来の対応するオブジェクトに似た動作なので、多くの場合、データベースとアプリケーションの変更を最小限に抑えながら、パフォーマンスを向上できます。And because these objects behave similar to their traditional counterparts, you can often gain performance benefits while making only minimal changes to the database and the application. さらに、同じデータベースにメモリ最適化テーブルと従来のディスクベースのテーブルの両方を持ち、2 つのテーブルに対してクエリを実行することができます。Plus, you can have both memory-optimized and traditional disk-based tables in the same database, and run queries across the two. この記事の末尾には、これらの種類の各オブジェクトについて、Transact-SQL スクリプト例を掲載しています。You find a Transact-SQL script showing an example for each of these types of objects towards the bottom of this article.

インメモリ OLTP の使用シナリオUsage Scenarios for In-Memory OLTP

インメモリ OLTP は魔法の高速化ボタンではなく、あらゆるワークロードに適しているわけではありません。In-Memory OLTP is not a magic go-fast button, and is not suitable for all workloads. たとえば、ほとんどのクエリが広範囲に及ぶデータに対する集計を行う場合、メモリ最適化テーブルで CPU 使用率は下がりません。このようなシナリオには、列ストア インデックスが役立ちます。For example, memory-optimized tables don't bring down your CPU utilization if most of the queries are performing aggregation over large ranges of data - Columnstore indexes help with that scenario.

次に、お客様がインメモリ OLTP で成功したシナリオとアプリケーション パターンの一覧を紹介します。Here is a list of scenarios and application patterns where we have seen customers be successful with In-Memory OLTP.

高スループット、低遅延トランザクションの処理High-throughput and low-latency transaction processing

これはインメモリ OLTP を構築する中核となるシナリオです。個々のトランザクションの低遅延を保ちながら、大量のトランザクションに対応します。This is the core scenario for which we built In-Memory OLTP: support large volumes of transactions, with consistent low latency for individual transactions.

一般的なワークロード シナリオとして、金融商品の取引、スポーツくじ、モバイル ゲーム、広告配信などがあります。Common workload scenarios are: trading of financial instruments, sports betting, mobile gaming, and ad delivery. また、一般的なパターンとして、読み取りや更新が頻繁な "カタログ" もあります。Another common pattern we've seen is a "catalog" that is frequently read and/or updated. たとえば、大きなファイルが複数ある場合、各ファイルは複数のクラスター ノードに分散され、メモリ最適化テーブル内にある各ファイルの各シャードの場所を分類します。One example is where you have large files, each distributed over a number of cluster nodes, and you catalog the location of each shard of each file in a memory-optimized table.

実装に関する注意点Implementation considerations

中核となるトランザクション テーブル (つまり、最もパフォーマンスが重要なトランザクションがあるテーブル) にメモリ最適化テーブルを使用します。Use memory-optimized tables for your core transaction tables, i.e., the tables with the most performance-critical transactions. ネイティブでコンパイルされたストアド プロシージャを使用して、ビジネス トランザクションに関連付けられたロジックの実行を最適化します。Use natively compiled stored procedures to optimize execution of the logic associated with the business transaction. データベースのストアド プロシージャに組み込むことができるロジック数が多いほど、インメモリ OLTP の利点も大きくなります。The more of the logic you can push down into stored procedures in the database, the more benefit you see from In-Memory OLTP.

既存のアプリケーションで開始するには:To get started in an existing application:

  1. トランザクション パフォーマンス分析レポート を使用して移行するオブジェクトを特定し、use the transaction performance analysis report to identify the objects you want to migrate,
  2. 移行に メモリ最適化 および ネイティブ コンパイル アドバイザーを利用します。and use the memory-optimization and native compilation advisors to help with migration.

お客様の導入事例Customer Case Studies

IoT (モノのインターネット) などのデータ統合Data ingestion, including IoT (Internet-of-Things)

インメモリ OLTP は、同時にさまざまなソースから大量のデータを取り込む処理が特に得意です。In-Memory OLTP is good at ingesting large volumes of data from many different sources at the same time. また、多くの場合、他の取り込み先と比較して、SQL ServerSQL Server データベースにデータを取り込む方が利点があります。これは、SQL ServerSQL Server ではデータに対するクエリの実行速度が速く、リアルタイムで洞察できるためです。And it is often beneficial to ingest data into a SQL ServerSQL Server database compared with other destinations, because SQL ServerSQL Server makes running queries against the data fast, and allows you to get real-time insights.

一般的なアプリケーション パターン:Common application patterns are:

  • センサーの読み取りとイベントを取り込みます。通知だけでなく履歴分析を可能にします。Ingesting sensor readings and events, and allow notifications as well as historical analysis.
  • 複数のソースからでも、一括更新を管理し、同時読み取りのワークロードに対する影響を最小限に抑えることができます。Managing batch updates, even from multiple sources, while minimizing the impact on the concurrent read workload.

実装に関する注意点Implementation considerations

データの取り込みにメモリ最適化テーブルを使用します。Use a memory-optimized table for the data ingestion. 取り込みの大部分が (更新ではなく) 挿入で構成され、データのインメモリ OLTP ストレージの占有領域が重要な場合、次のいずれかを行います。If the ingestion consists mostly of inserts (rather than updates) and In-Memory OLTP storage footprint of the data is a concern, either

  • を実行するジョブを使用して、クラスター化列ストア インデックス INSERT INTO <disk-based table> SELECT FROM <memory-optimized table>が指定されたディスクベースのテーブルに定期的にデータを一括オフロードします。または、Use a job to regularly batch-offload data to a disk-based table with a Clustered Columnstore index, using a job that does INSERT INTO <disk-based table> SELECT FROM <memory-optimized table>; or
  • 一時メモリ最適化テーブルを使用して、履歴データを管理します。このモードでは、履歴データはディスクに保存され、データの移動はシステムによって管理されます。Use a temporal memory-optimized table to manage historical data - in this mode, historical data lives on disk, and data movement is managed by the system.

SQL ServerSQL Server サンプル リポジトリに一時メモリ最適化テーブル、メモリ最適化テーブル型、およびネイティブ コンパイル ストアド プロシージャを使用するスマート グリッド アプリケーション含めることでデータの取り込みを高速化し、センサー データのインメモリ OLTP ストレージの占有領域を管理しています。The SQL ServerSQL Server samples repository contains a smart grid application that uses a temporal memory-optimized table, a memory-optimized table type, and a natively compiled stored procedure, to speed up data ingestion, while managing the In-Memory OLTP storage footprint of the sensor data:

お客様の導入事例Customer Case Studies

キャッシュとセッションの状態Caching and session state

インメモリ OLTP テクノロジは、SQL でセッションの状態 (ASP.NET アプリケーションの状態など) を維持する場合におよびキャッシュの場合に特に推奨されます。The In-Memory OLTP technology makes SQL really attractive for maintaining session state (e.g., for an ASP.NET application) and for caching.

ASP.NET セッションの状態は、インメモリ OLTP で特に成功している使用事例です。ASP.NET session state is a very successful use case for In-Memory OLTP. SQL ServerSQL Server では、あるお客様が毎秒約 120 万要求を達成しました。With SQL ServerSQL Server, one customer was about to achieve 1.2 Million requests per second. 一方、社内のすべての中間層アプリケーションのキャッシュ ニーズにインメモリ OLTP を使用し始めました。In the meantime, they have started using In-Memory OLTP for the caching needs of all mid-tier applications in the enterprise. 詳細:How bwin is using SQL Server 2016 (13.x)SQL Server 2016 (13.x) In-Memory OLTP to achieve unprecedented performance and scale (bwin がインメモリ OLTP を使用して前例のないパフォーマンスとスケールを達成している方法)Details: How bwin is using SQL Server 2016 (13.x)SQL Server 2016 (13.x) In-Memory OLTP to achieve unprecedented performance and scale

実装に関する注意点Implementation considerations

varbinary(max) 列に BLOB を格納することで、簡易なキーと値のストアとして非持続的メモリ最適化テーブルを使用できます。You can use non-durable memory-optimized tables as a simple key-value store by storing a BLOB in a varbinary(max) column. または、SQL ServerSQL ServerSQL DatabaseSQL DatabaseJSON のサポートで半構造化キャッシュを実装できます。Alternatively, you can implement a semi-structured cache with JSON support in SQL ServerSQL Server and SQL DatabaseSQL Database. 最後に、多様なデータ型と制約を含み、完全なリレーショナル スキーマを使用する非持続的なテーブルで、完全なリレーショナル キャッシュを作成できます。Finally, you can create a full relational cache through non-durable tables with a full relational schema, including various data types and constraints.

ASP.NET セッションの状態のメモリ最適化を始めるには、GitHub で公開されているスクリプトを利用して、組み込みの SQL ServerSQL Server セッションの状態プロバイダーで作成されるオブジェクトを置き換えます。Get started with memory-optimizing ASP.NET session state by leveraging the scripts published on GitHub to replace the objects created by the built-in SQL ServerSQL Server session state provider:

お客様の導入事例Customer case studies

tempdb オブジェクトの置き換えTempdb object replacement

非持続的テーブルとメモリ最適化テーブル型を利用して、一時テーブル、テーブル変数、テーブル値パラメーター (TVP) など、従来の TempDB ベース構造を置き換えます。Leverage non-durable tables and memory-optimized table types to replace your traditional TempDB based structures, such as temporary tables, table variables, and table-valued parameters (TVPs).

メモリ最適化テーブル変数と非持続的テーブルは、従来のテーブル変数と #temp テーブルと比較すると、一般的に CPU が減り、ログの IO が完全になくなります。Memory-optimized table variables and non-durable tables typically reduce CPU and completely remove log IO, when compared with traditional table variables and #temp table.

実装に関する注意点Implementation considerations

最初に参照してください:メモリ最適化を使用した一時テーブルとテーブル変数のパフォーマンスの向上。To get started see: Improving temp table and table variable performance using memory optimization.

お客様の導入事例Customer Case Studies

ETL (抽出、変換、読み込み)ETL (Extract Transform Load)

多くの場合、ETL ワークフローには、データのステージング テーブルへの読み込み、データの変換、最終的なテーブルへの読み込みが含まれています。ETL workflows often include load of data into a staging table, transformations of the data, and load into the final tables.

実装に関する注意点Implementation considerations

データのステージングには非持続的メモリ最適化テーブルを使用します。Use non-durable memory-optimized tables for the data staging. すべての IO が完全になくなり、データ アクセスがより効率的になります。They completely remove all IO, and make data access more efficient.

ワークフローの一部としてステージング テーブルで変換を実行する場合、ネイティブ コンパイル ストアド プロシージャを使用すると、変換を高速化できます。If you perform transformations on the staging table as part of the workflow, you can use natively compiled stored procedures to speed up these transformations. このような変換を並列して実行できると、メモリ最適化からさらにスケール メリットが得られます。If you can do these transformations in parallel you get additional scaling benefits from the memory-optimization.

サンプル スクリプトSample Script

インメモリ OLTP の使用を開始する前に、MEMORY_OPTIMIZED_DATA ファイルグループを作成する必要があります。Before you can start using In-Memory OLTP, you need to create a MEMORY_OPTIMIZED_DATA filegroup. さらに、データベース互換性レベル 130 (以上) を使用し、データベース オプション MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT をオンに設定することをお勧めします。In addition, we recommend using database compatibility level 130 (or higher), and set the database option MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT to ON.

次の場所のスクリプトを使用して、既定のデータ フォルダーにファイルグループを作成し、推奨される設定を構成できます。You can use the script at the following location to create the filegroup in the default data folder, and configure the recommended settings:

次に、データベースで作成できるインメモリ OLTP オブジェクトを説明するためのスクリプトを示します。The following script illustrates In-Memory OLTP objects you can create in your database:

-- configure recommended DB option
ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT=ON
GO
-- memory-optimized table
CREATE TABLE dbo.table1
( c1 INT IDENTITY PRIMARY KEY NONCLUSTERED,
  c2 NVARCHAR(MAX))
WITH (MEMORY_OPTIMIZED=ON)
GO
-- non-durable table
CREATE TABLE dbo.temp_table1
( c1 INT IDENTITY PRIMARY KEY NONCLUSTERED,
  c2 NVARCHAR(MAX))
WITH (MEMORY_OPTIMIZED=ON,
      DURABILITY=SCHEMA_ONLY)
GO
-- memory-optimized table type
CREATE TYPE dbo.tt_table1 AS TABLE
( c1 INT IDENTITY,
  c2 NVARCHAR(MAX),
  is_transient BIT NOT NULL DEFAULT (0),
  INDEX ix_c1 HASH (c1) WITH (BUCKET_COUNT=1024))
WITH (MEMORY_OPTIMIZED=ON)
GO
-- natively compiled stored procedure
CREATE PROCEDURE dbo.usp_ingest_table1
  @table1 dbo.tt_table1 READONLY
WITH NATIVE_COMPILATION, SCHEMABINDING
AS
BEGIN ATOMIC
    WITH (TRANSACTION ISOLATION LEVEL=SNAPSHOT,
          LANGUAGE=N'us_english')

  DECLARE @i INT = 1

  WHILE @i > 0
  BEGIN
    INSERT dbo.table1
    SELECT c2
    FROM @table1
    WHERE c1 = @i AND is_transient=0

    IF @@ROWCOUNT > 0
      SET @i += 1
    ELSE
    BEGIN
      INSERT dbo.temp_table1
      SELECT c2
      FROM @table1
      WHERE c1 = @i AND is_transient=1

      IF @@ROWCOUNT > 0
        SET @i += 1
      ELSE
        SET @i = 0
    END
  END

END
GO
-- sample execution of the proc
DECLARE @table1 dbo.tt_table1
INSERT @table1 (c2, is_transient) VALUES (N'sample durable', 0)
INSERT @table1 (c2, is_transient) VALUES (N'sample non-durable', 1)
EXECUTE dbo.usp_ingest_table1 @table1=@table1
SELECT c1, c2 from dbo.table1
SELECT c1, c2 from dbo.temp_table1
GO

詳細情報:Resources to learn more:

Transact-SQL のパフォーマンスを向上させるインメモリ OLTP テクノロジ In-Memory OLTP Technologies for Faster T-SQL Performance
インメモリ OLTP を使用したパフォーマンス デモ: in-memory-oltp-perf-demo-v1.0 Perf demo using In-Memory OLTP can be found at: in-memory-oltp-perf-demo-v1.0
インメモリ OLTP の説明とデモを紹介する 17 分のビデオ17-minute video explaining In-Memory OLTP and showing the demo
インメモリ OLTP を有効にして推奨されるオプションを設定するスクリプト Script to enable In-Memory OLTP and set recommended options
主なインメモリ OLTP ドキュメント Main In-Memory OLTP documentation
インメモリ OLTP が Azure SQL Database のパフォーマンスとリソース活用にもたらす利点Performance and resource utilization benefits of In-Memory OLTP in Azure SQL Database
メモリ最適化を使用した一時テーブルとテーブル変数のパフォーマンスの向上 Improving temp table and table variable performance using memory optimization
SQL データベースでのインメモリ テクノロジを使用したパフォーマンスの最適化Optimize Performance using In-Memory Technologies in SQL Database
メモリ最適化テーブルでのシステム バージョン管理されたテンポラル テーブルSystem-Versioned Temporal Tables with Memory-Optimized Tables
インメモリ OLTP - 一般的なワークロード パターンと移行に関する考慮事項In-Memory OLTP - Common Workload Patterns and Migration Considerations.