CosmosDBインスタンスでmongodbのシャーディングを使用する方法

Question

現在、Azure CosmosDBインフラストラクチャの上で実行されるマルチテナントのマルチドキュメントタイプのアプリケーションでMongoDBを使用して学習しています。

MSDNドキュメントのパーティションページ（つまりhttps://docs.microsoft.com/en-us/azure/cosmos-db/partition-data）は、DocumentDBを使用してCosmosと通信する場合のパーティション化戦略の実装方法を完全に説明していますが、使用時の処理方法MongoDB API。

私の考えは、基本的には、次のようになります。

• 単一のデータベース

• シングルコレクション

  どちらが安いの経験のためのコスモスモデルに自然にマッピングします。私はそれが最も安い選択肢であるため、標準サイズとして400 RUを目指しています。

• それぞれが独自の（セキュリティ、ユーザー、パフォーマンスなどの）懸念事項を持つアプリケーションに分離されたテナントにマッピングされるTenantIDプロパティと簡単なフィルタリングを可能にするDocumentTypeプロパティを持つ複数のタイプのドキュメント。

DocumentDB APIを使用すると、TenantIDをPartitionKeyとして使用するのは当たり前のことです。 MongoDB APIを使ってAzureに任せることはできますか？私は何か「手動で」する必要がありますか？

私はC＃APIを使用していますが、問題がある場合は設定が他の場所と似ていると想定しています。

Answer 1

モンゴーとコスモスのシャーディングメカニズムは、ビルド方法が異なります。したがって、プラットフォームを最大限に活用したい場合は、シャーディングキーをシステム間で変更する必要があります。

は必ずシャードキーが表現できる値の数を考えるモンゴDB http://learnmongodbthehardway.com/schema/sharding/

カーディナリティ

当接し、このサイトから取られました。可能な値が5035しかないシャーディングキーの は、 カーディナリティと見なされますが、数百万の数値を表現できるキャラクタは、カーディナリティーの高いキーと見なされる可能性があります。分割不可能な チャンクを避けるには、カーディナリティが高いカーディナリティー がカーディナリティーの低いキーよりも適しています。

だから、モンゴDBにあなたはコスモスDBのようにあなたは論理パーティションので、低カーディナリティのパーティションキーを対象とします

、およそ64メガバイトのチャンク（論理パーティション）をターゲットに高カーディナリティのpartionキーを持っていることになるでしょう10Gまでです