コスモスDB

Azure の Cosmos DB

開発者	マイクロソフト
初回リリース	2017 ; 7年前 (2017)
利用可能	英語
タイプ	マルチモデルデータベース
Webサイト	learn.microsoft.com/en-us/azure/cosmos-db/introduction

Azure Cosmos DB は、 Microsoftが提供するグローバルに分散されたマルチモデル データベース サービスです。これは、最新のアプリケーションに高可用性、スケーラビリティ、低レイテンシのデータ アクセスを提供するように設計されています。従来のリレーショナル データベースとは異なり、Cosmos DB はNoSQL (「ゼロ SQL」ではなく「SQL だけではない」という意味) およびベクター データベースです。^[1]つまり、非構造化、半構造化、構造化、ベクター データ型を処理できます。^[2]

内部的には、Cosmos DB は「アイテム」を「コンテナ」に格納します。^{[3]これらの 2 つの概念は、使用される}APIに応じて異なる方法で表現されます(たとえば、MongoDB 互換 API を使用する場合は、「コレクション」内の「ドキュメント」になります)。コンテナは「データベース」にグループ化されます。これは、コンテナの上の名前空間に似ています。コンテナはスキーマに依存しないため、アイテムを追加するときにスキーマは適用されません。

デフォルトでは、各項目のすべてのフィールドに自動的にインデックスが付けられ、特定のクエリ パターンに調整しなくても通常は良好なパフォーマンスが得られます。これらのデフォルトは、インデックス ポリシーを設定することで変更できます。インデックス ポリシーでは、フィールドごとに必要なインデックスの種類と精度を指定できます。Cosmos DB では、次の 2 種類のインデックスが提供されています。

• 範囲、範囲および ORDER BY クエリのサポート
• 空間、標準のGeoJSONフラグメントでエンコードされたポイント、ポリゴン、ライン ストリングからの空間クエリをサポート

コンテナはデータの整合性を確保するために一意のキー制約を強制することもできます。^[4]

各 Cosmos DB コンテナーは変更フィードを公開しており、クライアントはこれをサブスクライブすることで、コンテナー内で新しい項目が追加または更新されたときに通知を受け取ることができます。^[5] 2021 年 6 月 7 日現在、項目の削除は変更フィードによって公開されていません。変更は Cosmos DB によって永続化されるため、コンテナーの作成以降の任意の時点から変更を要求することができます。

コンテナー レベルで「Time to Live」(TTL) を指定すると、Cosmos DB は秒単位で表された一定時間が経過するとアイテムを自動的に削除します。このカウントダウンはアイテムの最後の更新後に開始されます。必要に応じて、TTL をアイテム レベルでオーバーロードすることもできます。

前のセクションで説明した内部データ モデルは、以下を通じて公開されます。

• 独自の SQL API。
• 5 つの異なる互換性 API は、 MongoDB、Gremlin、Cassandra、Azure Table Storage、etcdのワイヤ プロトコルと部分的に互換性のあるエンドポイントを公開します。これらの互換性 API により、互換性のあるアプリケーションは標準ドライバーまたは SDK を介して Cosmos DB に接続して使用できるようになり、パーティション分割やグローバル分散などの Cosmos DB のコア機能も活用できます。

SQL APIを使用すると、クライアントはコンテナーとアイテムを作成、更新、削除できます。アイテムは、読み取り専用のJSON対応SQL方言でクエリできます。^[8] Cosmos DBにはJavaScriptエンジンが組み込まれているため、SQL APIでは次のことも可能になります。

• ストアド プロシージャ。任意の複雑な操作とロジックのセットをACID準拠のトランザクションにまとめる関数。ストアド プロシージャの実行中に行われた変更から分離され、すべての書き込み操作が成功するか失敗するかのいずれかになり、データベースは一貫した状態になります。ストアド プロシージャは単一のパーティションで実行されます。したがって、パーティション化されたコレクションを呼び出すときは、呼び出し元がパーティション キーを提供する必要があります。ストアド プロシージャは、特定の機能の不足を補うために使用できます。たとえば、集計機能の不足は、^{オープン ソースの documentdb-lumenize [9]}プロジェクトでストアド プロシージャとしてOLAP キューブを実装することで補われます。
• トリガー。特定の操作（たとえば、ドキュメントの挿入など）の前または後に実行される関数で、操作を変更したり、キャンセルしたりできます。トリガーは要求があった場合にのみ実行されます。
• ユーザー定義関数(UDF)。SQL クエリ言語から呼び出して拡張し、制限された SQL 機能を補うことができる関数です。

SQL APIはREST APIとして公開されており、それ自体はMicrosoftによって公式にサポートされているさまざまなSDKに実装されており、.NET Framework、.NET、^[10] Node.js（JavaScript）、Java、Pythonで利用できます。

Cosmos DB は、2016 年にパーティション コンテナーの導入により自動パーティション分割機能を追加しました。バックグラウンドでは、パーティション コンテナーは複数の物理パーティションにまたがり、アイテムはクライアントが指定したパーティション キーによって分散されます。Cosmos DB は、サイズとスループットのニーズに応じて、データを分散するパーティションの数を自動的に決定します。パーティションが追加または削除されると、ダウンタイムなしで操作が実行されるため、新しいパーティションまたは残りのパーティション間でデータが再調整されている間もデータは使用可能です。

パーティション分割されたコンテナーが利用可能になる前は、データをパーティション分割するためのカスタム コードを記述するのが一般的で、一部の Cosmos DB SDK は複数の異なるパーティション分割スキームを明示的にサポートしていました。このモードは現在でも利用可能ですが、ストレージとスループットの要件が 1 つのコンテナーの容量を超えない場合、または組み込みのパーティション分割機能がアプリケーションのニーズを満たさない場合にのみ推奨されます。

開発者は、アプリケーションの予想される負荷に合わせて必要なスループットを指定できます。Cosmos DB は、要求されたスループットを保証するためにリソース (メモリ、CPU、 IOPS ) を予約し、99パーセンタイルで読み取りと書き込みの両方で要求の待機時間を 10 ミリ秒未満に維持します。スループットは、1 秒あたりの要求単位 (RU) で指定されます。1 KB の項目を読み取るコストは、1 要求単位 (または 1 RU) です。'id' による選択操作では、同じドキュメントの削除、更新、挿入操作と比較して、RU の数が少なくなります。大規模なクエリ (カウントなどの集計など) やストアド プロシージャの実行では、必要な操作の複雑さに応じて、数百から数千の RU が消費されることがあります。^[11]最小課金は時間単位です。

スループットは、コンテナー レベルまたはデータベース レベルのいずれかでプロビジョニングできます。データベース レベルでプロビジョニングすると、スループットはそのデータベース内のすべてのコンテナー間で共有され、一部のコンテナーに専用のスループットを割り当てることもできます。Azure Cosmos コンテナーにプロビジョニングされたスループットは、そのコンテナー専用に予約されます。^[12]データベースごとおよびコンテナーごとにプロビジョニングできる既定の最大 RU は 1,000,000 RU ですが、顧客はカスタマー サポートに問い合わせることでこの制限を増やすことができます。

コストの例として、単一リージョンインスタンスを使用して、5秒間に1,000,000件の1kレコードをカウントするには、1,000,000 RUが必要です。0.008 ドル/時間、つまり800 ドルになります。リージョンが 2 つあるとコストは 2 倍になります。

Cosmos DB データベースは、Microsoft Azure のどのリージョンでも利用できるように構成できます (2018 年 12 月現在 54 リージョン)。これにより、アプリケーション開発者は、ユーザーのいる場所の近くにデータを配置できます。^[13]各コンテナーのデータは、構成されたすべてのリージョン間で透過的に複製されます。リージョンの追加や削除は、ダウンタイムやパフォーマンスへの影響なしに実行されます。Cosmos DB のマルチホーミング API を活用することで、リージョンが追加または削除されたときにアプリケーションを更新または再デプロイする必要がなくなります。Cosmos DB は、利用可能なリージョンに、その場所に最も近いリージョンにリクエストを自動的にルーティングします。

Cosmos DBではデータの一貫性を構成可能で、アプリケーション開発者は5つの異なるレベルから選択できます。^[14]

• Eventual は順序付けを保証せず、レプリカが最終的に収束することだけを保証する。
• 一貫性のあるプレフィックスは、最終的な順序保証を追加します。
• セッションは単一のクライアント接続に限定され、基本的に各クライアントの読み取り/書き込みの一貫性を保証します。これはデフォルトの一貫性レベルです^[15]
• 境界付き古さは、読み取りがアイテムの x バージョンまたは指定された時間枠を超えて遅れないようにすることで、一貫したプレフィックスを強化します。
• 強い一貫性（または線形化可能）により、クライアントは常にグローバルにコミットされた最新の書き込みを読み取ることができる。

望ましい一貫性レベルはアカウントレベルで定義されますが、特定のHTTPヘッダーまたはSDKによって公開される対応する機能を使用して、リクエストごとに上書きすることができます。5つの一貫性レベルはすべてTLA+仕様言語を使用して指定および検証されており、TLA+モデルはGitHubでオープンソース化されています。^[16]

Cosmos DB の元の分散モデルでは、1 つの書き込みリージョンのみで、他のすべてのリージョンは読み取り専用レプリカです。2018 年 3 月、Microsoft は Azure Cosmos DB の新しいマルチマスター機能を発表しました。これにより、複数のリージョンが書き込みレプリカとして機能できるようになりました。この機能により、他のリージョンが読み取り専用だった元の単一書き込みリージョン モデルが大幅に改善されました。マルチマスターでは、異なるリージョンからの同時書き込みによって潜在的な競合が発生する可能性がありますが、これはデフォルトの「Last Write Wins」(LWW) ポリシーまたは JavaScript 関数などのカスタム競合解決メカニズムを使用して解決できます。LWW ポリシーでは、タイムスタンプに基づいて書き込みの勝者を決定しますが、カスタム オプションでは、開発者がアプリケーション定義のルールを通じて競合を処理できます。^[17]

2020 年 5 月に発表されたこの機能^[18]は、トランザクション ワークロードに影響を与えることなく、Azure Cosmos DB の運用データに対する大規模な分析を可能にする、完全に分離された列ストアです。この機能は、オンライン分析処理を実行するために最適化されたデータ リポジトリが必要な従来のETLパイプラインで発生する複雑さと待機時間の課題に対処します。これは、運用データを、大規模な分析クエリを最適化された方法で実行するのに適した別の列ストアに自動的に同期することで解決し、その結果、そのようなクエリの待機時間が改善されます。

Cosmos DB用のMicrosoft Azure Synapse Link ^[19]を使用すると、Synapse AnalyticsからAzure Cosmos DB分析ストアに直接リンクすることで、ETLなしのハイブリッドトランザクション/分析処理ソリューションを構築できます。これにより、運用データに対してほぼリアルタイムの大規模な分析を直接実行できます。

ガートナー・リサーチは、2016年のマジック・クアドラント運用データベース管理システムにおいてマイクロソフトをリーダーに位置付けており^[20]、そのレポートの中でCosmos DBの独自の機能について言及しています。

マイクロソフトは、 Microsoft Office、Skype、Active Directory、Xbox、MSNなど、多くの自社アプリでCosmos DBを利用しています^[21]。

よりグローバルに回復力のあるアプリケーション/システムを構築するために、Cosmos DBはAzure App ServicesやAzure Traffic Managerなどの他のAzureサービスと組み合わせます。^[22]

Cosmos DB Profiler クラウド コスト最適化ツールは、アプリケーションと Cosmos DB データベース間のやり取りにおける非効率的なデータ クエリを検出します。プロファイラーは、無駄なパフォーマンスと過剰なクラウド支出をユーザーに警告します。また、コードを分離して分析し、正確な場所にユーザーを誘導することで、それらの解決方法も推奨します。^[23]

• SQLには制限があります。集計はCOUNT、SUM、MIN、MAX、AVG関数に制限されており、GROUP BYやデータベースシステムにあるその他の集計機能はサポートされていません。ただし、ストアドプロシージャを使用してデータベース内の集計機能を実装することはできます。^[24]
• 「テーブル」間のSQL結合は不可能です。
• 純粋な JSON データ型のみをサポートします。最も顕著なのは、Cosmos DB が日時データに対応していないことです。このデータは、使用可能なデータ型を使用して保存する必要があります。たとえば、ISO-8601 文字列またはエポック整数として保存できます。Cosmos DB が最もよく比較されるデータベースであるMongoDB は、BSON バイナリ シリアル化仕様で JSON を拡張し、従来の数値型、正規表現、および Undefined に加えて、日時データもカバーしています。ただし、 Cosmos DB が純粋な JSON を選択していることは、JSON ベースの REST API やデータベース^に組み込まれた JavaScript エンジンに適しているため、実際には利点であると主張する人が多くいます [ 誰^{? ] 。}

• 公式サイト