Azure Cosmos DBがマルチモデルであることはどういう意味ですか？
新しいAzure cosmosデータベースを見ると、マルチモデルの性質について少し混乱しています。具体的には、次のことを意味します：
a）同じコレクションに対してグレムリングラフクエリとmongodb apiの両方を使用できるように、同じ基になるデータベース/ストアを複数の方法で同時にクエリできること。
- または-
b）Cosmos DBのプロビジョニング時に別のモデル（グラフ、キー値、列、ドキュメント）を選択できることを意味しますか？.
パンフレットでは、a）のように聞こえますが、Azureダッシュボードを使用してcosmosインスタンスを作成すると、作成時にモデルタイプを選択する必要があるため、b）のように見えます。
さらに、文献では円柱データを参照していますが、作成時にそのオプションは表示されません。
Cosmos DBは、Document DBの進化版である単一のNoSQLデータエンジンです。コンテナ（「データベースインスタンス」）を作成する場合、使用ケースに最も関連するAPIを選択します。これにより、基になるデータストアとの対話方法と、そのストアへのデータの永続化方法が最適化されます。
そのため、選択したAPIに応じて、目的のモデル（グラフ、列、キー値、またはドキュメント）を基になるストアに投影します。
コンテナに対して使用できるAPIは1つだけです。データの保存方法と取得方法により、複数のAPIは使用できません。 APIは、ストレージモデル（グラフ、キー値、列など）を決定しますが、それらはすべて、内部の同じテクノロジーにマップし直します。
下の@Jesse Carterのコメントのおかげで、グラフとDocumentSQL APIを組み合わせることができます。
マルチモデル、マルチAPIサポート
Azure Cosmos DBは、ドキュメント、キー値、グラフ、列ファミリを含む複数のデータモデルをネイティブにサポートします。 Cosmos DBのデータベースエンジンのコアコンテンツモデルは、Atom-Record-Sequence（ARS）に基づいています。アトムは、string、bool、numberなどのプリミティブタイプの小さなセットで構成されます。レコードは、これらのタイプで構成される構造体です。シーケンスは、アトム、レコード、またはシーケンスで構成される配列です。データベースエンジンは、さまざまなデータモデルをARSベースのデータモデルに効率的に変換および投影できます。 Cosmos DBのコアデータモデルは、動的に型指定されたプログラミング言語からネイティブにアクセスでき、JSONとしてそのまま公開できます。
このサービスは、データアクセスとクエリのための一般的なデータベースAPIもサポートしています。 Cosmos DBのデータベースエンジンは現在、DocumentDB SQL、MongoDB、Azure Tables（プレビュー）、Gremlin（プレビュー）をサポートしています。一般的なOSS APIを使用して引き続きアプリケーションを構築し、バトルテスト済みで完全に管理されたグローバルに分散されたデータベースサービスのすべての利点を活用できます。
Cosmos DBは、その中心にある地理的に分散したデータベースであり、独自のAtom-Record-Sequenceストレージエンジンとインデックスを備えています。そのインフラストラクチャに加えて、SQL APIを使用するストアのようなSQLから、Mongo、Cassandra、Gremlin、Azure Table storageの実装など、さまざまな種類のストアを実装できます。
さまざまなストアタイプにはそれぞれ独自のデータタイプ（たとえば、数値、日付などのエンコード方法）があり、独自の方法でストレージおよびインデックスレイヤーにエンコードされます。時間が経つにつれて、これらのデータ型のほとんどがSQL APIによってネイティブにサポートされると予想されます。しかし、現在のところ、各データベースタイプは独自のエンコード規則を使用しています。 Cosmos DB（これは組織の単位であり、ユーザーは多くのアカウントを持つことができます）でアカウントを作成するときに、データベースの「タイプ」がアカウントで指定されます。したがって、Table APIアカウントまたはMongoアカウント、あるいはあなたが持っているものを持っていることができます。
場合によっては、API Yを使用してデータタイプXのアカウントにアクセスできます。たとえば、SQL APIを使用して、Table APIアカウントのテーブルと通信できます。しかし、グラフの外では、通常、それは素晴らしいアイデアではありません。現時点では、各APIの情報を特別な形式でエンコードしていますが、異なるデータ型はお互いの形式を話しません。そのため、SQL APIを使用してテーブルAPIに書き込む場合、最終結果はおそらくデータの破損です。
例外は、すべてのデータベースタイプで適切に動作することを確認するために一生懸命働くグラフです。これについては今後さらに詳しく説明します。
そのため、マルチAPIアクセスを試してみたい場合は、特定のアカウントに「ネイティブ」APIを使用しない場合に「読み取り専用」モードでのみ行うことを強くお勧めします。言い換えれば、Table APIからのSQL APIの読み取りをぜひお試しください。SQLAPIクライアントを使用してTable APIアカウントに書き込みをしないでください。
受け入れられた答えは、いくつかの点を見逃しています。
Cosmos DBはNoSQLデータベースですが、高度に分散されており、ストレージ形式はAtom-Record-Sequenceです。
なぜそれが重要なのですか？入力および出力形式としてJSONを受け入れることを知っています。これは、CosmosがデータをJSONとして保存することを意味するものではなく、実際にはどの形式でもかまいません。これは、Cosmosのマルチモデル性について推論するのに役立ちます。特定のモデルに従ってクエリを実行すると、おそらくデータの投影またはビューが得られます。
@JesseCarterは、Document APIとGraph APIを互換的に使用できることを既に説明しました。先週、Table APIが一般に発表されました。おそらく、このAPIもそれほど変わらないでしょう。
Spectologicのメンバーは、CosmosのCross-APIの使用法に関するニースのブログ投稿を書いており、マルチモデルは内部よりも化粧品であり、唯一の本当の例外はMongoだと指摘しています。興味深い部分は、「ポータルエクスペリエンスの切り替え」の章で指摘されています： https://blog.spectologic.com/2017/06/30/digging-into-cosmosdb-storage/
したがって、最終的にはGlobalDocumentDb vs. MongoDbに要約されます。
私もこれに興味があり、APIの使用状況の監査の観点からより多くのことを理解したいと思い、これらの回答からより多くの読書を学びました。
実験すると、元の答えよりも物事が進んでいるように見えるので、現代的なスピンを追加します...
SQL APIを選択してCosmos DBアカウントを正常に作成し、ポータルでドキュメントを作成し、MongoDB API経由でドキュメントを取得できました。
元の回答は、MongoDBが特異なものであり、他のAPIで作成されたデータとやり取りできないことを示唆していました。
完全なテストを行うと、Yaronが示唆するデータ型の違いによりドキュメントが破損するかどうか（ https://stackoverflow.com/a/48286729/141022 ）と、ストレージの違いが生じるかどうかまだパフォーマンスの低下が見られます。
私の目的のために、あるAPIを監査するだけで十分かどうかに興味があります。この場合、あるAPIで作成されたデータを別のAPIで取得できるわけではないため、徹底的なテストは行っていません。
特に、ARMテンプレートはGlobalDocumentDBとMongoDBのいずれの種類でもデプロイされませんが、ポータルからARMテンプレートをエクスポートすると、違いが生じるとGlobalDocumentDBになります。
マルチモデルとは、データはさまざまな方法で保存できるです。現在、CosmosDBには4種類のデータが格納されており、APIと統合して、これらのデータベースストレージタイプに関するユーザーエクスペリエンスを構築できます。 4つのタイプはDocument DBまたはMongo DB、Graph Database、Key Value Paire、およびWide ColumnまたはColumn Familyです。
CosmosDBの実装の詳細に興味がある場合は、昔からこのホワイトペーパーを読むことができます（実装が変更されていないと仮定します）。 http://www.vldb.org/pvldb/vol8/p1668-shukla.pdf
TLDR：
- 下部では、CosmosDBはデータをARSに保存し、JSON形式で公開します。
- データベースエンジンは、デフォルトですべてのドキュメントのすべてのフィールドにインデックスを付けるため、非常に柔軟なクエリが可能になります。
- データベースエンジンは、JavaScriptに似た中間言語を実行し、データベースが公開する低レベルのストレージとAPIをブリッジします。
- このブリッジングにより、さまざまなクエリメカニズム（SQL、ドキュメント、カラムナーなど）をサポートするデータベースAPIを追加できます。