SQL Database에서 메모리 내 기술을 사용하여 성능 최적화

  • 아티클

적용 대상:Azure SQL Database

메모리 내 기술을 사용하면 애플리케이션의 성능을 향상시키고, 데이터베이스의 비용 감소가 예상됩니다.

메모리 내 기술을 사용하는 경우

메모리 내 기술을 사용하여 다양한 워크로드에서 성능을 개선할 수 있습니다.

  • 트랜잭션(OLTP(온라인 트랜잭션 처리)). 여기서 대부분의 요청은 작은 데이터 집합을 읽거나 업데이트합니다(예: CRUD(생성, 읽기, 업데이트, 삭제) 작업).
  • 분석(OLAP(온라인 분석 처리)). 여기서 대부분의 쿼리는 보고 목적으로 복잡한 계산을 수행하고 부하 또는 대량 로드 작업을 수행하거나 기존 테이블에 데이터 변경 내용을 기록하는 정기적으로 예약된 프로세스도 포함합니다. 종종 OLAP 워크로드는 OLTP 워크로드에서 주기적으로 업데이트되곤 합니다.
  • 혼합(HTAP(하이브리드 트랜잭션/분석 처리)) 여기서 두 OLTP 및 OLAP 쿼리는 동일한 데이터 세트에서 실행됩니다.

메모리 내 기술은 쿼리의 네이티브 컴파일 또는 기본 하드웨어에서 사용할 수 있는 일괄 처리와 SIMD 명령과 같은 고급 처리를 사용하여 메모리로 처리해야 하는 데이터를 유지함으로써 이러한 워크로드의 성능을 개선할 수 있습니다.

개요

Azure SQL Database는 다음과 같은 메모리 내 기술을 지원합니다.

  • 메모리 내 OLTP는 초당 트랜잭션의 수를 증가시키고 트랜잭션 처리에 대한 대기 시간을 감소시킵니다. 메모리 내 OLTP의 혜택에 해당하는 시나리오: 거래 및 게임, 이벤트 또는 IoT 디바이스에서 데이터 수집, 캐싱, 데이터 로드, 임시 테이블 과 테이블 변수 시나리오와 같은 처리량이 높은 트랜잭션 처리.
  • 클러스터형 columnstore 인덱스는 스토리지 공간을 줄이고(최대 10배) 보고 및 분석 쿼리 성능을 개선합니다. 데이터베이스에 있는 더 많은 데이터에 적합한 데이터 마트에서 팩트 테이블과 함께 이 기능을 사용하여 성능을 개선할 수 있습니다. 또한 운영 데이터베이스에서 보관할 기록 데이터와 함께 사용하여 최대 10배 더 많은 데이터를 쿼리할 수 있습니다.
  • HTAP에 대한 비클러스터형 columnstore 인덱스를 사용하면 비용이 많이 드는 ETL(추출, 변환 및 로드) 프로세스를 실행하고 데이터 웨어하우스가 채워질 때까지 기다릴 필요 없이 운영 데이터베이스를 직접 쿼리하여 비즈니스에 대한 실시간 인사이트를 얻을 수 있습니다. 비클러스터형 Columnstore 인덱스를 사용하면 운영 워크로드에 미치는 영향을 줄이는 동시에 OLTP 데이터베이스에 대한 분석 쿼리를 빠르게 실행할 수 있습니다.
  • HTAP에 대한 메모리 최적화 클러스터형 columnstore 인덱스를 사용하면 트랜잭션 처리를 빠르게 수행하고 동일한 데이터에서 분석 쿼리를 매우 신속하게 동시 실행할 수 있습니다.

Columnstore 인덱스와 메모리 내 OLTP는 각각 2012년과 2014년에 SQL Server에 도입되었습니다. Azure SQL Database, Azure SQL Managed Instance 및 SQL Server는 모두 동일한 메모리 내 기술을 구현합니다.

참고 항목

AdventureWorksLT 샘플 데이터베이스 및 ostress.exe를 사용하여 메모리 내 OLTP 기술의 성능 이점을 보여주는 자세한 단계별 자습서는 Azure SQL Database의 메모리 내 샘플을 참조하세요.

메모리 내 기술의 혜택

보다 효율적인 쿼리 및 트랜잭션 처리로 인해 메모리 내 기술은 비용을 절감하는 데도 도움이 됩니다. 일반적으로 성능 개선을 위해 데이터베이스의 가격 책정 계층을 업그레이드할 필요가 없습니다. 경우에 따라 메모리 내 기술로 성능을 개선하면서 가격 책정 계층을 줄일 수도 있습니다.

쿼럼 비즈니스 솔루션은 메모리 내 OLTP를 사용하여 워크로드를 두 배로 늘리면서 DTU를 70% 개선할 수 있습니다. 자세한 내용은 Azure SQL Database의 메모리 내 OLTP를 참조하세요.

