Microsoft Cosmos DBには、DocumentDB API、TableAPIなどが含まれています。約10個のデータがありますTB)キーと値の高速ルックアップが必要です(更新と書き込みはほとんどなく、ほとんどが読み取りです)。MicrosoftCosmosDBへのリンクを追加します:- https://docs.Microsoft.com/en-us/Azure/cosmos-db/
では、DocumentDBAPIとTableAPIのどちらを選択すればよいでしょうか。
DocumentDB API
とTable API
のどちらを選択するかは、主に、保存するデータの種類によって異なります。 DocumentDB API
はschema-less JSON database engine with SQL querying capabilities
を提供し、Table API
はkey-value storage database service
を提供します。データはkey-value
ベースであると述べたので、Table API
を使用することをお勧めします。
または、いつDocumentDB APIを選択する必要がありますか? Table APIはいつ選択する必要がありますか?
同上。
DcoumentDBAPIを使用して10 TBのデータを保存することをお勧めしますか?
Document DB API
とTable API
はどちらも、大量のデータを保存するように設計されています。
ただし、Azure Table Storage
も調べることをお勧めします。 Cosmos DBを使用すると、必要なスループットと堅牢なインデックス作成/クエリのサポートを微調整できますが、これにはコストがかかります。一方、Azure Tables
は、スループットが固定され、インデックス作成/クエリのサポートが制限されており、CosmosDBと比較して非常に安価です。
このリンクは、Cosmos DBの詳細を調べるのに役立つ場合があります: https://docs.Microsoft.com/en-us/Azure/cosmos-db/introduction 。
Azure Cosmos DB Table APIは、Cosmos DBとその高度なインデックス作成、地理分布などの機能をAzureTableストレージコミュニティで利用できるようにするために導入されました。アイデアは、CosmosDBによってのみ提供されるより高度な機能を必要とするAzureTableストレージを使用している人は、文字通り接続文字列を変更するだけで、既存のコードがCosmosDBで機能するというものです。
ただし、グリーンフィールドのお客様の場合は、TableAPIのスーパーセットであるSQLAPI(以前はDocument DB APIと呼ばれていました)を使用することをお勧めします。 SQL APIにさらに高度な機能を提供することに常に投資していますが、Table APIについては、長年変更されていないAzure TableStorageのAPIとの互換性を維持することを目指しています。
持っているデータの量は、選択するAPIに影響を与えません。どちらも同じマルチモデルインフラストラクチャを備えており、同じサイズのデータ、クエリの読み込み、分散などを処理できます。
これをトピック外としてフラグを立てないでください。
事前に知っておくと役立つ場合があります。ドキュメントインターフェイスを検討している場合、実際には、DataContractクラス(および他のすべてのクラス)がCosmosとの間でどのように変換されるかに影響を与える可能性のある大文字と小文字が区別されません。
以下のリンクされたディスカッションでは、Newtonsoft.Jsonで大文字と小文字が区別されないことがわかります。これは、APIから直接渡すまたは取得するオブジェクトの処理に影響を与える可能性があります。コスモスに欠陥があるわけではなく、実際、それは完全に優れています。しかし、ドキュメントAPIを使用すると、(私のように)DataContractオブジェクトをCosmosに単純に渡し始めることができます(これは明らかに間違いではなく、実際にはオブジェクトAPIから非常に期待されています)が、シリアライザーと命名戦略ハンドラーのオプションがいくつかあります。少なくとも前もって知っておくほうがよいでしょう。
したがって、オブジェクトインターフェイスでのこの動作に注意するためのメモを追加するだけです。議論はここGitHubにあります: