알림 계획
쿼리 알림을 효과적으로 사용하려면 쿼리 알림이 응용 프로그램에 효과적인지 여부와 응용 프로그램에서 사용되는 쿼리가 알림을 지원하는지 여부 및 알림 구독 및 수신을 위해 응용 프로그램에 사용할 전략 등에 대해 고려해야 합니다.
쿼리 알림은 쿼리의 데이터가 비교적 가끔 변경되고, 데이터 변경 시 응용 프로그램이 이를 즉시 업데이트할 필요가 없으며, 알림에 대한 쿼리 만들기에 설명된 요구 사항 및 제한 사항에 쿼리가 부합되는 경우 데이터베이스에 대한 왕복 횟수를 효과적으로 줄여 줍니다. 여러 웹 기반 응용 프로그램에서는 이러한 기준을 충족하며 이러한 응용 프로그램에서는 쿼리 알림을 활용할 수 있습니다.
일부 경우에는 쿼리 알림이 효과적이 아닐 수 있습니다. 쿼리 알림은 응용 프로그램이 데이터베이스에서 데이터를 자주 읽지만 상대적으로 데이터에 대한 업데이트가 가끔 발생하는 경우에 유용합니다. 예를 들어 온라인 카탈로그 응용 프로그램은 카탈로그 업데이트 횟수보다 읽기 횟수가 더 많을 것입니다. 하지만 온라인 장바구니의 경우에는 특정 내용이 상당히 자주 업데이트되기 때문에 쿼리 알림의 효율이 떨어집니다.
쿼리 알림은 응용 프로그램에서 공통 구조를 공유하고 매개 변수의 값만 달라지는 쿼리를 실행하는 경우에 더욱 효율적입니다. 예를 들면 다음과 같습니다.
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 300
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 500
이 경우 두 알림에 대한 쿼리 알림 구독은 같은 내부 템플릿을 공유하므로 서로 다른 쿼리 구조로 두 개의 알림을 사용하는 것보다 SQL Server에 오버헤드가 적습니다. 하지만 쿼리에 있는 매개 변수는 유지됩니다. 쿼리에서 템플릿을 공유하는 경우에도 ListPrice가 350인 항목을 추가하면 첫 번째 쿼리가 아닌 두 번째 쿼리에 대한 알림이 발생합니다.
쿼리 알림이 테이블에 활성화된 경우 테이블에 대한 업데이트는 보다 비용이 높아집니다. 데이터베이스 엔진은 구독을 확인하고 필요한 경우 알림을 생성하기 위해 추가 작업을 수행합니다. 내부 템플릿을 다시 사용하면 구독 당 오버헤드를 최소화하는 데 도움이 됩니다. 따라서 쿼리 알림은 유사한 구조의 쿼리를 전송하는 응용 프로그램에 대해서만 사용해야 합니다. 서로 다른 구조의 쿼리를 전송하는 응용 프로그램에서는 쿼리 알림을 사용하지 않아야 합니다.
예를 들어 특정 가격 범위의 카탈로그 항목을 표시하는 응용 프로그램은 같은 구조의 쿼리를 전송합니다. 이 경우 데이터베이스 엔진은 각 쿼리에 대해 내부 템플릿을 다시 사용하여 쿼리 알림 성능이 향상될 수 있습니다. 하지만 임시 보고를 허용하는 응용 프로그램은 여러 구조의 쿼리를 전송합니다. 이 경우 응용 프로그램에서는 쿼리 알림을 사용하지 않아야 합니다.
데이터베이스 엔진은 적어도 하나 이상의 등록된 구독에서 사용되는 한 내부 템플릿을 유지 관리합니다. 데이터베이스 엔진은 여러 내부 템플릿의 개수를 하나의 특정 테이블로 제한합니다. 이러한 제한을 초과하면 새로운 템플릿을 만들어야 하는 구독이 데이터베이스 엔진에 등록되지 않습니다. 그 대신 데이터베이스 엔진이 구독을 등록할 수 없다는 구독 메시지를 즉시 생성합니다.
효율적인 쿼리 알림 정책 계획
쿼리 알림은 알림의 총 수가 적당할 때 일반적으로 잘 작동하고, 응용 프로그램은 데이터가 변경될 때 즉각적인 알림 응답 시간을 요청하지 않습니다. 대표적인 웹 계층 캐시 무효화 시나리오는 이 모델에 적합하며 응용 프로그램에 쿼리 알림을 사용하는 것이 좋습니다. 알림의 응답 시간이 초 미만 단위이거나, 네트워크 인프라가 빠르지 않고 불안정하거나, 알림 양이 매우 많을 때 응용 프로그램에 쿼리 알림을 사용하는 것은 좋지 않습니다.
쿼리 알림을 사용할 때는 응용 프로그램이 배포되는 시점에 실행되는 환경과 범위에서 테스트하고 조정해야 합니다. 실제 사용할 때 예상되는 최대 부하 시나리오를 고려하고 발생할 수 있는 최대 활동량에 대한 계획을 세웁니다.
초 미만 단위의 안정적인 쿼리 알림이 필요한 상황에서 쿼리 알림을 사용하는 경우 고성능 OLTP 응용 프로그램을 구축하는 데 적용한 것과 동일한 기술을 쿼리 알림 응용 프로그램에 적용합니다.
이 경우 응용 프로그램의 잠금 시간을 초 미만 단위보다 길지 않게 하십시오. 예를 들어, 불안정한 성능의 네트워크에서 실행되는 클라이언트에서 다중문 트랜잭션을 실행하지 마십시오.
사용자 데이터 테이블에서 문제가 되는 부분을 확인하고 제거합니다.
쿼리 알림이 설정된 해당 사용자 테이블에 업데이트가 발생하면 쿼리 알림 내부 테이블을 순차적으로 자주 검색됩니다. 쿼리 알림 내부 테이블에서 유지되는 테이블 수준 잠금에 병목이 발생하면 쿼리 알림이 있는 사용자 테이블을 여러 개의 개별 테이블로 분할하여 데이터가 변경될 때마다 처리될 알림 수를 줄일 수 있습니다.
수명이 짧은 알림 요청이 필요한 경우 SqlDependency Constructor의 제한 시간에 기본값인 5일 보다 훨씬 짧은 값(예: 1분)을 사용해 보십시오. 이렇게 하면 내부 쿼리 알림 테이블의 행 수를 현저히 줄일 수 있습니다. 결과적으로 이러한 테이블을 처리하는 데 필요한 시간과 잠금 경합을 줄일 수 있습니다.
쿼리 알림 대체
데이터 업데이트 빈도가 매우 높고 처리되지 않은 응답 요청이 많은 환경에서 데이터 변경에 대한 빠르고 예측 가능한 알림 응답 시간이 필요한 경우 다음 대체 솔루션 중 하나를 고려하십시오.
모니터링되는 테이블에 AFTER UPDATE 트리거를 만드십시오. 이 트리거의 동작은 SQL Server Service Broker를 사용하여 알림이 필요한 엔터티에 메시지를 보냅니다. (다음과 같은 여러 가지 방법으로 트리거를 설계할 수 있습니다. 변경 시 알림을 받아야 하는 엔터티임을 나타내도록 관심있는 테이블에 열을 추가하거나 기본 테이블과 알림을 요청하는 엔터티 정보가 포함된 두 번째 테이블을 연결합니다.)
쿼리 알림에 의존하지 않는 사용자 지정 응용 프로그램 계층 솔루션을 사용하십시오. 예를 들어, 주 메모리 개체 컬렉션에서 모니터링되는 데이터를 유지 관리하는 미들웨어 응용 프로그램에서 알림이 모두 발생하도록 구성합니다. 개체가 알림 조건에 맞게 수정될 때 응용 프로그램에서 알림을 생성할 수 있습니다.
메모리 내 개체 캐시와 개체에 등록한 콜백 함수를 기반으로 변경 알림 메커니즘을 지원하는 Windows Server App Fabric 캐시를 사용하십시오.