Azure Cosmos DBとは？特徴や構造およびデータ形式について

＜目次＞

(１) Azure Cosmos DBとは？特徴や構造およびデータ形式について
　 (１-１) Azure Cosmos DBとは？
　(１-２) Azure Cosmos DBのデータ形式
　 (１-３) Azure Cosmos DBの主な特徴
　 (１-４) Azure Cosmos DBの構造について
　 (１-５) Azure Cosmos DBのマルチモデルAPIについて

(１) Azure Cosmos DBとは？特徴や構造およびデータ形式について

(１-１) Azure Cosmos DBとは？

「Azure Cosmos DB」はフルマネージド（運用作業をクラウド業者で実施）のNoSQL（非リレーショナルデータベース）です。世界中のリージョンにて利用できる事から、世界中のどこからアクセスしても10ミリ秒以下の高速な応答（クエリの応答）と、99.999%以上の可用性である事を強みとしています。

＞目次にもどる

(１-２) Azure Cosmos DBのデータ形式

特徴的な点として、データがJSON形式で格納されており、SQLの応答結果もJSON形式で返却されます。通常のテーブル・カラム型式のリレーショナルデータベースに慣れ親しんだ人からすると、少し不思議な感じですね。ただし、後述の「Azure Cosmos DBのマルチモデルAPI」の所でも触れますが、JSON形式だからといって皆さまが現在使われている型式のデータベースが使えない・移行できないという事ではなく、そうしたモデル型式の違いにも対応できる各種APIもあるのでMongo DBでもGremlinでも、色々と対応が可能です。

（図１１１）JSON形式のイメージ

＞目次にもどる

(１-３) Azure Cosmos DBの主な特徴

・①フルマネージドなDB

障害監視、パッチ適用、バックアップといった運用作業をクラウドプロバイダ（業者）が行ってくれます。

・②Turnkeyによるグローバル分散（Global Distribution）

どんな時でもGUIから数回のクリックで（あるいはプログラム経由の場合はAPIコール１つで）、Cosmos DBに紐づくリージョンを「追加」したり「除去」したりできます。

・③透過的なマルチマスターレプリケーション

またリージョン間のデータのレプリケーションは透過的（利用者が意識する必要なく）に、しかも数回のクリック操作だけで行う事ができます。それにより、システムの利用者はその人の居る地理的な場所から一番近いデータのレプリカにアクセスでき、レイテンシーが少ない高速アクセスを実現できます。

・④スループットのスケーリングが容易

Azure Cosoms DBにはスループットの単位として「Request Unit（略してRU）」（リクエスト／秒）があり、この値を千単位～億単位まで、ワンクリックで機動的に変更が可能です。この「Request Unit」はデータベースの使用量を計測する際の単位としても利用されます。１つのCRUD操作が何RUを消費するか？は実行する処理や規模によって異なってきます。

・⑤非常に低レイテンシー

99パーセンタイル（100個ある場合は小さい方から数えて99番目）の範囲で10msの速度での読み書きが可能です（世界中にリージョンがあるため、最も近く適したリージョンから読み書きする事で、世界中のアクセスを低レイテンシーで処理できる）。

・⑥データの一貫性を調整できる

リージョン間でのデータのレプリケーションを行う場合は「どれくらいリアルタイムで」コピーをしていくか？といった所がポイントとなりますが、性能とデータの一貫性のバランスを取りながら、利用者にて選択する事ができます。

・⑦スキーマ不要＆インデックス管理も自動

Azure Cosmos DBは通常のリレーショナルデータベースのようにスキーマ（テーブル、ビュー等のオブジェクトの論理集合）や、テーブルやカラムといった概念がなく、あくまでドキュメント（JSON形式のデータ）に対して処理を行います。またその際にインデックスの更新も自動で処理されるという特徴があります。加えてドキュメントのJSON形式のデータについても、常に必要なプロパティ（≒変数）は少なく（_rid、_etag、_selfなど）、制約の少なく自由度の高いデータを扱う事ができます。

