Azure Cosmos DB for Table についてよく寄せられる質問

これまで Azure Table Storage を使っていたユーザーが Azure Cosmos DB for Table でテーブルを作成する場合、知っておく必要のある動作の違いがいくつかあります。

• Azure Cosmos DB for Table ではパフォーマンスを保証するために予約容量モデルが使われていますが、これは、テーブルが作成されると直ちに、たとえ容量が使われていない場合でも、容量に対して課金されることを意味します。 Azure Table Storage では、使用された容量に対してのみ課金されます。 Table 用 API では 99 パーセンタイルで 10 ミリ秒の読み取り SLA と 15 ミリ秒の書き込み SLA が提供されるのに対し、Azure Table Storage で提供される SLA が 10 秒であるのは、このためです。 ただし、その結果として、Table 用 API のテーブルでは、要求が含まれない空のテーブルであっても、Azure Cosmos DB が提供する SLA でテーブルへの要求を処理できる容量を確保するためにコストがかかります。

• Table 用 API によって返されるクエリ結果は、Azure Table Storage のようなパーティション キーと行キーの順序にはなりません。

• 行キーに許される最大長は 255 バイトです。

• バッチに含めることができるのは最大 2 MB です。

• CORS は現在サポートされていません。

• Azure Table Storage ではテーブル名の大文字と小文字は区別されませんが、Azure Cosmos DB for Table では区別されます。

• 現在、バイナリ フィールドなどのエンコード情報に対する Azure Cosmos DB の内部形式の一部は、それほど効率的ではありません。 そのため、データ サイズの予期しない制限が発生する可能性があります。 たとえば、現在、エンコードによってデータ サイズが増加するため、フル 1 メガのテーブル エンティティを使用してバイナリ データを格納することはできません。

• Azure Cosmos DB では、エンティティ プロパティ名 ID、rid、etag、および ResourceId を予約しており、現在サポートされていません。

• TableQuery TakeCount は 1,000 に制限されません。

• REST API の観点では、Azure Table Storage では次のエンドポイントとクエリ オプションがサポートされています (ただし、Azure Cosmos DB for Table ではサポートされていません)。

  残りのメソッド	REST エンドポイント/クエリ オプション	ドキュメントの URL	説明	Table Storage ではサポート対象	Table 用 API ではサポート対象
  GET、PUT	/?Restype=service@comp=properties	「Set Table Service Properties」(Table Service のプロパティを設定する) および「Get Table Service Properties」(Table Service のプロパティを取得する)	このエンドポイントは、CORS ルールの設定、ストレージ分析の構成、ログ記録の設定に使われます。 CORS は現在サポートされておらず、Azure Cosmos DB での分析とログ記録の処理は Azure Storage Table とは異なります。	はい	いいえ
  OPTIONS	/<table-resource-name>	プレフライト CORS テーブル要求	これは、Azure Cosmos DB が現在サポートしていない CORS の一部です。	はい	いいえ
  GET	/?Restype=service@comp=stats	「Get Table Service Stats」(Table Service の統計情報を取得する)	プライマリとセカンダリの間でデータがレプリケートされる速度の情報を提供します。 Azure Cosmos DB ではレプリケーションは書き込みの一部なので、これは必要ありません。	はい	いいえ
  GET、PUT	/mytable?comp=acl	「Get Table ACL」(テーブルの ACL を取得する) およびSet Table ACL」(テーブルの ACL を設定する)	Shared Access Signature (SAS) の管理に使われる保存されたアクセス ポリシーを取得および設定します。	はい	いいえ

• Azure Cosmos DB for Table は JSON 形式のみをサポートし、ATOM はサポートしません。

• 特に .NET SDK には、Azure Cosmos DB が現在サポートしていないクラスとメソッドがいくつかあります。

  • CloudTableClient クラス
    • \ServiceProperties
    • \ServiceStats
  • CloudTable クラス
    • SetPermissions
    • GetPermissions

いいえ、既存のストレージ SDK でまだ動作するはずです。 ただし、最善のサポートと、多くの場合に優れたパフォーマンスを得るために、常に最新の SDK を使うことをお勧めします。 使うことができる言語の一覧については、Azure Cosmos DB for Table の概要に関する記事をご覧ください。