참고 항목

메모리 내 기술은 Azure SQL Database의 프리미엄 및 중요 비즈니스용 계층에서 제공됩니다.

이 문서에서는 Azure SQL Database 전용 메모리 내 OLTP 및 columnstore 인덱스의 측면을 설명하며, 다음과 같은 샘플도 제공합니다.

  • 여기서는 데이터 크기 제한과 스토리지에 대한 이와 같은 기술의 영향에 대해 알아봅니다.
  • 다양한 가격 책정 계층 사이에서 이러한 기술을 사용하는 데이터베이스의 이동을 관리하는 방법을 알아보세요.
  • 또한 columnstore 인덱스뿐만 아니라 메모리 내 OLTP의 사용을 보여 주는 두 개의 샘플이 표시됩니다.

SQL Server에서 메모리 내 기능에 대한 자세한 내용은 다음을 참조하세요.

메모리 내 OLTP

메모리 내 OLTP 기술은 메모리에 모든 데이터를 유지하여 매우 빠른 데이터 액세스 작업을 제공합니다. 또한 특수한 인덱스, 쿼리의 네이티브 컴파일 및 래치 없는 데이터 액세스를 사용하여 OLTP 워크로드의 성능을 개선합니다. 메모리 내 OLTP 데이터를 구성하는 방법에는 두 가지가 있습니다.

  • 모든 행이 별도의 메모리 개체인 메모리 최적화 rowstore 형식. 고성능 OLTP 워크로드에 최적화된 클래식 메모리 내 OLTP 형식입니다. 메모리 최적화 rowstore 형식으로 사용할 수 있는 두 가지 유형의 메모리 최적화 테이블이 있습니다.

    • 서버를 다시 시작한 후 메모리에 행이 배치되는 지속성 테이블(SCHEMA_AND_DATA). 이 유형의 테이블은 기존 rowstore 테이블처럼 동작하면서 메모리 내 최적화의 추가적인 혜택을 제공합니다.
    • 비지속형 테이블(SCEMA_ONLY). 여기서 행은 다시 시작된 후 유지되지 않습니다. 이 유형의 테이블은 임시 데이터(예: 임시 테이블 교체) 또는 데이터를 일부 지속형 테이블(준비 테이블이라고 함)로 이동하기 전에 신속하게 로드해야 하는 테이블을 위해 설계되었습니다.

  • 데이터가 열 형식으로 구성된 메모리 최적화 columnstore 형식. 이 구조는 OLTP 워크로드가 실행되는 동일한 데이터 구조에서 분석 쿼리를 실행해야 하는 HTAP 시나리오를 위해 설계되었습니다.

참고 항목

메모리 내 OLTP 기술은 완전히 메모리에 상주할 수 있는 데이터 구조를 위해 설계되었습니다. 메모리 내 데이터를 디스크로 오프로드할 수 없으므로 메모리가 충분한 데이터베이스를 사용하고 있는지 확인합니다. 자세한 내용은 메모리 내 OLTP의 데이터 크기 및 스토리지 최대값을 참조하세요.

메모리 내 OLTP의 데이터 크기 및 스토리지 최대값

메모리 내 OLTP는 사용자 데이터를 저장하는 데 사용되는 메모리 최적화 테이블을 포함합니다. 이러한 테이블은 메모리에 맞게 지정해야 합니다. SQL Database에서 직접 메모리를 관리하기 때문에 사용자 데이터에 대한 할당량의 개념이 있습니다. 이 아이디어를 메모리 내 OLTP 스토리지라고 합니다.

지원되는 단일 데이터베이스 가격 책정 계층 및 탄력적 풀 가격 책정 계층은 각각 일정량의 메모리 내 OLTP 스토리지를 포함합니다.

메모리 내 OLTP 스토리지 제한 계산 시 포함되는 항목은 다음과 같습니다.

  • 메모리 최적화 테이블 및 테이블 변수의 활성 사용자 데이터 행. 이전 행 버전은 최대값 계산에 포함되지 않습니다.
  • 메모리 최적화 테이블에 대한 인덱스입니다.
  • ALTER TABLE 작업의 운영 오버헤드.

제한에 도달한 경우 할당량 초과 오류가 표시되고 더 이상 데이터를 삽입하거나 업데이트할 수 없습니다. 이 오류를 완화하려면 데이터를 삭제하거나 데이터베이스 또는 풀의 가격 책정 계층을 늘립니다.

제한에 도달한 경우 메모리 내 OLTP 스토리지 사용률을 모니터링하고 경고를 구성하는 방법에 대한 자세한 내용은 메모리 내 스토리지 모니터링을 참조하세요.

