cosmic

Cosmos DBの性能はRu/s単体で、あらかじめプロビジョニングしておくことで性能を確保しておくことができます。

プロビジョニングスループットは、2種類の単位で設定することができます。
データベース単位とコンテナー単位です。

データベース単位のスループット設定は、複数のテナントアプリ用に便利です。
ユーザーをコンテナーで表現できます。
NoSQL/RMDBを移行するとき、DBレベルのスループットは論理的には同じですが、よりコスト効率が高く柔軟性があります。

コンテナー単位のスループット設定は、特定コンテナーのスループットを保証したいときに使用します。

image

cosmic

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、ROw、Node、Edgeなどの形態で提供されます。

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

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

image

cosmic

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

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

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

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

http://aka.ms/PracticalCosmosDB

が参考になります。

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

image

cosmic

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

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

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

image

cosmic

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

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

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

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

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

image