다음을 통해 공유

Azure Stream Analytics에서 Azure SQL Database로 처리량 성능 향상

이 문서에서는 Azure Stream Analytics를 사용하여 Azure SQL Database에 데이터를 로드할 때 더 나은 쓰기 처리량 성능을 달성하기 위한 팁을 설명합니다.

Azure Stream Analytics의 SQL 출력은 옵션으로 병렬로 쓰기를 지원합니다. 이 옵션을 사용하면 여러 출력 파티션이 대상 테이블에 병렬로 쓰는 완전 병렬 작업 토폴로지를 사용할 수 있습니다. 그러나 Azure Stream Analytics에서 이 옵션을 사용하도록 설정하면 데이터베이스 구성 및 테이블 스키마에 따라 크게 달라지기 때문에 처리량을 높이기에는 충분하지 않을 수 있습니다. 인덱스, 클러스터링 키, 인덱스 채우기 비율 및 압축 선택은 테이블을 로드하는 시간에 영향을 줍니다. 내부 벤치마크에 따라 쿼리 및 로드 성능을 개선하기 위해 데이터베이스를 최적화하는 방법에 대한 자세한 내용은 SQL Database 성능 지침을 참조하세요. 쓰기 순서는 SQL Database와 병렬로 작성할 때 보장되지 않습니다.

다음은 솔루션의 전반적인 처리량을 개선하는 데 도움이 되는 각 서비스 내의 몇 가지 구성입니다.

Azure Stream Analytics

  • 분할 상속 – 이 SQL 출력 구성 옵션을 사용하면 이전 쿼리 단계 또는 입력의 분할 체계를 상속할 수 있습니다. 이 기능을 사용하도록 설정하면 디스크 기반 테이블에 데이터를 기록하고 작업의 완전히 병렬 토폴로지를 사용하여 향상된 처리량을 기대할 수 있습니다. 이 분할은 이미 다른 많은 출력에 대해 자동으로 발생 합니다. 이 옵션을 사용하여 대량 삽입할 때도 테이블 잠금(TABLOCK)을 사용할 수 없습니다.

    메모

    입력 파티션이 8개 이상인 경우 입력 분할 체계를 상속하는 것이 적절하지 않을 수 있습니다. 이 상한은 단일 ID 열과 클러스터형 인덱스가 있는 테이블에서 관찰되었습니다. 이 경우 쿼리에서 INTO 8을 사용하여 출력 기록기 수를 명시적으로 지정하는 것이 좋습니다. 스키마 및 인덱스 선택에 따라 관찰이 달라질 수 있습니다.

  • 일괄 처리 크기 - SQL 출력 구성을 사용하면 대상 테이블/워크로드의 특성에 따라 Azure Stream Analytics SQL 출력의 최대 일괄 처리 크기를 지정할 수 있습니다. 일괄 처리 크기는 모든 대량 삽입 트랜잭션과 함께 전송되는 최대 레코드 수입니다. 클러스터형 columnstore 인덱스에서 일괄 처리 크기는 약 100K 로 더 많은 병렬화, 최소 로깅 및 잠금 최적화를 허용합니다. 디스크 기반 테이블에서는 일괄 처리 크기가 높을수록 대량 삽입 중에 잠금 에스컬레이션이 트리거될 수 있으므로 10K(기본값) 이하가 솔루션에 최적일 수 있습니다.

  • 입력 메시지 튜닝 – 상속 분할 및 일괄 처리 크기를 사용하여 최적화한 경우 파티션당 메시지당 입력 이벤트 수를 늘리면 쓰기 처리량을 더욱 높일 수 있습니다. 입력 메시지 튜닝을 사용하면 Azure Stream Analytics 내의 일괄 처리 크기를 지정된 일괄 처리 크기까지 지정할 수 있으므로 처리량이 향상됩니다. 이는 EventHub 또는 Blob에서 압축 을 사용하거나 입력 메시지 크기를 늘려서 수행할 수 있습니다.

