개요 및 사용 시나리오Overview and Usage Scenarios

이 항목 적용 대상: 예SQL Server예Azure SQL 데이터베이스없습니다Azure SQL 데이터 웨어하우스 없습니다 병렬 데이터 웨어하우스THIS TOPIC APPLIES TO: yesSQL ServeryesAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

메모리 내 OLTP는 SQL Server 및 Azure SQL Database에서 트랜잭션 처리, 데이터 수집, 데이터 로드 및 일시적인 데이터 시나리오의 성능을 최적화하기 위해 사용할 수 있는 뛰어난 기술입니다.In-Memory OLTP is the premier technology available in SQL Server and Azure SQL Database for optimizing performance of transaction processing, data ingestion, data load, and transient data scenarios. 이 항목에서는 메모리 내 OLTP의 기술 및 사용 시나리오를 알아봅니다.This topic 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 topic 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 Server와 Azure SQL Database의 메모리 내 OLTP 기술에 대해 설명합니다.This article covers the In-Memory OLTP technology in both SQL Server and Azure SQL Database. 다음 블로그 게시물에서는 Azure SQL Database의 성능 및 리소스 사용률 이점에 대해 자세히 설명합니다.The following blog post contains a deep dive into the performance and resource utilization benefits in Azure SQL Database:

메모리 내 OLTP 개요In-Memory OLTP Overview

메모리 내 OLTP는 올바른 워크로드에 대해 상당한 성능 향상을 제공할 수 있습니다.In-Memory OLTP can provide great performance gains, for the right workloads. 하나의 고객은 SQL Server 2016을 실행하는 단일 컴퓨터에서 메모리 내 OLTP를 사용하여 초당 120만 요청을 달성 하려는 bwin입니다.One customer, bwin, managed to achieve 1.2 Million requests per second with a single machine running SQL Server 2016, leveraging In-Memory OLTP. 또 다른 고객은 Azure SQL Database에서 메모리 내 OLTP를 활용하여 리소스 사용률을 70%로 줄이는 동시에워크로드를 두 배로 늘리려는 Quorum입니다.Another customer, Quorum, managed to double their workload while reducing their resource utilization by 70%, by leveraging In-Memory OLTP in Azure SQL Database. 고객이 일부 경우에 최대 30배의 성능 향상을 얻었지만 워크로드에 따라 정도가 다릅니다.While customers have seen up to 30X performance gain in some cases, how much gain you will 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 Server의 다른 테이블과 동일한 내구성이 보장됩니다. 트랜잭션 커밋의 일부로 모든 변경 내용이 디스크의 트랜잭션 로그에 기록됩니다.By default, all transactions are fully durable, meaning that you have the same durability guarantees you get for any other table in SQL Server: as part of transaction commit, all changes are written to the transaction log on disk. 트랜잭션 커밋 후 언제든 오류가 발생한 경우 데이터베이스가 다시 온라인 상태로 전환되면 데이터가 그대로 유지됩니다.If there is a failure at any time after the transaction commits, your data is there when the database comes back online. 또한 메모리 내 OLTP는 AlwaysOn, 백업/복원 등 SQL Server의 모든 고가용성 및 재해 복구 기능와 함께 작동합니다.In addition, In-Memory OLTP works with all high availability and disaster recovery capabilities of SQL Server, like AlwaysOn, backup/restore, etc.

데이터베이스에서 메모리 내 OLTP를 활용하려면 다음과 같은 유형의 개체 중 하나 이상을 사용합니다.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 Server 및 Azure SQL Database에 기본 제공됩니다.In-Memory OLTP is built into SQL Server and Azure SQL Database. 또한 이러한 개체는 기존 개체와 매우 유사하게 동작하기 때문에 데이터베이스 및 응용 프로그램에 대한 최소한의 변경으로 성능 이점을 얻을 수 있습니다.And because these objects behave very similar to their traditional counterparts, you can often gain performance benefits while making only minimal changes to the database and the application. 뿐만 아니라 메모리 최적화 테이블과 기존 디스크 기반 테이블을 동일한 데이터베이스에서 함께 사용하고 둘 간에 쿼리를 실행할 수 있습니다.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 will find a Transact-SQL script showing an example for each of these types of objects towards the bottom of this topic.

메모리 내 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 사용률을 낮추지 않습니다. 이 시나리오에는 Columnstore 인덱스가 도움이 됩니다.For example, memory-optimized tables will not really 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 really 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 nodes in a cluster, 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 will 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. 메모리 최적화네이티브 컴파일 Advisor를 사용하여 마이그레이션에 대한 도움을 얻습니다.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 really good at ingesting large volumes of data from many different sources at the same time. 또한 다른 대상보다 SQL Server Database로 데이터를 수집하는 데 유용한 경우가 많습니다. SQL은 데이터에 대한 쿼리를 매우 빠르게 실행하고 실시간 통찰력을 제공하기 때문입니다.And it is often beneficial to ingest data into a SQL Server database compared with other destinations, because SQL makes running queries against the data really fast, and allows you to get real-time insights.

일반적인 응용 프로그램 패턴은, 센서 판독값 및 이벤트를 수집하여 알림 및 기록 분석을 지원하는 것입니다.Common application patterns are: Ingesting sensor readings and events, to allow notification, 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

  • 을 수행하는 작업을 사용하여클러스터형 Columnstore 인덱스 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
  • temporal 메모리 최적화 테이블 을 사용하여 기록 데이터를 관리합니다. 이 모드에서는 기록 데이터가 디스크에 있으며, 데이터 이동이 시스템에 의해 관리됩니다.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 Server 샘플 리포지토리에는 temporal 메모리 최적화 테이블, 메모리 최적화 테이블 형식 및 고유하게 컴파일된 저장 프로시저를 사용하여 센서 데이터의 메모리 내 OLTP 저장소 공간을 관리하는 동시에 데이터 수집을 가속화하는 스마트 그리드 응용 프로그램이 포함되어 있습니다.The SQL 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 Server를 사용하여 초당 120만 요청을 달성하려고 했습니다.With SQL 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. 세부 정보: bwin에서 SQL Server 2016 메모리 내 OLTP을 사용하여 전례 없는 성능 및 확장성을 달성하는 방법Details: How bwin is using SQL Server 2016 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) columns. 또는 SQL Server 및 Azure SQL Database에서 JSON 지원 을 사용하여 반구조화된 캐시를 구현할 수 있습니다.Alternatively, you can implement a semi-structured cache with JSON support in SQL Server and Azure SQL Database. 마지막으로, 다양한 데이터 형식 및 제약 조건 등 완전한 관계형 스키마를 사용하여 비영구 테이블을 통해 완전한 관계형 캐시를 만들 수 있습니다.Finally, you can create a full relational cache through non-durable tables with a full relational schema, including various data types and constraints.

GitHub에 게시된 스크립트에서 기본 제공 SQL Server 세션 상태 제공자가 만든 개체를 대체하여 메모리 최적화 ASP.NET 세션 상태를 시작해 보세요.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 Server session state provider:

고객 사례 연구Customer case studies

Tempdb 개체 대체Tempdb object replacement

비영구 테이블 및 메모리 최적화 테이블 형식을 활용하여 기존 tempdb 기반 #temp 테이블, 테이블 변수 및 TVP(테이블 반환 매개 변수)를 대체할 수 있습니다.Leverage non-durable tables and memory-optimized table types to replace your traditional tempdb-based #temp 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을 ON으로 설정하는 것이 좋습니다.In addition, we recommend to use 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: