Microsoft AzureのNoSQLデータベース「Cosmos DB」における設計方法を知る

Microsoft AzureのNoSQLデータベース「Cosmos DB」を使ってみよう 第2回

　本連載では、Microsoft Azureのサービスラインナップの1つで、NoSQLデータベースのPaaSであるCosmos DBについて全4回（概要／設計／実装／運用）に分けて説明します。2回目の今回は、設計編としてCosmos DBを使い始める際に考慮すべきポイントについて説明します。なお、第1回ではサービスの旧名称である「DocumentDB」を本文中に使用していましたが、今回からは「Cosmos DB」に名称を統一しています。

対象読者

• Microsoft Azureや他のクラウドサービスを利用している方
• NoSQLデータベースを利用している方
• Cosmos DBの仕組みを理解したい方

検証環境

　本稿では、以下の環境で動作を確認しています。

• macOS Sierra 10.12.4
• Firefox 53.0.3
• Google Chrome 58

Cosmos DBにおける設計のポイント

　Cosmos DBをデータベースとして利用するための設計ポイントを、以下の3項目に分けて説明していきます。

• ドキュメントのデータモデリング
  • ドキュメント指向型データベースにおける一般的なモデリングに、Cosmos DBの特性を加味して検討します。

• データサイズとRUの見積もり
  • 課金に影響するこれら2つの要素に対するアプローチを紹介します。

• インデックス作成ポリシーの検討
  • Cosmos DBにおけるインデックス作成について説明し、効率的なインデックスの作成を目指します。

Cosmos DBの制約

　設計のポイントを説明する前に、設計を行う上で注意すべきCosmos DBのリソースにおける制限・制約について説明します。

　Cosmos DBのリソースの上限は、選択したプランによってそれぞれ異なります。

　表1は、各プランでのリソースの制限・制約をまとめたものです。

表1　プランごとのリソースの制限・制約

リソース	単一コンテナ（パーティション分割なし）	パーティション分割コンテナ
コレクションに割り当てられるストレージサイズ	10GB固定	10TB（※）
1ドキュメントのサイズ	2MB	2MB
ページあたりの応答サイズ	4MB	4MB
コレクションのスループット	400～10,000RU／秒	2,500～100,000RU／秒（※）

※ これ以上の容量やスループットを必要とする場合はサポート要求を出すによって上限を引き上げることができます。

 

　表中のパーティション分割とは、Cosmos DBがスケーラビリティを向上させるために、ドキュメントを物理リソース上に自動で分散配置する機能です。

図1　パーティション分割コンテナの概念

　パーティション分割コンテナでは、コレクションの作成時にパーティション分割するためのキーとなるJSONプロパティを指定する必要があります。このキーには、均等に分散している値を持つJSONプロパティを選ぶことが推奨されています。

　一般的には、ユーザーIDなどの必ずユニークとなる値を設定します。