DocumentDBで最も困難なことの1つは、毎日アプリケーションを実行するために必要な要求単位数（RU/s）の数だけでなく、使用スパイク中にも求められます。これが間違っていると、DocumentDBクライアントは例外をスローします。これは恐ろしい使用モデルです。DocumentDB OfferThroughputをコードに設定する必要がありますか？
DocumentDBサンプルで新しいコレクションを作成するときに、OfferThroughput値が400にハードコーディングされていることがわかりました（これは最も低いRU/sのようです）。 Azureのポータルに設定するのが最善だと思っていたので、コードを変更することなく動的に変更することができます。
コードで設定するシナリオはどのようなものが優先されますか？
AzureポータルとSDKの両方とも、REST API（https://msdn.microsoft.com/en-us/library/azure/mt632095.aspx）を使用してコレクションのスループットを更新します。ポータルは、DocumentDBのJavaScriptクライアント側SDKを使用します。そのため、優先順位や優先順位はありません。更新の最後の呼び出しはコレクションで有効になります。
コードで提供されるシナリオとポータルで提供されるシナリオの設定は、環境設定や展開プロセスによって異なります。プロダクションアプリケーションの場合、簡単に自動化できるのでコードは優れています。スループットを動的に変更することも、多数のコレクションの設定から一貫して行うこともできます。
DocumentDBの購買スループットのプロビジョニングモデルは、非常にクラウドではないようです。実際には、スパイクが必要とする最高レベルのプリプロビジョニングを行っているか、Azure SDKを使用してスループットを上げたり下げたりするために何かをコーディングしています（複数の場合に悪夢となります）そのコレクションに対するスパイクのソース）。
価格設定モデルはばかげている。基本的なアーキテクチャ（特に250GBの層）は、とにかく拡張性があると思われるので、使用ごとに料金を請求するだけです。
動的であるために、はと書いてあります。Azureにはルール指向の解決策がないようです。