탄력적 풀에 대한 정보

탄력적 풀을 사용하면 메모리 내 OLTP 스토리지가 풀의 모든 데이터베이스에서 공유됩니다. 따라서 한 데이터베이스의 사용량은 다른 데이터베이스에 영향을 줄 수 있습니다. 이에 대한 두 가지 완화는 다음과 같습니다.

  • 데이터베이스에서 전반적으로 풀의 eDTU 또는 vCore 수보다 낮게 Max-eDTU 또는 MaxvCore를 구성합니다. 이 최대값은 그러면 풀에 있는 모든 데이터베이스에서 메모리 내 OLTP 스토리지 사용률을 eDTU 수에 해당하는 크기로 제한합니다.
  • 0보다 큰 값으로 Min-eDTU 또는 MinvCore를 구성합니다. 이 최소값은 풀에 있는 데이터베이스 각각에 구성된 Min-eDTU 또는 vCore에 해당하는 사용 가능한 메모리 내 OLTP 스토리지의 양을 보장합니다.

메모리 내 OLTP 기술을 사용하는 데이터베이스의 서비스 계층 변경

데이터베이스를 범용(vCore)에서 중요 비즈니스용 또는 표준(DTU)에서 프리미엄과 같이 항상 더 높은 계층으로 업그레이드할 수 있습니다. 사용 가능한 기능 및 리소스만 증가합니다.

그러나 계층을 다운그레이드하면 데이터베이스 성능이 저하될 수 있습니다. 데이터베이스에 메모리 내 OLTP 개체가 포함되어 있을 때 중요 비즈니스용에서 범용(또는 프리미엄에서 표준이나 기본)으로 다운그레이드하면 성능 저하 현상이 특히 뚜렷하게 나타납니다. 데이터베이스에서 메모리 내 개체를 쉽게 찾을 수 있습니다.

메모리 최적화 테이블은 계속 표시되더라도 다운그레이드 후에 사용할 수 없는 상태가 됩니다. 탄력적 풀의 가격 책정 계층을 낮추거나 메모리 내 기술을 포함한 데이터베이스를 범용, 표준 또는 기본 탄력적 풀로 이동하는 경우에도 동일한 고려 사항이 적용됩니다.

Important

메모리 내 OLTP는 범용 또는 Azure SQL Database의 표준 또는 기본 DTU 계층에서 지원하지 않습니다. 따라서 메모리 내 OLTP 개체가 있는 데이터베이스를 이러한 계층 중 하나로 이동할 수 없습니다. 데이터베이스를 다운그레이드하기 전에 모든 메모리 최적화 테이블 및 테이블 형식뿐만 아니라 고유하게 컴파일한 모든 T-SQL 모듈을 제거하거나 이를 행 기반 개체로 변환합니다.

중요 비즈니스용 계층으로 리소스 스케일 다운: 메모리 최적화 테이블의 데이터는 데이터베이스의 계층과 연결되거나 탄력적 풀에서 사용할 수 있는 메모리 내 OLTP 스토리지 내에 맞아야 합니다. 계층을 스케일 다운하거나 사용 가능한 메모리 내 OLTP 스토리지가 충분하지 않은 풀로 데이터베이스를 이동하려고 하면 작업이 실패합니다.

메모리 내 개체가 있는지 확인

지정된 데이터베이스가 메모리 내 OLTP를 지원하는지를 파악하는 프로그래밍 방식도 있습니다. 다음 Transact-SQL 쿼리를 실행할 수 있습니다.

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

쿼리에서 1을 반환하면 메모리 내 OLTP가 이 데이터베이스에서 지원되는 것입니다.

다음 쿼리는 데이터베이스를 범용, 표준 또는 기본으로 다운그레이드하기 전에 제거해야 하는 모든 개체를 식별합니다.

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

메모리 내 columnstore

메모리 내 columnstore 기술을 사용하면 테이블에 대량의 데이터를 저장하고 쿼리할 수 있습니다. Columnstore 기술은 열 기반 데이터 스토리지 형식 및 일괄 쿼리 처리를 사용하여 기존 행 기반 스토리지보다 OLAP에서 최대 10배 높은 쿼리 성능을 실현합니다. 또한 압축되지 않은 데이터 크기보다 최대 10배의 데이터 압축 향상을 얻을 수 있습니다.