・⑧パーティショニング

データベースにおける「パーティショニング」は一般的にテーブルを「パーティション」で区切る事によって、大きな表をフルスキャン（総なめ）する事なく、より早く目的のデータを特定するための仕組みです。Azure Cosmos DBでもこのようなパーディションの概念があり、コンテナ（Container）に含まれるデータを「パーティションキー」により「論理的」に区切る事によって、後はCosmos DBの方で自動的に「物理的」に区切る処理が行われます。

＞目次にもどる

(１-４) Azure Cosmos DBの構造について

Azure Cosmos DBの構造はざっくり次の図のようになっています。

（図１３１）

まずCosmos DBのリソース（Azureにおける各サービスの論理単位）が頂点にあり、その下に「データベース」（RDBの「データベース」相当）が１～複数個あり、更にその配下に「コンテナ」（RDBの「テーブル」相当）が１個～複数個あります。コンテナはCosmos DBにおけるスループット（Cosmos DBではRequest Unitと呼ぶ）やストレージ容量を調整する際の単位でもあります。そしてContainerの中にはitem（RDBの「カラム」相当）が１個～複数個あります。

（表）

Database Account	Azureのサブスクリプション配下に紐づく、Cosmos DBのリソース（＝サービス）です。１つのAzureサブスクリプション配下に最大50個の「Database Account」を紐づける事ができます。
Database	リレーショナルデータベースでいう所の「データベース」に相当します。 Azureサブスクリプション配下に「Database Account」を作成したら、次は「Database」、「Container」、「item」を作成していきます。１つの「Database Account」配下に複数の「Database」を作る事ができます。こちらも、複数のCosmos DBの「Container」を束ねる論理的な単位になります。
Container(s)	リレーショナルデータベースでいう所の「テーブル」に相当します。 Cosmos DBにおけるコンテナ（Contaier）はデータベースのオブジェクト（RDBでいう表、ビュー、インデックス等）に相当するもので、Cosmos DBにけるスケーリング（RU＝Request Unit＝リクエスト/秒の調整、ストレージ量の調整）の単位であり、Container単位でRUやストレージを調整していく事になります。また、リレーショナルデータベースにおける「パーティショニング」に似た機能があり、ユーザが指定した「パーティションキー」（論理）に基いて、自動的＆透過的（利用者が意識する必要なく）、物理的なパーティショニングを実施してくれます。
item(s)	リレーショナルデータベースでいう所の「行」に相当します。全てのCosmos itemには、システム側で共通的に使用するitemが含まれています。例えば以下のような項目があります。・「_rid」：各itemを一意に識別するための「id」・「_etag」：楽観排他制御のために使用される情報

＞目次にもどる

(１-５) Azure Cosmos DBのマルチモデルAPIについて

「マルチモデルAPI」はCosmos DBが５種類のデータベース（Mongo DB、Gremlin、Cassandra、Azure Table Storage、etcd）と互換するためのAPIです。

このAPIを使う事で、これら５種類のデータベースを使用するアプリケーションは、ほぼ改修なくそのままAPI経由でCosmos DBに接続する事が可能となります。例えばCassandra APIの場合だと、既存のCassandraアプリの「接続文字列」を変更するのみで、「Apache Cassandra」⇒「Azure Cosmos DBのCassandra API」への切り替えを実現できます。

（表）

●利用するAPI	●Containers （Containerが何として認識されるか？）	●items （itemが何として認識されるか？）
MongoDB	Collections （テーブル相当）	Documents （レコード相当）
Gremlin	Graphs （グラフ）	Node、Edges （ノード＝データエンティティ、エッジ＝ノード間の関係）
Cassandra	Table （表）	Row （行）
Azure Table Storage	Table （表）	Item （項目）
etcd	Key （キー）	Value （値）

＞目次にもどる