DTU 벤치마크
적용 대상: Azure SQL Database
DTU(데이터베이스 트랜잭션 단위)는 CPU, 메모리, 읽기 및 쓰기의 혼합 측정값을 나타내는 측정 단위입니다. 각 DTU 측정값과 연결된 물리적 특성(CPU, 메모리, IO)은 실제 데이터베이스 워크로드를 시뮬레이션하는 벤치마크를 사용하여 보정됩니다. 이 문서에서는 DTU 벤치마크를 요약하고 스키마, 사용된 트랜잭션 유형, 워크로드 조합, 사용자 및 속도, 크기 조정 규칙 및 벤치마크와 연결된 메트릭에 대한 정보를 공유합니다.
DTU 기반 구매 모델에 대한 일반적인 정보는 DTU 기반 구매 모델 개요를 참조하세요.
벤치마크 요약
DTU 벤치마크는 OLTP(온라인 트랜잭션 처리) 워크로드에서 가장 빈번하게 발생하는 기본 데이터베이스 작업의 성능을 측정합니다. 클라우드 컴퓨팅을 예상하고 벤치마크를 설계했지만, 데이터베이스 스키마, 데이터 채우기, 트랜잭션은 OLTP 워크로드에서 가장 일반적으로 사용되는 기본 요소를 광범위하게 나타내도록 설계되었습니다.
벤치마크 결과와 실제 데이터베이스 성능 간 상관 관계 분석
모든 벤치마크는 대표적, 암시적 수치임을 이해하는 것이 중요합니다. 벤치마크 애플리케이션에서 달성한 트랜잭션 속도는 다른 애플리케이션에서 달성할 수 있는 속도와 동일하지 않습니다. 벤치마크는 다양한 테이블 및 데이터 유형이 포함된 스키마에 대해 실행되는 다양한 트랜잭션 유형의 컬렉션으로 구성되어 있습니다. 벤치마크는 모든 OLTP 워크로드에 공통적이고 동일한 기본 작업을 실행하며 특정 클래스의 데이터베이스 또는 애플리케이션을 나타내지 않습니다. 벤치마크의 목표는 컴퓨팅 크기를 확장 또는 축소할 경우 예상할 수 있는 데이터베이스의 상대적 성능에 대한 합리적 지침을 제공하는 것입니다.
실제로, 각 데이터베이스는 크기와 복잡성이 다르고 다양하게 혼합된 워크로드를 처리할 수 있으며 각각 다른 방식으로 대응합니다. 예를 들어, IO를 많이 사용하는 애플리케이션은 IO 임계값에 빠르게 도달할 수 있고 CPU를 많이 사용하는 애플리케이션은 CPU 한도에 빠르게 도달할 수 있습니다. 부하가 증가할 때 특정 데이터베이스가 벤치마크와 동일하게 확장된다는 보장이 없습니다.
벤치마크와 그 방법론은 이 문서에서 더 자세히 설명합니다.
스키마
스키마는 다양한 작업을 지원하도록 다양하고 복잡하게 설계되었습니다. 벤치마크는 6개의 테이블로 구성된 데이터베이스에 실행합니다. 테이블은 고정 크기, 확장, 증가의 세 범주로 구분됩니다. 2개의 고정 크기 테이블, 3개의 확장 테이블, 1개의 증가 테이블이 있습니다. 고정 크기 테이블에는 고정된 수의 행이 있습니다. 확장 테이블에는 데이터베이스 성능에 비례하는 카디널리티가 있지만 벤치마크 중에는 변경되지 않습니다. 증가 테이블은 초기 로드 시 확장 테이블과 같은 크기이지만, 행을 삽입 및 증가하면서 벤치마크를 실행하는 동안 카디널리티가 변경됩니다.
스키마에는 정수, 숫자, 문자, 날짜/시간 등 혼합된 데이터 유형이 포함되어 있습니다. 스키마에는 기본 및 보조 키가 포함되어 있지만 외부 키가 없습니다. 즉, 테이블 간 참조 무결성 제약 조건이 없습니다.
데이터 생성 프로그램은 초기 데이터베이스의 데이터를 생성합니다. 정수 및 숫자 데이터는 다양한 전략으로 생성됩니다. 값이 범위에 무작위로 분포되는 경우도 있습니다. 또한 특정 분포를 유지하기 위해 값 집합을 무작위로 변경하는 경우도 있습니다. 가중치를 적용한 단어 목록에서 텍스트 필드를 생성하여 현실적 데이터를 만듭니다.
데이터베이스는 배율을 기준으로 크기를 조정합니다. 배율(약어: SF)은 확장 및 증가 테이블의 카디널리티를 결정합니다. 아래의 사용자 및 속도 섹션에 설명된 대로 데이터베이스 크기, 사용자 수, 최대 성능은 모두 서로에 비례하여 확장됩니다.
트랜잭션
워크로드는 아래 표와 같이 9가지 트랜잭션 유형으로 구성되어 있습니다. 각 트랜잭션은 다른 트랜잭션과 크게 대비되도록 데이터베이스 엔진 및 시스템 하드웨어에서 특정 시스템 집합의 특성을 강조하도록 설계되었습니다. 이 방식에서는 다양한 구성 요소가 전반적 성능에 미치는 영향을 쉽게 평가할 수 있습니다. 예를 들어 "읽기 작업이 많은" 트랜잭션은 디스크에서 많은 읽기 작업을 만듭니다.
트랜잭션 유형 | 설명 |
---|---|
적은 읽기 작업 | SELECT, 메모리 내, 읽기 전용 |
중간 읽기 작업 | SELECT, 대부분 메모리 내, 읽기 전용 |
많은 읽기 작업 | SELECT, 대부분 메모리 외, 읽기 전용 |
적은 업데이트 작업 | UPDATE, 메모리 내, 읽기-쓰기 |
많은 업데이트 작업 | UPDATE, 대부분 메모리 외, 읽기-쓰기 |
적은 삽입 작업 | INSERT, 메모리 내, 읽기-쓰기 |
많은 삽입 작업 | INSERT, 대부분 메모리 외, 읽기-쓰기 |
DELETE | DELETE, 메모리 내 및 메모리 외 혼합, 읽기-쓰기 |
많은 CPU 사용 | SELECT, 메모리 내, 상대적으로 많은 CPU 부하, 읽기 전용 |
워크로드 혼합
가중치를 적용한 분포에서 다음과 같은 전반적 혼합을 적용하여 무작위로 트랜잭션을 선택합니다. 전반적 혼합은 읽기/쓰기 비율이 약 2:1입니다.
트랜잭션 유형 | 혼합 비율 |
---|---|
적은 읽기 작업 | 35 |
중간 읽기 작업 | 20 |
많은 읽기 작업 | 5 |
적은 업데이트 작업 | 20 |
많은 업데이트 작업 | 3 |
적은 삽입 작업 | 3 |
많은 삽입 작업 | 2 |
DELETE | 2 |
많은 CPU 사용 | 10 |
사용자 및 속도
벤치마크 워크로드는 연결 집합에 트랜잭션을 제출하는 도구를 기반으로 많은 동시 사용자의 동작을 시뮬레이션합니다. 모든 연결과 트랜잭션이 시스템에서 생성된 것이지만, 간단히 이러한 연결을 ‘사용자’로 지칭합니다. 각 사용자는 나머지 사용자와 독립적으로 운영하지만, 모든 사용자는 아래와 같이 동일한 단계의 주기를 수행합니다.
- 데이터베이스에 연결합니다.
- 종료 메시지가 나타날 때까지 반복합니다.
- (가중치가 적용된 분포에서) 무작위로 트랜잭션을 선택합니다.
- 선택한 트랜잭션을 수행하고 응답 시간을 측정합니다.
- 속도 지연을 기다립니다.
- 데이터베이스 연결을 종료합니다.
- 종료합니다.
(2c 단계에서) 무작위이지만 평균 1.0초의 분포가 있는 속도 지연을 선택합니다. 따라서 각 사용자는 평균적으로 1초당 최대 1개의 트랜잭션을 생성할 수 있습니다.
확장 규칙
사용자 수는 데이터베이스 크기로 결정됩니다(배율 단위). 5개의 배율 단위당 1명의 사용자가 있습니다. 속도 지연으로 인해 1명의 사용자는 평균적으로 초당 최대 1개의 트랜잭션을 생성할 수 있습니다.
예를 들어, 배율이 500(SF=500)인 데이터베이스는 사용자가 100명이며 최대 100TPS의 속도를 달성할 수 있습니다. TPS 속도를 높이려면 더 많은 사용자와 더 큰 데이터베이스가 필요합니다.
측정 기간
유효한 벤치마크를 실행하려면 한 시간 이상의 안정적 측정 기간이 필요합니다.
메트릭
벤치마크의 핵심 메트릭은 처리량과 응답 시간입니다.
- 처리량은 벤치마크의 필수 성능 측정값입니다. 처리량은 모든 트랜잭션 유형을 세는 단위 시간당 트랜잭션 수로 보고됩니다.
- 응답 시간은 성능 예측 가능성에 대한 측정값입니다. 응답 시간 제약 조건은 서비스 클래스에 따라 달라지며, 다음과 같이 서비스 클래스가 높을수록 응답 시간 요구 사항이 더욱 까다로워집니다.
서비스 클래스 | 처리량 측정 | 응답 시간 요구 사항 |
---|---|---|
Premium | 초당 트랜잭션 수 | 0.5초에서 95 백분위수 |
표준 | 분당 트랜잭션 수 | 1.0초에서 90 백분위수 |
기본 | 시간당 트랜잭션 수 | 2.0초에서 80 백분위수 |
참고
응답 시간 메트릭은 DTU 벤치마크에만 해당됩니다. 다른 워크로드에 대한 응답 시간은 워크로드에 따라 다릅니다.
다음 단계
다음 문서에서 구매 모델 및 관련 개념에 대해 자세히 알아보세요.