編集

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

  • よく寄せられる質問

適用対象: Table

Azure Cosmos DB for Table と Azure Table Storage の比較

Table 用 API と Azure Table Storage の動作はどのような点が異なりますか?

これまで 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

その他のよく寄せられる質問

Table 用 API を使うには新しい SDK が必要ですか?

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

Table 用 API に接続するには、どのような接続文字列を使う必要がありますか?

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

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

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

Table 用 API 用の .NET SDK で、要求オプションの構成設定をオーバーライドするにはどうすればよいですか?

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

既存の Azure Table Storage SDK を使っている顧客に関する変更はありますか?

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

Table 用 API で使うために、Azure Cosmos DB に格納されているテーブル データを表示するにはどうすればよいですか?

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

Table 用 API で動作するのはどのツールですか?

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

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

操作のコンカレンシーは制御されますか?

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

エンティティの OData クエリ モデルはサポートされていますか?

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

同じアプリケーションで Azure Table Storage と Azure Cosmos DB for Table に同時に接続できますか?

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

既存の Azure Table Storage アプリケーションをこのサービスに移行するにはどうすればよいですか?

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

たとえば、最初は 『n』 GB のデータが時間の経過と共に 1 TB に増加した場合、このサービスではストレージ サイズはどのように拡張されるのですか?

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

Table 用 API を監視するにはどうすればよいですか?

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

必要なスループットを計算するにはどうすればよいですか?

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

エミュレーターでローカルに Table 用 API の SDK を使うことはできますか?

現時点ではありません。

既存のアプリケーションを Table 用 API で動作させることはできますか?

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

Table 用 API の機能を使わない場合、既存の Azure Table Storage アプリケーションを SDK に移行する必要はありますか?

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

Table 用 API で、Azure の複数のリージョン間でのデータのレプリケーションを追加するにはどうすればよいですか?

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

Table 用 API でアカウントのプライマリ書き込みリージョンを変更するにはどうすればよいですか?

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

データを分散するときに低待機時間を実現するために、優先読み取りリージョンを構成するにはどうすればよいですか?

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

Table 用 API の整合レベルについてどのように考えればよいですか?

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

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

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

Azure Cosmos DB for Table では、Azure Table Storage より多くの整合性レベルが提供されますか?

はい。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 はフェールオーバーをどのように処理しますか?

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

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

Table 用 API ではバックアップは有効になっていますか?

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

Table 用 API では、既定でエンティティのすべての属性のインデックスが作成されますか?

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

つまり、クエリを満たすために複数のインデックスを作成する必要はないということですか?

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

インデックス作成ポリシーは変更できますか?

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

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

プラットフォームとしての Azure Cosmos DB は、並べ替え、集計、階層などの多数の機能を備えているようですが、 これらの機能は Table 用 API に追加される予定ですか?

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

Table 用 API の TableThroughput は、どのようなときに変更する必要がありますか?

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

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

Table 用 API のテーブルのスループットはスケールアップまたはスケールダウンできますか?

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

新しくプロビジョニングされたテーブルには、既定の TableThroughput が設定されるのですか?

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

Azure Table Storage サービスの既存の顧客を対象とする価格の変更はありますか?

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

Table 用 API の料金はどのように計算されますか?

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

Table 用 API では、テーブルのレート制限にどのように対処すればよいですか?

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

Azure Cosmos DB の Table 用 API オファリングを利用するために、PartitionKey および RowKey とは別にスループットを選ぶ必要があるのはなぜですか?

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

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

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

データの保存にしか料金を支払っておらず、クエリを実行することはほとんどないため、Azure Table Storage は安価でした。 Azure Cosmos DB for Table オファリングでは、トランザクションを 1 つも実行していない場合や何も保存していない場合でも課金されているようです。 説明できますか。

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

Azure Table Storage にデータを取り込んだときに、(パーティションがいっぱいであることを示す) "クォータが上限に達した" ことを通知するメッセージが表示されたことは一度もありませんでした。 Table 用 API では、このメッセージが表示されました。 このサービスには制限があり、既存のアプリケーションを変更しなければならないのでしょうか?

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

Table 用 API で PartitionKey と RowKey が必要なのはそのためですか?

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

Table 用 API のエラー メッセージはどのようなものですか?

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

Table 用 API で多数のテーブルを次々に作成しようとすると調整が行われるのはなぜですか?

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

SDK やバグに関するフィードバックを提供するにはどうすればよいですか?

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

関連するコンテンツ

次のステップ

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