:Table Store を使用すると、エラー 500 が時々返される

症状

Table Store を使用する場合、報告される一般的な 4xx および 5xx エラーには次のものがあります。

Table Store は排他的に配布される NoSQL サービスであるため、サーバーはデータ・ボリューム内のデータ量とアクセス条件に基づいて自動的に負荷を分散し、データ・サイズのシームレスなスケーリングを可能にし、通常は単一ホスト・サービス

Table Store は、第 1 の主キーのシーケンスに基づいてデータを異なるデータパーティションに分割し、データパーティションは読み書きサービスのために異なるサービスノードにスケジューリングされます。

データパーティションのデータやアクセス・ボリュームが大きすぎると、 Table Store 最初にこの状態を検出し、二つのデータパーティションにデータパーティションを分割して、下のサービスノードへの 2 つのデータパーティションをスケジュールするための動的負荷分散機能を使用していますより軽い荷重。次の図では、P1 は Table Store によって P1’ と P5 に次のように分割されています。

前述の例に示すように、 Table Store は、テーブルデータサイズの自動スケーリングを可能にし、手動の介入は必要ありません。ただし、データテーブルが作成されると、1 つのデータパーティションしか存在せず、読み書きの並行性が制限されます。その結果、自動ロードバランシングでもレイテンシが存在します。リクエスト機能のチケットを開いて、事前にデータテーブルを複数のデータパーティションに分割することができます。

Table Store は共有ストレージを使用し、データパーティションは論理単位です。ロード・バランシング中、データ・テーブル・メタデータはデータの移行なしに変更されます。メタデータが変更されると、データの一貫性を保つために、関連するデータパーティションが短期間無効になることがあります。 この期間は通常、数百ミリ秒と短く、データ・パーティションの負荷が大きい場合には数秒間続くことがあります。この期間中、データ・パーティションの読み取りまたは書き込みが行われると、500 エラーが報告されることがあります。この問題を解決するためにもう一度試すことができます。公式 SDK は、デフォルトでいくつかの再試行ポリシーを提供します。クライアントの初期化時に再試行ポリシーを指定できます。

Table Store は、標準的な RESTful API を提供します。制御不能なネットワーク環境のため、すべての読み取り/書き込み操作の再試行ポリシーを追加して、ネットワークエラーをある程度まで許容することをお勧めします。

注意: BatchWriteRow または BatchGetRow を使用して、複数の表または表の複数のデータ・パーティション間でバッチでデータの書き込みまたは読み取りを行うため、データ・パーティションが分割される可能性があるため、書き込みまたは読み取り操作は非アトミックです。操作はアトムから行のみです。200 個のメッセージが返されたとしても、失敗した行の応答で getFailedRows()をチェックする必要があります。