데이터를 구성하는 데 사용할 수 있는 두 가지 유형의 columnstore 모델이 있습니다.

  • 클러스터형 columnstore 여기서 테이블의 모든 데이터는 열 형식으로 구성됩니다. 이 모델에서 테이블의 모든 행은 데이터를 많이 압축하고 테이블에서 빠른 분석 쿼리 및 보고서를 실행할 수 있도록 열 형식으로 배치됩니다. 데이터의 특성에 따라 데이터 크기가 10~100배 감소할 수 있습니다. 또한 클러스터형 columnstore 모델을 사용하면 100,000개보다 큰 데이터 일괄 처리가 디스크에 저장되기 전에 압축되므로 대량 데이터(대량 로드)를 빠르게 수집할 수 있습니다. 이 모델은 클래식 데이터 웨어하우스 시나리오에 적합합니다.
  • 데이터가 기존 rowstore 테이블에 저장되고 분석 쿼리에 사용되는 columnstore 형식의 인덱스가 있는 비클러스터형 columnstore. 이 모델은 HTAP(하이브리드 트랜잭션 분석 처리)를 사용하도록 설정합니다. 이 기능은 트랜잭션 워크로드에서 성능이 뛰어난 실시간 분석을 실행합니다. OLTP 쿼리는 작은 행의 세트에 액세스하는 데 최적화된 rowstore 테이블에서 실행되는 반면 OLAP 쿼리는 스캔 및 분석에 유용한 columnstore 인덱스에서 실행됩니다. 쿼리 최적화는 쿼리에 따라 rowstore 또는 columnstore 형식을 동적으로 선택합니다. 비클러스터형 columnstore 인덱스는 원래 데이터 집합이 변경되지 않고 원래 rowstore 테이블에 유지되므로 데이터 크기를 줄이지 않습니다. 그러나 추가 columnstore 인덱스의 크기는 해당 B-트리 인덱스보다 작은 크기의 순서에 있어야 합니다.

참고 항목

메모리 내 columnstore 기술은 메모리에서 처리하는 데 필요한 데이터만 유지하고 메모리에 맞지 않는 데이터는 디스크에 저장합니다. 따라서 메모리 내 columnstore 구조에서 데이터의 양은 사용할 수 있는 메모리 양을 초과할 수 있습니다.

columnstore 인덱스의 데이터 크기 및 스토리지

Columnstore 인덱스는 메모리에 맞지 않아도 됩니다. 따라서 인덱스의 크기에 대한 유일한 제한은 전체 최대 데이터베이스 크기이며 DTU 기반 구매 모델 및 vCore 기반 구매 모델 문서에서 설명합니다.

클러스터형 columnstore 인덱스를 사용하는 경우 기본 테이블 스토리지에 열 형식 압축이 사용됩니다. 이 압축을 통해 사용자 데이터의 스토리지 공간을 크게 줄일 수 있습니다. 즉, 데이터베이스에 더 많은 데이터를 담을 수 있습니다. 또한 압축은 열 형식 보관 압축을 사용하여 늘릴 수 있습니다. 수행할 수 있는 압축의 크기는 데이터의 특성에 따라 달라지지만 보통 10배 정도 압축됩니다.

예를 들어, 최대 크기 1TB(테라바이트)인 데이터베이스가 있고 columnstore 인덱스를 사용하여 10배 압축을 달성한 경우 데이터베이스에 총 10TB의 사용자 데이터를 담을 수 있습니다.

비클러스터형 columnstore 인덱스를 사용하는 경우 기본 테이블은 여전히 기존의 rowstore 형식으로 저장됩니다. 따라서 스토리지 절감이 클러스터형 columnstore 인덱스만큼 크지 않습니다. 그러나 기존의 많은 비클러스터형 인덱스를 단일 columnstore 인덱스로 바꾸는 경우에도 테이블에 대한 스토리지 공간에서 전반적인 절감 효과를 얻을 수 있습니다.

columnstore 인덱스를 포함하는 데이터베이스의 서비스 계층 변경

‘단일 데이터베이스를 기본 또는 표준으로 다운그레이드’하는 것은 대상 계층이 S3 미만인 경우 불가능할 수 있습니다. 기본 계층을 제외하고 중요 비즈니스용/프리미엄 가격 책정 계층, 표준 계층, S3 이상에서만 columnstore 인덱스가 지원됩니다. 데이터베이스를 지원되지 않는 계층 또는 수준으로 다운그레이드하면 columnstore 인덱스를 사용할 수 없습니다. 시스템은 columnstore 인덱스를 유지 관리하지만 해당 인덱스를 사용하지는 않습니다. 나중에 지원되는 계층 또는 수준으로 다시 업그레이드하는 경우 columnstore 인덱스는 즉시 다시 사용할 수 있습니다.

클러스터형 columnstore 인덱스가 있는 경우에는 다운그레이드 후에 전체 테이블을 사용할 수 없게 됩니다. 데이터베이스를 지원하지 않는 계층 또는 수준으로 다운그레이드하기 전에 모든 클러스터형 columnstore 인덱스를 삭제합니다(그리고 rowstore 클러스터형 인덱스로 대체합니다).

관련 콘텐츠