Microsoft Azure DocumentDBとAzure Table Storage
数年前から、Microsoftは「テーブルストレージ」と呼ばれる「NoSQL」キー/値ストレージを提供しています（ http://Azure.Microsoft.com/en-us/documentation/articles/storage-dotnet-how- to-use-tables / ）
テーブルストレージは、高いパフォーマンス、スケーラビリティ（パーティション分割による）、および比較的低コストを提供します。パーティションキーと行キーのみにインデックスを付けることができるテーブルの主な欠点-したがって、値のクエリを作成することは非常に非効率的です。
最近、Microsoftは「DocumentDB」と呼ばれる新しい「NoSQL」サービスを発表しました（ http://Azure.Microsoft.com/en-us/documentation/services/documentdb/ ）
プロパティのリストを保存する代わりに（Tablesのように）、DocumentDBはJSONオブジェクトを保存します。インデックス付けされているオブジェクト全体-したがって、保存されたオブジェクトのすべてのプロパティとネストされたプロパティに基づいて効率的なクエリを作成できます。
マイクロソフトによると、DocumentDBは高いパフォーマンスとスケーラビリティも提供します。
もしそうなら-なぜ誰もがDocumentDBよりもテーブルストレージを使用するのでしょうか？ DocumentDBはTablesと同じ機能を提供しているように見えますが、何かをインデックス化する機能などの追加機能を備えています。
誰かがDocumentDBとTable Storageを比較し、それぞれの長所と短所を強調できると嬉しいです。
どちらもNoSQLテクノロジーですが、大きく異なります。 Azure Tablesはシンプルなキー/値ストアであり、複雑なクエリなどの複雑な機能をサポートしていません（ほとんどの場合、パフォーマンスとコストの節約につながる完全なパーティション/テーブルスキャンが必要になります）、カスタムインデックス（インデックスは、 PartitionKeyとRowKeyのみ。現在、他のエンティティプロパティでインデックスを作成することはできず、PartitionKey/RowKeyの組み合わせ以外を検索するには、パーティション/テーブルスキャンが必要です。また、複数のエンティティの読み取り要求をバッチ処理することはできません（すべてのエンティティが同じパーティションに属している場合、バッチ書き込み要求を介してサポートされます）。 Azure Tablesの実際のアプリケーションについては、 [〜＃〜] here [〜＃〜] を参照してください。
データのニーズ（特にクエリに関するもの）が単純な場合（上記の例のように）、Azure Tablesは必要なものを提供します。価格設定、パフォーマンス、ストレージ容量により、DocDBを優先して使用することになります。たとえば、Azure Tables パフォーマンスターゲット は1秒あたり20.000操作です。 DocDBで同じレベルのパフォーマンスを取得しようとすると、かなり高い サービスコスト が得られます。また、Azureテーブルは、Azureストレージアカウントの容量によって制限されます（ 500TB ）。一方、DocDBストレージは、購入する容量ユニットによって制限されます。
テーブルサービスは主にキー値型のNOSQLであり、DocumentDBは（名前が示すとおり）ドキュメント型のNoSQLストアです。あなたが求めているのは、本質的に、これら2つのタイプのNOSQLアプローチの違いです。これに従って研究を形成すれば、確実に理解を深めることができるはずです。
物事を単純にするために、DocumentDBとTable Servicesの価格設定の違いを考慮することをお勧めします。これらのサービスのコストは互いに大きく異なるだけでなく、DocumentDBが「プロビジョニングファースト」モデルで動作し、テーブルサービスが純粋な消費ベースの価格で提供されるという事実から、比較/コントラストに関する手がかりが得られる場合があります。
これを聞いてみましょう。 Table Servicesの機能がニーズを十分に満たすのに、なぜDocumentDBを使用するのですか？ ;）現在のAzure DiagnosticsツールがAzure Storage Servicesをどのように使用しているか、Storage Metricsがそれ自体でAzure Storageをどのように使用して、Table Servicesがどれほど役立つか、ある状況でDocumentDBがどれだけ過剰になるかを把握することをお勧めします。
お役に立てれば。
比較は、パフォーマンスと取引価格のallであると思います。テーブルサービスは単なるストレージサービスであり、毎秒20,000 opsで上限に達しているように見えますが、そのような種類のスループットを常に支払うことは（ストレージが常に提供するため）月1,200ドルです。クレイジーマネー。
テーブルサービスには単純なインデックスがあるため、クエリは非常に制限されています。 IDを介して読み書きされるあらゆるものに適しています。 DocumentDBはドキュメント全体にインデックスを付けるため、任意のプロパティでクエリを実行できます。
そして最後に、Tableサービスは、DocumentDBストレージが無制限のように見えるストレージアカウントのストレージ制約（Microsoftとの直接の交渉を考えると非常に高くなる可能性があります）に縛られています。
だからバランスです。 1か所で必要な大量のデータ（数百ギガバイト、またはテラバイト）がありますか？ DocumentDB。複雑なクエリをサポートする必要がありますか？ DocumentDB。高速で行き来する必要があるが、1対2のプロパティルックアップに基づいたデータはありますか？テーブルサービス。スループットの代価を払わないようにするために、単純なインデックスをコード化する必要がありますか？テーブルサービス。
そして、Redis、誰かが言った...男、私は知らない。キャッシングフレームワーク（Redisが提供する）に永続性が存在しても、それが選択の技術に変わることはありません...「頻繁に使用されるが欠落している可能性のあるデータを保持する永続ストアには大きな違いがありますキャッシュがそうするように、そしてあなたのデータがそこにあることを保証する永続的なストアのように、「期限切れ」。
実際の例：
トークンをいくつか保存し、取得し、削除する必要があります。これまでに行われたクエリのみがユーザーIDに基づきます。
したがって、要件を完全に満たすため、テーブルストレージを使用します。ユーザーIDに対してトークンを保存します。
ドキュメントDBは、これには行き過ぎたようです。
Cosmos DB、Azure Table Storage、Azure SQL Databaseの一般的な属性：
99.99可用性SLA
完全に管理されたデータベースサービス
ISO 27001、HIPAAおよびEUモデル条項に準拠
次の表は、Azure Cosmos DB、Azure Table Storageの一般的ではない属性を示しています