接続文字列は次のとおりです。

DefaultEndpointsProtocol=https;AccountName=<AccountNamefromCosmosDB;AccountKey=<FromKeysPaneofCosmosDB>;TableEndpoint=https://<AccountName>.table.cosmosdb.azure.com

接続文字列は、Azure Portal の [接続文字列] ページから取得できます。

一部の設定は CreateCloudTableClient メソッドで処理され、他の設定はクライアント アプリケーションの appSettings セクションの app.config で処理されます。 構成設定については、「Azure Cosmos DB の機能」をご覧ください。

[なし] : 既存の Azure Table Storage SDK を使用する既存または新規のお客様を対象とする変更はありません。

Azure Portal を使用してデータを参照できます。 また、Table 用 API のコードまたは次の回答で説明するツールを使うこともできます。

Azure Storage Explorer を使うことができます。

以前に指定した形式の接続文字列を取得する柔軟性を備えたツールは、新しい Table 用 API に対応できます。 テーブル ツールの一覧については、「Azure Storage クライアント ツール」をご覧ください。

はい。オプティミスティック コンカレンシーは、ETag メカニズムを使用して提供されます。

はい。Table 用 API は、OData クエリと LINQ クエリをサポートしています。

はい。同時に接続するには、CloudTableClient の 2 つのインスタンスを作成し、各インスタンスで接続文字列を使用して独自の URI を参照します。

AzCopy がサポートされています。

Azure Cosmos DB は、水平スケーリングを使用して無制限のストレージを提供するように設計されています。 このサービスは、ストレージを監視し、ストレージを効率的に増やすことができます。

Table 用 API の [メトリック] ペインを使って、要求とストレージ使用量を監視できます。

容量見積もりツールを使用して、操作に必要な TableThroughput を計算できます。 詳細については、「Estimate Request Units and Data Storage (要求ユニットとデータ ストレージの見積もり)」をご覧ください。 一般に、エンティティを JSON として示し、操作数を指定します。

現時点ではありません。

はい。同じ API がサポートされています。

いいえ。中断することなく、Azure Table Storage 資産を作成したり、既存の Azure Table Storage 資産を使用したりできます。 ただし、Table 用 API を使わない場合、自動インデックス、追加の整合性オプション、またはグローバル分散によるメリットは得られません。

Azure Cosmos DB ポータルのグローバル レプリケーション設定を使用して、アプリケーションに適したリージョンを追加できます。 グローバル分散型のアプリケーションを開発するには、低待機時間の読み取りを実現するために、PreferredLocation 情報をローカル リージョンに設定したアプリケーションを追加する必要があります。

Azure Cosmos DB のグローバル レプリケーション ポータル ウィンドウを使用してリージョンを追加し、必要なリージョンにフェールオーバーできます。 手順については、複数リージョンの Azure Cosmos DB アカウントを使用した開発に関する記事をご覧ください。

ローカルの場所から読み取りを実行できるようにするには、app.config ファイルの PreferredLocation キーを使用します。 既存のアプリケーションの場合、LocationMode が設定されていると、Table 用 API はエラーをスローします。 Table 用 API は app.config ファイルからこの情報を取得するので、該当のコードを削除してください。

Azure Cosmos DB では、整合性、可用性、待機時間の最適なトレードオフを提供します。 Azure Cosmos DB には 5 つの整合性レベルが用意されているので、Table 用 API の開発者は、データのクエリを実行するときにテーブル レベルで最適な整合性モデルを選び、個々の要求を行うことができます。 クライアントは、接続時に整合性レベルを指定できます。 レベルは、CreateCloudTableClient の consistencyLevel 引数を使って変更できます。

Table 用 API では、既定で有界整合性制約の整合性が適用され、"自身の書き込みの読み取り" によって低待機時間の読み取りを実現します。 詳細については、整合性レベルに関する記事をご覧ください。

既定では、Azure Standard Table はリージョン内では厳密な整合性を提供し、セカンダリの場所では最終的な整合性を提供します。

はい。Azure Cosmos DB の分散特性のメリットを得る方法については、「一貫性レベル」をご覧ください。 整合性レベルは保証の対象となるため、安心して使用できます。

