SQL Azure と Cosmos DB をメインにWindows Azureの情報を発信
Cosmos DBでデータモデリングをする際には、アクセスパターンに基づいてします。
これは、データモデリングをアクセスパターンに最適化させるためです。
パーティショニングは、全体的な性能、拡張性、費用の観点から重要なポイントです。
詳細は、
http://aka.ms/PracticalCosmosDB
が参考になります。
パーティショニングの選択を間違えた場合は、Change Feed経由でマイグレーションをします。
適切なパーティショニングなっているかは、パーティションを監視することが重要です。
Cosmos DB の重要機能に、Change Feedがあります。
Change Feedは、API経由で全てのSocmos Containerに提供されます。
Change FeedはAzure FunctionsやCosmos DB SDKを使用する任意のコードから利用できます。
使用例を考えてみましょう。
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を削減できます。
