請求率很大

我使用Azure documentdb並通過我的node.js在express服務器上訪問它，當我在循環中查詢時，數量很少的幾百個沒有問題。但是，當查詢在循環稍微大體積，說一千左右加請求率很大

我得到的部分結果（不一致的，我每次運行結果值的時間不一樣。可能是因爲Node.js的異步性）後幾個結果它與此錯誤崩潰

body：'{「code」：「429」，「message」：「消息：{\」Errors \「：[\」Request rate is large \「]} \ r \ nActivityId ：1fecee65-0bb7-4991-a984-292c0d06693d，請求URI：/ apps/cce94097-e5b2-42ab-9232-6abd12f53528/services/70926718-b021-45ee-ba2f-46c4669d952e/partitions/dd46d670-ab6f-4dca-bbbb-937647b03d97/replicas/130845018837894542p「}'}

Mea nDocumentDb無法處理每秒超過1000個請求？一起給我在NoSQL技術上留下不好的印象..是DocumentDB的簡短介紹嗎？

來源

2015-08-26 Shreyz

你可以檢查你爲收藏設定的定價層次是什麼？是「標準S2」（1000個請求單元）還是「標準S3」（2500個請求單元）？ –

拉夫，這是我DocumentDB性質是什麼見刀片，STATUS 在線賬戶TIER 標準位置東南亞 – Shreyz

什麼辦法可以升級到S3現在？ – Shreyz

正如Gaurav所建議的，您可以通過提高定價層來避免該問題，但即使您進入最高層，您也應該能夠處理429個錯誤。當您收到429錯誤時，響應將包含'x-ms-retry-after-ms'標頭。這將包含一個數字，表示在重試導致錯誤的請求之前，您應該等待的毫秒數。

我寫了邏輯來處理這個在我的documentdb-utils node.js package。您可以嘗試使用documentdb-utils，也可以自己複製它。這是一個snipit的例子。

createDocument = function() { 
    client.createDocument(colLink, document, function(err, response, header) { 
     if (err != null) { 
      if (err.code === 429) { 
       var retryAfterHeader = header['x-ms-retry-after-ms'] || 1; 
       var retryAfter = Number(retryAfterHeader); 
       return setTimeout(toRetryIf429, retryAfter); 
      } else { 
       throw new Error(JSON.stringify(err)); 
      } 
     } else { 
      log('document saved successfully'); 
     } 
    }); 
};

注意，在上面的例子中document在createDocument的範圍內。這使得重試邏輯更簡單一些，但是如果您不喜歡使用大範圍的變量，那麼您可以將document傳入createDocument，然後將其傳遞給setTimeout調用中的lambda函數。

來源

2015-08-26 12:20:33

我剛剛重讀你的問題，並有一個更多的想法。 DocumentDB處理縮放的方式是通過集合的數量。因此，如果您需要超過2500 RU /秒，您應該劃分您的數據並使用第二個集合...即使您沒有接近一個集合的存儲容量。另一方面，如果你的穩定狀態遠低於2500RU /秒，但你不經常發生突發情況，那麼上面的429處理方法應該沒問題。 –

回答

相關問題