[SQL Server] In-Memory OLTP

SQL Server의 In-Memory OLTP 기능에 대한 소개와 간단한 성능 테스트 했던 내용을 공유 합니다. SQL Server 2014 버전에서 진행했던 내용으로 이후 버전에서는 변경된 부분이 있을 수 있습니다.

 

In-Memory OLTP 기능은 SQL Server 2014버전에서 Enterprise와 Developer에디션에서만 사용 가능합니다.
SQL Server 2016 SP1 이후부터는 Standarad 에디션에서도 사용할 수 있도록 변경 되었습니다.

1. SQL Server In-Memory OLTP 란?

1) 개념

자주 사용하는 테이블 전체를 메모리에 올려서 2~30배의 트랜잭션 처리 성능 향상을 얻을 수 있는 기능입니다.

2) 특징

가. 메모리 최적화 테이블

기존 디스크 기반 테이블은 8KB 크기의 페이지와 페이지들의 모임인 익스텐트로 구성됩니다.

이에 반해 메모리 최적화 테이블은 개별 행 단위로 존재하며 아래와 같은 특징을 지닙니다.

  • 같은 행이 여러 버전으로 존재하는 multi-versioning 구조
  • 각 행들은 타임 스탬프와 포인터 열을 보유
  • 타임 스탬프는 행의 유효성을 검사 하는데 사용되고 Commit 시에 유효성 검사를 수행
  • 포인터 열을 통해 같은 행의 여러 버전들이 연결됨

나. NO Lock & NO Latch

위에서 말한 메모리 최적화 테이블의 특징으로 인해 Lock과 Latch가 없어 동시성이 향상 됩니다. Lock은 동시 트랜잭션을 제어하기 위한 기술이고 Latch는 데이터 정합성을 보장하기 위해 SQL Server 내부적으로 사용하는 개체입니다. 개별 행으로 존재하기 때문에 충돌이 발생할 확률이 극히 낮아지고 심지어 multi-versioning 구조로 같은 행에 대한 충돌도 발생하지 않습니다.

Lock과 Latch가 없는 방식 덕분에 스레드의 수를 증가시켰을 때 성능향상이 linear하게 증가합니다. 그에 반해 디스크 기반 테이블에서는 스레드의  수가 증가한다 한들 테이블이 병목구조가 되어 성능향상에 한계가 있습니다.

3) 사용법

CREATE TABLE [dbo].[ReservationDetail]
(
    [ReservationID] [bigint] NOT NULL,
    [ReservationDetailID] [bigint] IDENTITY(1,1) NOT NULL,
    [Quantity] [int] NOT NULL,
    [Comment] [nvarchar](1000) NULL,

CONSTRAINT [PK_ReservationDetail] PRIMARY KEY NONCLUSTERED
(
    [ReservationDetailID] ASC
)
)WITH ( MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA)

GO   
  • 기존 테이블 생성 구문 뒤에 인덱스 생성(필수), 옵션 설정문 추가합니다.
  • 인덱스 : Hash, Non Clustered, Columnstore 인덱스만 가능
  • Durabliity
    • SCHEMA_AND_DATA : 주기적인 DISK 쓰기로 시스템 FAILURE 시에 메모리에 있던 데이터 복구가능. 디스크로부터의 read는 오직 재부팅시에만 발생
    • SCHEMA_ONLY : 시스템 FAILURE 시에 메모리에 있던 데이터 복구 불가능. 대신 DISK I/O가 없으므로 성능 극단적으로 향상
      (데이터 손실이 상관없는 특수한 경우에 사용)

2. SQL Server In-Memory 성능 테스트

마이크로소프트에서 제공한 In-memory OLTP 성능 테스트 demo 프로그램을 사용하여 진행하였습니다.
(출처 : https://github.com/Microsoft/sql-server-samples/releases/tag/in-memory-oltp-demo-v1.0)

 

테스트 방법 : 기존 디스크 기반의 테이블, 프로시저와 같은 데이터를 가지는 메모리 최적화된 테이블, Natively compiled 프로시저를 사용하여 초당 처리하는 트랜잭션 수를 비교

1) 테스트 서버 사양

  • 프로세서 : 2 core (1차) -> 8 core (2차~)
  • 메모리 : 8GB -> 32GB(2차~)
  • 디스크 : 50GB x 2
  • OS : Windows Server 2012 R2 Standard
  • DB : SQL Server 2014 Developer
  • 기본 트랜잭션 환경 설정 :

2) 테스트

  • HW 스펙 향상 후 테스트(2 core -> 8core, 8GB -> 32GB)
  • 트랜잭션 설정 변경 후 테스트

- 트랜잭션 별 로우 수 10 -> 100

- 쓰기당 읽기 수 1 -> 10

- ALTER DATABASE CURRENT SET DELAYED_DURABILITY = FORCED 설정 변경

  • DELAYED_DURABILITY = FOCED
  • 모든 COMMIT된 트랜잭션이 DELAYED DURABLE이 됨
    • Delayed Durable : 트랜잭션 로그를 버퍼에 쌓고 버퍼가 가득차거나 버퍼 쓰기 이벤트가 발생할 때 디스크에 기록하여 디스크I/O를 감소시킴

3) 결과

가. Core 수가 부족하면 큰 성능향상 얻지 못함

  • (2core일 때 2배 -> 8core일 때 6배 성능 향상)

나. 트랜잭션 별 행 수가 클 때 21배의 성능 향상

  • 대량 데이터를 읽고 쓰는 트랜잭션에 적합

다. 쓰기당 읽기 수를 1 -> 10 늘리자 성능 향상 1~2배

  • 읽기 보다는 쓰기 위주의 트랜잭션에서 성능 향상 높음

라. DELAYED_DURABILITY = FOCED 옵션 설정으로 6배 -> 8배로 성능 향상

  • 트랜잭션 로그 디스크 I/O를 감소시키기 때문. 대신 장애 발생 시에 데이터 손실 가능성 있음.

'DB > SQL Server' 카테고리의 다른 글

[SQL Server] 설치  (0) 2020.06.08