蒼の王座

Cosmos DBは、Cosmos Accountが上位にあります。
そして、どこにデータを配置するのかのリージョンを選択します。

Accountには、Cosmos Databaseがぶら下がります。
Csomos Databaseに、Cosmos Containersが紐づきます。
Cosmos Containersに、Cosmos Itemsがぶら下がります。

Cosmos Containersは、Cosmos APIによって、Container、Table、Graphなどのインターフェイスが提供されます。
ストアドプロシージャー、ユーザー定義関数、トリガー、コンフリクト、ユーザマージプロシージャなどの機能が提供されています。
コンテナーレベルのRUsは、単体コンテナーに影響をします。

Cosmos Itemsは、Cosmos APIによって、Document、ROｗ、Node、Edgeなどの形態で提供されます。

データベースレベルのRUsは、コンテナー全体で共有されます。

Cosmos Databaseの管理単位はコンテナーです。
データベースはスキーマセットで構成されます。
Cosmos コンテナーはスループットとストレージの拡張単位です。

Cosmos DBでデータモデリングをする際には、アクセスパターンに基づいてします。

1. 最初にアクセスパターンを特定します
2. 特定したアクセスパターンに基づいて、データモデルをデザインします

これは、データモデリングをアクセスパターンに最適化させるためです。

パーティショニングは、全体的な性能、拡張性、費用の観点から重要なポイントです。
詳細は、

http://aka.ms/PracticalCosmosDB

が参考になります。

パーティショニングの選択を間違えた場合は、Change Feed経由でマイグレーションをします。
適切なパーティショニングなっているかは、パーティションを監視することが重要です。

Cosmos DB の重要機能に、Change Feedがあります。
Change Feedは、API経由で全てのSocmos Containerに提供されます。
Change FeedはAzure FunctionsやCosmos DB SDKを使用する任意のコードから利用できます。

使用例を考えてみましょう。

1. 異なる/複数のパーティションキー用に他のコンテナーに複製する
2. コンテナー間の非正規化
3. イベントドリブン　アーキテクチャ用のトリガーAPI
4. リアルタイムのストリーム処理とマテリアライズビュー用
5. セカンダリデータストアへのデータの移動やアーカイブ

Cosmos DB でデータをモデル化する方法として、参照モデルと埋め込みモデルの2種類があります。
参照モデルがいわゆる、リレーショナルデータベースでの正規化をベースとしたモデリングとなります。

参照モデルとしては、種類ごとにドキュメントを分離し、1つのPostに複数のCommentが紐づいたりします。
それぞれが独立していて、個別に更新されます。

それに対して、埋め込みモデルは、１つのドキュメントに複数のデータを内在させます。
１つのPostに複数のCommentを内在させます。
内在しているので、Itemを更新すると同時に更新することになります。

Cosmos DBで性能とRU/sを考慮したモデルリングをしていく際には、埋め込み型を使用したほうがいいケースがあり、モデルリング時にはどちらが最適化を考慮する必要があります。

データモデルを設計する方法として、従来からあるのがリレーショナルな方法です。
一つのエンティティを一つのテーブルに入れて、一つのコンテナーに格納する方法です。
しかし、これはCosmos DBの場合は非効率になるケースが多々あります。

Cosmos DB らしい設計をするには、「type」プロパティを持たせて、種類はプロパティで表現します。
PostとCommentsは同じPostIdでパーティショニングして、同じコンテナーに格納させるべきです。

postもcommentsも同じコンテナーに格納し、区別はtypeでします。

コンテナーに複数のEntityタイプを格納することは、Cosmos DBの場合良い設計になることが多いです。
スキーマーに依存しないCosmos DB標準のレバレッジをかけられ巣。
類似したパターンを共有し、同じパーティションキーで一つのクエリにすることでRU/sを削減できます。

FYI:　CosmosDB のデータモデリングの勘所