DocumentDBが返す「要求速度が大きい」、紺色の解析

Question

私は紺色（管理されたAzureサービスのパースサーバー）でパーズを実行しています。 データベースとしてDocumentDBを含めると、1秒あたりのリクエスト数に制限があります。 一部の解析クラウド関数が大きく、要求の速度が高すぎます（S3層の場合でも）。このエラーが発生します（Visual Studio Team Services（Visual Studio Online）とストリーミングログを使用して表示）。

error: Uncaught internal server error. { [MongoError: Message: {"Errors":["Request rate is large"]} 

ActivityId: a4f1e8eb-0000-0000-0000-000000000000, Request URI: rntbd://10.100.99.69:14000/apps/f8a35ed9-3dea-410f-a89a-28650ff41381/services/2d8e5320-89e6-4750-a06f-174c12013c69/partitions/53e8a085-9fed-4880-bd90-f6191765f625/replicas/131091039101528218s] 
    name: 'MongoError', 
    message: 'Message: {"Errors":["Request rate is large"]}\r\nActivityId: a4f1e8eb-0000-0000-0000-000000000000, Request URI: rntbd://10.100.99.69:14000/apps/f8a35ed9-3dea-410f-a89a-28650ff41381/services/2d8e5320-89e6-4750-a06f-174c12013c69/partitions/53e8a085-9fed-4880-bd90-f6191765f625/replicas/131091039101528218s' } MongoError: Message: {"Errors":["Request rate is large"]} 

ActivityId: a4f1e8eb-0000-0000-0000-000000000000, Request URI: rntbd://10.100.99.69:14000/apps/f8a35ed9-3dea-410f-a89a-28650ff41381/services/2d8e5320-89e6-4750-a06f-174c12013c69/partitions/53e8a085-9fed-4880-bd90-f6191765f625/replicas/131091039101528218s 
    at D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:673:34 
    at handleCallback (D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:159:5) 
    at setCursorDeadAndNotified (D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:501:3) 
    at nextFunction (D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:672:14) 
    at D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:585:7 
    at queryCallback (D:\home\site\wwwroot\node_modules\mongodb-core\lib\cursor.js:241:5) 
    at Callbacks.emit (D:\home\site\wwwroot\node_modules\mongodb-core\lib\topologies\server.js:119:3) 
    at null.messageHandler (D:\home\site\wwwroot\node_modules\mongodb-core\lib\topologies\server.js:397:23) 
    at TLSSocket.<anonymous> (D:\home\site\wwwroot\node_modules\mongodb-core\lib\connection\connection.js:302:22) 
    at emitOne (events.js:77:13) 

このエラーを処理するにはどうすればよいですか？

Answer 1

TL; DR;

1. 古いS3コレクションを新しい価格設定の新しい単一のコレクションにアップグレードします。これは最大10K RU（2500 RU以上）をサポートできます。
2. 古いS3コレクションを削除し、新しいパーティションコレクションを作成します。解析時にパーティション化されたコレクションのサポートが必要になります。
3. x-ms-retry-after-ms応答ヘッダーに沿ってバックオフ戦略を実装します。

ロング答えは：

DocumentDBに各要求は、その動作の要求電荷を有するHTTPヘッダーを返します。要求単位の数は、コレクションごとに構成されます。私の理解によれば、サイズS3のコレクションが1つあるので、このコレクションは1秒あたり2500リクエスト単位しか処理できません。

複数のコレクションを追加することで、DocumentDBの縮尺が変わります。 S1 - > S3を使用する古い設定では、これを手動で行う必要があります。つまり、一貫したハッシュ、地図または一時停止の日付などのアルゴリズムを使用してコレクションにデータを配信する必要があります。 DocumentDBの新しい価格設定では、パーティション化されたコレクションを使用できます。パーティションキーを定義することによって、DocumentDBによってデータが分割されます。 RequestRateTooLargeエラーが発生した場合は、パーティションをスケールアウトすることをお勧めします。ただし、Parseが一部のコレクションをサポートしているかどうかを調べる必要があります。

HTTP 429 RequestRateTooLargeを受信すると、x-ms-retry-after-msというヘッダーもあります。###ここで###は操作を再試行するまで待機するミリ秒数を示します。あなたができることは、操作を再試行するバックオフ戦略を実装することです。再試行中にクライアントがサーバーにハングしている場合は、要求キューを構築してサーバーを塞ぐ可能性があります。このようなバーストを処理するキューを追加することをお勧めします。短い要求の要求に対しては、これはコレクションを拡大することなくそれを処理する良い方法です。

Answer 2

私は外部のmongoDBデータベースとしてMlabを使用し、それをdocumentDBの代わりに使用するには、azureの解析アプリケーションを設定します。

私は "パフォーマンス"の向上のために多くを払う必要があります。