다음을 통해 공유

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 데이터베이스의 메모리 내 샘플을 참조하세요.

메모리 내 기술의 혜택

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

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

참고 항목

메모리 내 OLTP는 프리미엄(DTU) 및 Azure SQL 데이터베이스의 중요 비즈니스용(vCore) 서비스 계층에서 제공됩니다. 하이퍼스케일 서비스 계층은 메모리 내 OLTP 개체의 하위 집합을 지원합니다. 자세한 내용은 해당 하이퍼스케일 제한 사항을 참조하세요.

columnstore 인덱스는 서비스 목표가 S3 미만인 경우 기본 계층 및 표준 계층을 제외한 모든 서비스 계층에서 사용할 수 있습니다. 자세한 내용은 columnstore 인덱스를 포함하는 데이터베이스의 서비스 계층 변경을 참조하세요.

이 문서에서는 Azure SQL 데이터베이스 전용 메모리 내 OLTP 및 columnstore 인덱스의 측면을 설명하며 다음을 확인할 수 있는 샘플도 포함되어 있습니다.

  • 스토리지 및 데이터 크기 제한에 대한 이러한 기술의 영향.
  • 다양한 가격 책정 계층 사이에서 이러한 기술을 사용하는 데이터베이스의 이동을 관리하는 방법.
  • columnstore 인덱스뿐만 아니라 메모리 내 OLTP의 예시 사용.

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

메모리 내 OLTP

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

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

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

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

참고 항목

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

메모리 내 OLTP의 데이터 크기 및 스토리지 한도

메모리 내 OLTP는 사용자 데이터를 저장하는 데 사용되는 메모리 최적화 테이블을 포함합니다. 이러한 테이블은 메모리에 맞게 지정해야 합니다. 각 서비스 목표에는 메모리 최적화 테이블(메모리 내 OLTP 스토리지라고 함)에 대한 메모리 할당량 또는 한도가 있습니다.

지원되는 단일 데이터베이스 서비스 목표 및 각 탄력적 풀 서비스 목표는 각각 일정량의 메모리 내 OLTP 스토리지를 포함합니다.

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

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

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

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

탄력적 풀에 대한 정보

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

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

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

메모리 내 OLTP는 Azure SQL 데이터베이스의 범용, 표준 및 기본 서비스 계층에서 지원하지 않습니다. 따라서 메모리 내 OLTP 개체가 있는 데이터베이스를 이러한 계층 중 하나로 크기 조정할 수 없습니다. 데이터베이스를 이러한 서비스 계층 중 하나로 크기 조정하려면 모든 메모리 최적화 테이블 및 테이블 형식과 네이티브 컴파일된 모든 T-SQL 모듈을 제거하거나 디스크 기반 개체 및 일반 T-SQL 모듈로 변환합니다.

중요 비즈니스용 또는 프리미엄 데이터베이스를 스케일 다운하는 경우 메모리 최적화 테이블의 데이터는 데이터베이스 또는 탄력적 풀의 대상 서비스 목표에서 사용할 수 있는 메모리 내 OLTP 스토리지 내에 맞아야 합니다. 데이터베이스 또는 탄력적 풀을 스케일 다운하거나 데이터베이스를 탄력적 풀로 이동하려는 경우 대상 서비스 목표에 사용 가능한 메모리 내 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 인덱스로 바꾸는 경우에도 테이블에 대한 스토리지 공간에서 전반적인 절감 효과를 얻을 수 있습니다. 기본 테이블에 rowstore 데이터 압축을 사용할 수도 있습니다.

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

DTU 구매 모델을 사용하고 데이터베이스에 columnstore 인덱스가 포함된 경우 S3 서비스 목표 이하로 데이터베이스 크기를 조정하는 경우 애플리케이션의 작동이 중지될 수 있습니다. S3 이상을 사용하는 경우 Columnstore 인덱스는 하이퍼스케일, 중요 비즈니스용 및 프리미엄 서비스 계층뿐만 아니라 표준 서비스 계층에서도 지원됩니다. Columnstore 인덱스는 기본 서비스 계층에서 지원되지 않습니다. 데이터베이스를 지원되지 않는 계층 또는 서비스 목표로 크기를 조정하면 columnstore 인덱스를 사용할 수 없습니다. 시스템은 DML 문을 실행할 때 인덱스를 유지 관리하지만 인덱스를 사용하지는 않습니다. 나중에 지원되는 서비스 계층 또는 서비스 목표로 크기를 다시 조정하는 경우 columnstore 인덱스는 즉시 다시 사용할 수 있습니다.

클러스터형 columnstore 인덱스가 있는 경우 데이터베이스를 지원되지 않는 서비스 계층 또는 서비스 목표로 크기를 조정하면 전체 테이블을 사용할 수 없게 됩니다. 크기 조정 작업 전에 모든 클러스터형 columnstore 인덱스를 삭제하고 rowstore 클러스터형 인덱스 또는 힙으로 바꿔 놓습니다.

관련 콘텐츠