많은 양의 레코드를 가져올 때 DocumentDB가 SQL보다 느린가요?

Question

저는 벤치마킹을하고 있었으므로 2500 레코드가있는 SQL 데이터베이스가있었습니다. 나는 그 기록들을 DocumentDB에 삽입했다.

필자는 두 줄의 코드를 작성하여 모든 2500을 C#의 배열로 가져 오는 엔티티 프레임 워크로 작성했습니다. DocuementDB에서 모든 2500을 배열로 가져 오는 다음 행. 사용

코드 :

var test= await Task<Test>.Run(() => 
       client.CreateDocumentQuery<Test>(collection.DocumentsLink) 
       .ToList()); 

DocumentDB의 예를 20 초 동안했다. SQL Server 라인은 거의 순간적이었습니다. 객체는 5 개의 속성을 가진 간단한 DTO이며 인터넷을 통해 SQL 쿼리를 수행했습니다.

DocumentDB를 잘못 사용하고 있습니까? 나는 당신의 모든 기록을 기억으로 가져 와서 linq와 합류 시키려고했다고 생각했습니다.

Answer 1

@bladefist를 사용하면 DocumentDB에서 훨씬 뛰어난 성능을 얻을 수 있습니다. 예를 들어 서유럽의 Azure VM 및 DocumentDB 계정에서이 코드 스텁과 출력을 살펴보십시오.

이

• 를 사용하여 직접 연결 및 TCP 프로토콜
• 를 사용하여 큰 페이지 크기 (최대 : : 1000) 당신이 큰 일괄 적으로 읽고있는 경우에하는 것은 최소화하기 위해 성능을 따르지

  Stopwatch watch = new Stopwatch(); 
  for (int i = 0; i < 10; i++) 
  { 
      watch.Start(); 
      int numDocumentsRead = 0; 
      foreach (Document d in client.CreateDocumentQuery(collection.SelfLink, 
       new FeedOptions { MaxItemCount = 1000 })) 
      { 
       numDocumentsRead++; 
      } 
  
      Console.WriteLine("Run {0} - read {1} documents in {2} ms", i, numDocumentsRead, 
       watch.Elapsed.TotalMilliseconds); 
      watch.Reset(); 
  } 
  
  //Output 
  Run 0 - read 2500 documents in 426.1359 ms 
  Run 1 - read 2500 documents in 286.506 ms 
  Run 2 - read 2500 documents in 227.4451 ms 
  Run 3 - read 2500 documents in 270.4497 ms 
  Run 4 - read 2500 documents in 275.7205 ms 
  Run 5 - read 2500 documents in 281.571 ms 
  Run 6 - read 2500 documents in 268.9624 ms 
  Run 7 - read 2500 documents in 275.1513 ms 
  Run 8 - read 2500 documents in 301.0263 ms 
  Run 9 - read 2500 documents in 288.1455 ms 
  

  일부 모범 사례 왕복 횟수

• 지연 시간을 줄이려면 DocumentDB 계정과 동일한 지역에서 클라이언트를 실행하십시오.
• 다음과 같은 용량 단위의 프로비저닝 된 처리량 (및 저장량) 구매는 컬렉션 전체에 퍼집니다. 따라서 처리량을 측정하려면 앱이 모든 콜렉션에서 작업 부하를 분산시켜야합니다. 예를 들어 1CU를 구매 한 경우 모든 처리량을 단일 수집 항목 또는 3 개 모음에 분산하도록 선택할 수 있습니다.