3

元は約200行のExcelファイルがあり、Excelファイルをデータテーブルに変換でき、すべてがdocumentdbに正しく挿入されました。

Excel ファイルには現在 5000 行あり、30 ～ 40 レコードの挿入後に挿入されず、残りのすべての行が documentdb に挿入されません。

以下のような例外を見つけました。

Microsoft.Azure.Documents.DocumentClientException: 例外: Microsoft.Azure.Documents.RequestRateTooLargeException、メッセージ: {"エラー":["要求率が大きい"]}

私のコードは次のとおりです。

    Service service = new Service();
    foreach(data in exceldata) //exceldata contains set of rows
    {
    var student = new Student();
    student.id= "";
    student.name = data.name;
    student.age = data.age;
    student.class = data.class;
    student.id = service.savetoDocumentDB(collectionLink,student); //collectionlink is a string stored in web.config
    students.add(student);
    }

Class Service
{
 public async Task<string> AddDocument(string collectionLink, Student data)
        {
            this.DeserializePayload(data);
            var result = await Client.CreateDocumentAsync(collectionLink, data);
            return result.Resource.Id;
        }
}

私は何か間違ったことをしていますか？どんな助けも非常に高く評価されます。

4

1 に答える 1

4

更新：

4/8/15 の時点で、DocumentDB は、JSON ファイル、MongoDB、SQL Server、および CSV ファイルをサポートするデータ インポート ツールをリリースしました。ここで見つけることができます: http://www.microsoft.com/en-us/download/details.aspx?id=46436

この場合、Excel ファイルを CSV として保存し、データ インポート ツールを使用してレコードを一括インポートできます。

元の回答:

DocumentDB コレクションは、1 秒あたり 2,000 要求単位でプロビジョニングされます。注意することが重要です - 制限はリクエスト単位ではなくリクエスト単位で表されます。そのため、大きなドキュメントを書き込むと小さなドキュメントよりもコストがかかり、スキャンはインデックス シークよりもコストがかかります。

SDK によって返された/オブジェクトのx-ms-request-chargeHTTP 応答ヘッダーまたはRequestChargeプロパティを調べることで、任意の操作 (CRUD) のオーバーヘッドを測定できます。ResourceResponseFeedResponse

プロビジョニングされたスループットを使い果たすと、RequestRateTooLargeException がスローされます。いくつかのソリューションは次のとおりです。

  • 少し遅れてバックオフし、例外が発生するたびに再試行してください。推奨される再試行遅延は、x-ms-retry-after-msHTTP 応答ヘッダーに含まれています。または、短い遅延でリクエストを単純にバッチ処理することもできます
  • 遅延インデックス作成を使用して、取り込み速度を高速化します。DocumentDB では、コレクション レベルでインデックス作成ポリシーを指定できます。デフォルトでは、インデックスはコレクションへの書き込みごとに同期的に更新されます。これにより、クエリは、インデックスが「追いつく」ための遅延なしに、ドキュメントの読み取りと同じ一貫性レベルを尊重できます。レイジー インデックス作成を使用すると、コンテンツのインデックス作成に必要な作業を長期間にわたって償却できます。ただし、遅延インデックス作成が有効になっている場合、DocumentDB アカウントに構成されている整合性レベルに関係なく、クエリ結果は最終的に整合性が保たれることに注意してください。
  • 前述のように、各コレクションには 2,000 RU の制限があります。複数のコレクションとキャパシティー ユニット間でデータをシャーディング/パーティション分割することにより、スループットを向上させることができます。
  • 空のコレクションを削除して、プロビジョニングされたすべてのスループットを利用する - DocumentDB アカウントで作成されたすべてのドキュメント コレクションには、プロビジョニングされたキャパシティ ユニット (CU) の数と作成されたコレクションの数に基づいて、予約されたスループット容量が割り当てられます。1 つの CU で 2,000 の要求ユニット (RU) が利用可能になり、最大 3 つのコレクションがサポートされます。CU に対して作成されたコレクションが 1 つだけの場合、CU スループット全体がコレクションで使用可能になります。2 番目のコレクションが作成されると、最初のコレクションのスループットは半分になり、2 番目のコレクションに割り当てられます。コレクションごとに利用できるスループットを最大化するには、コレクションに対するキャパシティー ユニットの数を 1:1 にすることをお勧めします。

参考文献:

于 2015-01-28T07:47:51.797 に答える