AzureのDocumentDBを含むNoSQLタイプのデータベースはかなり新しいです。私はドキュメントを読んで基礎を理解しています。Azure DocumentDBデータモデリング、パフォーマンス＆価格
データモデリングに関するいくつかの質問、特に価格設定に関する質問がドキュメントに残されました。
マイクロソフトでは、コレクションごとに、特定のスキーマを持たないJSONオブジェクトのリストを収集します。正しく理解すると、コレクションごとに料金が発生します。
統一されたスキーマは必要ないので、コレクション自体にさまざまな種類のオブジェクトが含まれているという点で、あなたの「コレクション」が「データベース」に似ていると予想されますか？あるいは、それぞれの "コレクション"が類似のタイプのオブジェクトのみを含むという点で "コレクション"が "テーブル"に似ていると予想されます（おそらくオブジェクトのプロパティの違いを考慮して）。
ここではクエリのパフォーマンスに違いはありますか？
ありがとうございました！
DocumentDBの通常のパターンは、さまざまなタイプのオブジェクトを同じ「コレクション」に格納することです。あなたはフィールドtype = "MyType"またはisMyType = trueのいずれかを使ってそれらを区別します。後者は、サブクラス化とmixinの動作を可能にします。
パフォーマンスに関して、DocumentDBは、選択したスループットに対して10msの読み取り/ 15msの書き込みレイテンシを保証します。実動システムでは、すべてを1つの大きな「パーティション化されたコレクション」に入れ、必要に応じてサイズとスループットのレバーを時間の経過と共にスライドさせ、要求をロードします。基本的に無限のスケーラビリティが得られ、スループットとサイズレバーを増やす（または減らす）と同時に、DocumentDBはリソース（セカンダリ、パーティションなど）の割り当て（および割り当て解除）を行います。
コレクションはデータベースに似ていますが、リレーショナルテーブル以外のコレクションもあります。通常、タイプ間を区別するために文書内にtypeプロパティを格納し、特定のタイプに制限する場合は、それぞれのクエリにAND type='MyType'フィルタを追加します。
インデックス付きのプロパティ（型）に対して別のフィルタを追加するだけなので、同じコレクション内に異なる種類のドキュメントを保存すると、クエリのパフォーマンスは大きく変わりません。しかし、1つのコレクションにスループットをプールし、各タイプ/コレクションごとに少量のスループットを分散させることでメリットが得られます。