Azure Cosmos DB では、データはローカル リージョンで永続的にコミットされ、わずか数ミリ秒ですぐに他のリージョンにプッシュされます。 このレプリケーションは、データ センターのラウンドトリップ時間 (RTT) にのみ依存します。 Azure Cosmos DB のグローバル分散機能の詳細については、Azure Cosmos DB:Azure のグローバル分散データベース サービスに関する記事をご覧ください。

Azure Cosmos DB では、コンテナー レベル (テーブル) で整合性レベルを設定できます。 レベルを変更するには、.NET SDK を使って、app.config ファイルで TableConsistencyLevel キーの値を指定します。 指定できる値は、Strong、Bounded Staleness、Session、Consistent Prefix、Eventual です。 詳細については、「Azure Cosmos DB の調整可能なデータの一貫性レベル」をご覧ください。 基本的な考え方として、要求の整合性レベルは、テーブルの設定よりも高いレベルに設定することはできません。 たとえば、テーブルの整合性レベルを Eventual (最終的) に設定し、要求の整合性レベルを Strong (厳密) に設定することはできません。

Table 用 API は、Azure Cosmos DB のグローバルに分散されたプラットフォームを利用します。 アプリケーションがデータ センターのダウンタイムを許容できるようにするには、Azure Cosmos DB ポータルでアカウントのリージョンを少なくとももう 1 つ有効にします (複数リージョンの Azure Cosmos DB アカウントを使用した開発に関する記事を参照)。 ポータルを使用してリージョンの優先順位を設定できます (複数リージョンの Azure Cosmos DB アカウントを使用した開発に関する記事を参照)。

アカウントのリージョンを必要な数だけ追加し、フェールオーバーの優先順位を指定してフェールオーバー先を制御できます。 データベースを使用するには、そのリージョンでもアプリケーションを提供する必要があります。 そうすれば、ダウンタイムが発生しなくなります。 最新の .NET クライアント SDK は自動回帰しますが、他の SDK はしません。 つまり、ダウンしているリージョンを検出すると、新しいリージョンに自動的にフェールオーバーできます。

はい。Table 用 API は、バックアップに Azure Cosmos DB のプラットフォームを利用します。 バックアップは自動的に作成されます。 詳細については、Azure Cosmos DB でのオンライン バックアップと復元に関する記事をご覧ください。

はい。エンティティのすべての属性のインデックスが既定で作成されます。 詳細については、「Azure Cosmos DB でのインデックス作成ポリシー」をご覧ください。

はい。Azure Cosmos DB for Table はすべての属性の自動インデックス作成機能を備えています。スキーマ定義は不要です。 この自動化により、開発者はインデックスの作成と管理ではなく、アプリケーションに注力できるようになります。 詳細については、「Azure Cosmos DB でのインデックス作成ポリシー」をご覧ください。

はい。インデックス定義を提供することでインデックス作成ポリシーを変更できます。 設定を適切にエンコードし、エスケープする必要があります。

インデックス作成ポリシーを設定できる唯一の方法は次のとおりです。ポータルのデータ エクスプローラーで、変更する特定のテーブルに移動し、[スケールと設定]->[インデックス作成ポリシー] で必要な変更を行って、[保存] を選びます。

Table 用 API は Azure Table Storage と同じクエリ機能を提供します。 また、並べ替え、集計、地理空間クエリ、階層、さまざまな組み込み関数もサポートしています。 詳細については、SQL クエリに関する記事を参照してください。

次のいずれかの条件に該当する場合は、TableThroughput を変更してください。

• データの抽出、変換、読み込み (ETL) を実行している。または、短時間に大量のデータをアップロードする必要がある。
• バックエンドでコンテナーまたはコンテナーのセットのスループットを増やす必要がある (たとえば、使用されたスループットがプロビジョニング スループットを超えており、調整が行われている)。 詳細については、「Azure Cosmos DB コンテナーのスループットの設定」を参照してください。

はい。スループットのスケーリングは、Azure Cosmos DB ポータルのスケール ウィンドウを使用して実行できます。 詳細については、スループットの設定に関する記事をご覧ください。

はい。app.config で TableThroughput をオーバーライドしておらず、Azure Cosmos DB であらかじめ作成されているコンテナーを使用していない場合、スループットが 400 に設定されたテーブルが作成されます。