SQL Azure

  • 분할된 테이블 및 인덱스 – 분할된 SQL 테이블과 파티션 키와 같은 열이 있는 테이블의 분할된 인덱스(예: PartitionId)를 사용하면 쓰기 중에 파티션 간의 경합을 크게 줄일 수 있습니다. 분할된 테이블의 경우 PRIMARY 파일 그룹에 파티션 함수 와 파티션 구성표를 만들어야 합니다. 이렇게 하면 새 데이터가 로드되는 동안 기존 데이터의 가용성도 높아집니다. 로그 IO 제한은 파티션 수에 따라 영향을 받을 수 있으며, SKU를 업그레이드하여 파티션 수를 늘림으로써 이를 해결할 수 있습니다.

  • 고유 키 위반 방지 – Azure Stream Analytics 활동 로그에서 여러 키 위반 경고 메시지가 표시되는 경우 복구 사례 중에 발생할 수 있는 고유한 제약 조건 위반의 영향을 받지 않도록 합니다. 인덱스에 IGNORE_DUP_KEY 옵션을 설정하여 이 문제를 방지할 수 있습니다.

Azure Data Factory와 인메모리 테이블

  • In-Memory 테이블을 임시 테이블로 사용하기 - In-Memory 테이블은 매우 빠른 데이터 로드를 가능하게 하지만, 데이터는 메모리에 적합해야 합니다. 벤치마크는 메모리 내 테이블에서 디스크 기반 테이블로의 대량 로드가 ID 열과 클러스터형 인덱스가 있는 디스크 기반 테이블에 단일 기록기를 사용하여 직접 대량 삽입하는 것보다 약 10배 더 빠릅니다. 이 대량 삽입 성능을 활용하려면 메모리 내 테이블에서 디스크 기반 테이블로 데이터를 복사하는 Azure Data Factory를 사용하여 복사 작업을 설정합니다.

성능 문제 방지

데이터를 전송하고, insert 문을 구문 분석하고, 문을 실행하고, 트랜잭션 레코드를 발급하는 반복 오버헤드가 방지되므로 데이터를 대량 삽입하면 단일 삽입으로 데이터를 로드하는 것보다 훨씬 빠릅니다. 대신 데이터를 스트리밍하기 위해 스토리지 엔진에 보다 효율적인 경로가 사용됩니다. 그러나 이 경로의 설치 비용은 디스크 기반 테이블의 단일 insert 문보다 훨씬 높습니다. 손익분기점은 일반적으로 약 100개의 행에서 발생하며, 그 지점부터는 대량 로드가 거의 항상 더 효율적입니다.

들어오는 이벤트 속도가 낮으면 100개 행보다 낮은 일괄 처리 크기를 쉽게 만들 수 있으므로 대량 삽입이 비효율적이며 디스크 공간이 너무 많이 사용됩니다. 이 제한 사항을 해결하려면 다음 작업 중 하나를 수행할 수 있습니다.

  • INSTEAD OF 트리거를 생성하여 모든 행에 단순 삽입을 수행합니다.
  • 이전 섹션에서 설명한 대로 In-Memory 임시 테이블을 사용합니다.

이와 같은 또 다른 시나리오는 NCCI(비클러스터형 columnstore 인덱스)에 쓸 때 발생합니다. 여기서 대량 삽입이 작을수록 세그먼트가 너무 많아 인덱스가 충돌할 수 있습니다. 이 경우 클러스터형 Columnstore 인덱스 대신 사용하는 것이 좋습니다.

요약

요약하자면, SQL 출력을 위한 Azure Stream Analytics의 분할된 출력 기능을 통해 SQL Azure의 분할된 테이블과 작업의 정렬된 병렬화는 상당한 처리량 향상을 제공해야 합니다. In-Memory 테이블에서 디스크 기반 테이블로 데이터 이동을 조정하고 관리하기 위해 Azure Data Factory를 활용하면 처리량이 획기적으로 증가합니다. 가능한 경우 메시지 밀도를 개선하는 것이 전체 처리량을 개선하는 주요 요인이 될 수 있습니다.

다음 단계

  • Last updated on