Azure DocumentDB 제한 요청

Question

나는 하늘에 문서 데이터베이스가 있습니다. 사용자 레코드와 모든 데이터를 보관할 때 특히 많은 쿼리가 발생합니다.

나는 S1 계획에 있었고 내가 RU/s 한도를 치고 있었다는 예외가 생길 것입니다. S1 계획에는 250이 있습니다.

RU/S를 설정하고 비용을 지불 할 수있는 표준 계획으로 전환하기로 결정했습니다.

500 RU/s로 설정했습니다.

동일한 쿼리를 수행하고 돌아가서 모니터링 차트를 살펴 보았습니다.

이 최신 쿼리 테스트를 수행 할 당시 나는 226 건의 요청을했으며 10 건이 제한되었다고 말했습니다.

왜 그럴까요? 나는 그것을 500RU/s로 설정했다. 그런데 쿼리가 실패했습니다.

Answer 1

첫째, Requests = Request Units이므로 226 요청은 어느 시점에서 1 초 이내에 500 개 이상의 요청 단위를 필요로합니다.

DocumentDb API는 요청하는 RU의 수를 알려주므로 클라이언트 측에서 어떤 요청이 문제를 일으키는 지 확인할 수 있습니다. 저의 경험에 비추어 볼 때, 단순한 by-id 요청조차도 최소한 몇 개의 RU가 소요됩니다. 비용은 사용하는 클라이언트 측 SDK에 따라 다릅니다. 필자의 코드에서는 10 RU 이상의 비용이 소요되는 모든 요청을 자동으로 기록하기 위해 무언가를 추가 했으므로 알기 쉽고 조치를 취할 수 있습니다.

포털의 모니터링 도구가 매우 부적합하고 팀에서 작업하고 있다는 것을 알고 있습니다. 5 분 간격으로 총 RU 만 볼 수 있지만 1 초 내에 600 RU를 사용하려고 시도 할 수 있으며 포털에서 실제로 볼 수는 없습니다.

귀하의 경우, 500 RU 이상으로 비용이 많이 소요되는 단일 쿼리가있을 수 있습니다. 로깅에서 알려줍니다. 이 경우 생성 된 SQL을보고 이유를 확인하거나 여기에 게시 할 수도 있습니다.

또는 작은 시간에 많은 요청이 누적되는 효과가 누적 될 수 있습니다. 한 사용자 작업에 대한 응답으로 226 건의 요청을 처리하는 경우 (그리고 난 그럴지도 모름) 설계를 재고하고 싶을 것입니다.

마지막으로 실패한 요청을 다시 시도 할 수 있습니다. 다른 SDK에 대해서는 잘 모르겠지만 .Net SDK는 포기하기 전에 자동으로 9 번 요청을 재 시도합니다 (229 요청에 대한 다른 설명이 서버에 적용될 수 있음). 선택한 SDK가 다시 시도하지 않으면 직접 할 수 있습니다. 서버는 재시도 전에 얼마나 오래 기다려야하는지에 대한 지시와 함께 특정 상태 코드 (429는 기억하지만 꽤 기억할 수 없음)를 반환합니다.

더 자세히 도움을 받으려면 검색어를 확인하고 질문을 업데이트하십시오.