[なし] : Azure Table Storage の既存のお客様を対象とする価格の変更はありません。

料金は、割り当てられた TableThroughput によって異なります。

要求レートが基になるコンテナーまたはコンテナーのセットのプロビジョニング スループットの容量を超えると、エラーが発生し、SDK では再試行ポリシーの適用によって呼び出しが再試行されます。

Azure Cosmos DB では、app.config ファイルまたはポータルでコンテナーのスループットが指定されていない場合、既定のスループットが設定されます。

Azure Cosmos DB では、操作に上限を設定してパフォーマンスと待機時間を保証します。 この保証は、エンジンがテナントの操作にガバナンスを適用できる場合に可能になります。 TableThroughput を設定すると、プラットフォームでこの容量が予約され、操作が正常に完了することが保証されるので、保証されたスループットと待機時間が確保されます。

また、スループットの仕様により、スループットを弾力的に変更して、アプリケーションの季節性によるメリットを享受し、スループットのニーズを満たして、コストを削減できます。

Azure Cosmos DB は、可用性、待機時間、スループットが保証された、グローバル分散型の SLA ベースのシステムとして設計されています。 他のシステムのスループットとは異なり、Azure Cosmos DB でスループットを予約すると、そのスループットが保証されます。 Azure Cosmos DB には、セカンダリ インデックスやグローバル分散など、お客様から要望があった追加機能が用意されています。

Azure Cosmos DB は、待機時間、スループット、可用性、整合性を保証し、無制限のスケールを提供する SLA ベースのシステムです。 保証された Premium パフォーマンスを確保するために、データ サイズとインデックスが管理可能であり、スケーラブルであることを確認してください。 パーティション キーごとのエンティティ数または項目数に 20 GB の制限を設けているのは、検索やクエリの優れたパフォーマンスを確実に提供するためです。 すべての情報を 1 つのパーティションに格納し、そのパーティションに対してクエリを実行すると、ホット パーティションになります。Azure Storage でもアプリケーションが適切にスケールできるように、ホット パーティションが発生しないようにすることをお勧めします。

はい。 Table 用 API の外部からアクセスできる領域は、Azure Table Storage SDK のその領域とほぼ同じであるため、パーティション キーによってデータを効率的に分散させることができます。 行キーはそのパーティション内で一意です。 行キーが存在する必要があり、Standard SDK の場合と同様に、行キーを null にすることはできません。 RowKey の長さは 255 バイト、PartitionKey の長さは 1 KB です。

Azure Table Storage と Azure Cosmos DB for Table は同じ SDK を使っているので、ほとんどのエラーは同じです。

Azure Cosmos DB は、待機時間、スループット、可用性、整合性を保証する SLA ベースのシステムです。 Azure Cosmos DB はプロビジョニングされるシステムであるため、これらの要件を保証するためにリソースが予約されています。 テーブルを次々に作成すると、その作成ペースが検出され、調整が行われます。 テーブルの作成ペースを確認し、1 分あたり 5 つ未満に抑えることをお勧めします。 Table 用 API はプロビジョニングされるシステムであることに注意してください。 プロビジョニングした時点から料金が発生します。

次のいずれかの方法でフィードバックをお寄せください。

• Microsoft Q&A 質問ページ
• Stack Overflow。 Stack Overflow は、プログラミングに関する質問に最適です。 質問が的を得ており、かつその質問を明確で回答可能なものにするようにできるだけ多くの詳細情報が含まれていることを確認してください。

ロールベースのアクセス制御 (RBAC) は、企業内の個々のユーザーのロールに基づいて、コンピューター リソースまたはネットワーク リソースへのアクセスを規制する方法です。 Azure Cosmos DB では、RBAC を使用して、ユーザーとアプリケーションにデータ プレーン アクセスを許可します。

Azure Cosmos DB のネイティブのロールベースのアクセス制御 (RBAC) 機能を使用して、ユーザーとアプリケーションにデータ プレーン アクセスを許可します。

関連するコンテンツ

• .NET SDK と Azure Cosmos DB を使用して Table 用 API アプリを構築する
• Azure Cosmos DB for Table のデータを管理する Java アプリを作成する

次のステップ