SQL Azure 성능 고려 사항

Question

SQL Azure 응용 프로그램을 계획 할 때 고려해야 할 성능 고려 사항은 무엇입니까? Azure 저장소, 그리고 작업자와 웹 역할은 매우 확장 성이 뛰어나지 만 결국에는 하나의 데이터베이스를 사용하는 경우 병목처럼 보입니다.

1. 얼마나 많은 동시 연결하지 SQL 애저 지원 :

   나는 약 번호를 찾을려고?

2. 대역폭은 어느 것입니까?

운이 없다.

예를 들어, 매우 높은 수준의 삽입을 사용하는 응용 프로그램을 계획하고 있지만 집계 함수의 결과를 매번 반환해야합니다 (예 : 한 열에 같은 키가있는 모든 레코드의 합계). 그래서 나는 테이블 스토리지와 함께 갈 수 없습니다.

일괄 처리는 옵션이지만 시간 응답 또한 중요합니다. 따라서 데이터베이스가 많은 연결로 인해 부풀려 질 것 같습니다.

샤딩은 다른 옵션이지만 삽입량이 많은 경우에도 데이터 양이 매우 적으며 PK가 1 개인 경우 FK가없는 경우 4 ~ 6 개입니다. 따라서 1Gb DB조차도 파티션에 대한 과잉 (과금 : D)이 될 수 있습니다.

이러한 종류의 응용 프로그램에 직면 할 때 유의해야 할 성능 키는 무엇입니까?

건배.

Answer 1

클라우드에서도 확장 성과 성능 모두를 달성하는 것이 매우 어려울 수 있습니다. 질문은 기본적으로 확장성에 관한 것이므로 큐를 사용하여 데이터가 "궁극적으로"일관성있게되는 방식으로 응용 프로그램을 디자인 할 수 있습니다. 작업자 역할은 들어오는 삽입 요청을 수신하고 비동기 적으로 삽입을 수행합니다.

데이터베이스에 대한 왕복 수를 최소화하고 연결 풀링을 최적화하려면 삽입을 일괄 처리하십시오. 한 번에 100 개의 인서트를 보낼 수 있습니다. 또한 SQL Azure는 MARS (다중 활성 레코드 세트)를 지원하므로 하나의 일괄 처리에서 여러 SELECT를 호출 코드로 반환 할 수 있습니다. 일괄 처리 및 MARS를 사용하면 데이터베이스 연결 수를 최소한으로 줄일 수 있습니다.

샤딩은 일반적으로 읽기 작업에 도움이됩니다. 비록 내가 샤딩 (sharding)을 가진 인서트를 절대로 벤치 마크하지는 않았지만, 인서트를위한 것이 아닙니다. 따라서 샤딩이 요구 사항에 도움이 될지 확신 할 수 없습니다.

Azure는 동일한 서버의 다른 사용자와 데이터베이스를 공유하는 다중 점유 환경에서 확장 성 및 합리적인 성능을 위해 설계된 제품입니다. 따라서 응답 시간이 보장되는 강력한 성능이 필요한 경우 호스팅 선택을 재평가하거나 tijmenvdk에서 제안한대로 Azure의 성능 경계를 실제로 테스트해야 할 수 있습니다.

Answer 2

SQL Azure는 리소스 충돌이 발생하는 경우 연결을 차단합니다 (부하가 많이 발생하지만 데이터베이스가 실제로 이동 한 경우에도 발생할 수 있음). 스로틀은 비 결정적입니다. 즉, 이러한 상황이 발생할 때를 예측할 수 없습니다. 스로틀 링할 때 SQL Azure는 연결을 끊어 재 시도를 요구합니다. 지원되는 연결 수 및 대역폭은 기본 인프라의 유연한 특성으로 인해 "의도적으로"게시되지 않습니다. 즉, 설정은 높은 처리량이 아닌 고 가용성에 맞게 최적화되어 있습니다.

알려진 시간에 버스트가 발생하는 경우 버스트가 발생하는 동안 샤딩을 고려하고 버스트 발생 후 데이터를 통합 할 수 있습니다. 이를 처리하는 또 다른 방법은 스로틀이 발생하는 경우에만 큐잉/일괄 쓰기를 시작하는 것입니다. Azure Queue를 사용하여 작업자 역할을 수행하면 나중에 대기열을 비울 수 있습니다. 이 "오버플로 메커니즘"은 스로틀 링이 발생하면 자동으로 맞물리게됩니다.

Azure 테이블 저장소를 사용하고 데이터에 대한 집계를 수행하는 대신 모든 레코드의 필요한 합계를 반환하는 대신 다시보고 할 수있는 별도의 실행중인 테이블을 유지할 수 있습니다 (이 문제는 테이블에 대한 잠금의 부재).

명백한 진술에 사과드립니다.하지만 첫 번째 단계는 시나리오에서 조절이 중단되었는지 테스트하는 것입니다. 오버플로 솔루션을 사용해 보겠습니다.