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

Cassandra サービス用 API と Apache Cassandra の主な違いを次に示します:

• Apache Cassandra では、パーティション キー サイズの上限に 100 MB が推奨されます。 Azure Cosmos DB の Cassandra 用 API では、パーティションごとに最大 20 GB を使用できます。
• Apache Cassandra を使用すると、永続的なコミットを無効にすることができます。 コミット ログへの書き込みをスキップして、メモリ内のデータ構造に直接移動できます。 これにより、メモリ内のデータ構造がディスク上の SSTable にフラッシュされる前にノードがダウンすると、データが失われる可能性があります。 Azure Cosmos DB では、データの損失を防ぐために常に永続的なコミットが行われます。
• Apache Cassandra では、多数の置換または削除を伴うワークロードの場合にパフォーマンスが低下する可能性があります。 この理由は、最新のデータを取り込むために読み取りワークロードでスキップする必要がある廃棄標識です。 Cassandra 用 API では、多数の置換または削除があるワークロードの場合に読み取りのパフォーマンスが低下しません。
• 置換数の多いワークロードのシナリオでは、圧縮を実行してディスク上の SSTable をマージする必要があります (Apache Cassandra の書き込みは追加のみなので、マージが必要です。複数の更新プログラムは、定期的にマージする必要がある個々の SSTable エントリとして格納されます)。 このような状況の場合、圧縮中の読み取りのパフォーマンスも低下する可能性があります。 このパフォーマンスへの影響は Cassandra 用 API では発生しません。API に圧縮が実装されていないためです。
• Apache Cassandra では、レプリケーション係数として 1 を設定できます。 しかし、データがある唯一のノードがダウンした場合、可用性が低下します。 レプリケーション係数は常に 4 (3 のクォーラム) であるため、これは Azure Cosmos DB の Cassandra 用 API に関する問題ではありません。
• Apache Cassandra でノードを追加または削除するには、手動による介入が必要です。さらに、新しいノードの CPU 使用率は高くなり、既存のノードではトークン範囲の一部が新しいノードに移動されます。 この状況は、既存のノードを使用停止する場合も同じです。 一方、Cassandra 用 API の場合は、サービスまたはアプリケーションで問題が発生することなくスケールアウトします。
• Apache Cassandra のように、クラスター内の各ノードに num_tokens を設定する必要はありません。 Azure Cosmos DB では、ノードとトークン範囲が完全に管理されます。
• Cassandra 用 API はフル マネージドです。 Apache Cassandra で使用されるコマンド (repair や decommission など) は必要ありません。

API for Cassandra for Azure Cosmos DB では、Cassandra クエリ言語 (CQL) m バージョン 3.x がサポートされています。 CQL の互換性は、パブリック Apache Cassandra GitHub リポジトリに基づいています。 その他のプロトコルのサポートに関するフィードバックがある場合は、メールで askcosmosdbcassandra@microsoft.com に送信してください。

Azure Cosmos DB では、テーブルの作成元に基づいてコンテナーの既定のスループットが設定されます。つまり、Azure portal または CQL です。

Azure Cosmos DB では、操作に上限を設定してパフォーマンスと待機時間を保証します。 このような保証は、エンジンがテナントの操作にガバナンスを適用できる場合に可能になります。 スループットを設定すると、プラットフォームでこの容量が予約され、操作が正常に完了することが保証されるので、保証されたスループットと待機時間が確保されます。 アプリケーションの季節性を利用し、コストを削減するために、スループットをエラスティックに変更することができます。

スループットの概念については、「Azure Cosmos DB の要求ユニット」を参照してください。 テーブルのスループットは、基になる物理パーティション全体で均等に分散されます。

Azure Cosmos DB では、スループットの単位として 1 秒あたりの要求単位数 (RU/秒) が使われています。 CQL を使用して作成されたテーブルの既定値は 400 RU です。 RU は Azure portal から変更できます。

CQL

CREATE TABLE keyspaceName.tablename (user_id int PRIMARY KEY, lastname text) WITH cosmosdb_provisioned_throughput=1200

.NET

int provisionedThroughput = 400;
var simpleStatement = new SimpleStatement($"CREATE TABLE {keyspaceName}.{tableName} (user_id int PRIMARY KEY, lastname text)");
var outgoingPayload = new Dictionary<string, byte[]>();
outgoingPayload["cosmosdb_provisioned_throughput"] = Encoding.UTF8.GetBytes(provisionedThroughput.ToString());
simpleStatement.SetOutgoingPayload(outgoingPayload);

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

この容量を超えると、容量が使い果たされたことを示す次のエラー メッセージを受け取ります。

0x1001 Overloaded: the request can't be processed because "Request Rate is large" (0x1001 オーバーロード: "要求レートが大きい" ため要求を処理できませんでした)

この問題の原因となっている操作 (とそのボリューム) を確認することが重要です。 Azure portal でメトリックを使用すると、プロビジョニングした容量を超えた容量の使用について理解できることがあります。 次に、基になるすべてのパーティションでほぼ均等に容量が使用されていることを確保する必要があります。 1 つのパーティションがほとんどのスループットを消費していることがわかった場合は、ワークロードに偏りがあります。

複数のパーティション全体、または集計して、時間単位、日単位、7 日間単位で使用されたスループットを示すメトリックを使用できます。 詳細については、「Azure Cosmos DB のメトリックを使用した監視とデバッグ」を参照してください。

診断ログについては、「Azure Cosmos DB 診断ログ」の記事を参照してください。

はい。パーティション キーは、適切な場所にエンティティを配置するために使用されます。 Azure Cosmos DB では、物理パーティションに格納されている適切な論理パーティションを見つけるために使用されます。 パーティション分割の概念については、「Azure Cosmos DB でのパーティション分割とスケーリング」の記事でわかりやすく説明されています。 ここで重要な点は、論理パーティションは 20 GB の制限を超えないようにすることです。

Azure Cosmos DB はサービス レベル アグリーメント (SLA) に基づくシステムです。 待機時間、スループット、可用性、一貫性が保証され、無制限のスケールが提供されます。 この無制限のストレージは、主要な概念としてパーティション分割を使用し、データの水平スケールアウトに基づいています。 パーティション分割の概念については、「Azure Cosmos DB でのパーティション分割とスケーリング」の記事でわかりやすく説明されています。

論理パーティションあたりのエンティティ数または項目数に関する 20 GB の制限に従うことをお勧めします。 すべての情報を 1 つのパーティションに格納し、そのパーティションに対してクエリを実行すると、ホット パーティションになります。アプリケーションが適切にスケールできるように、ホット パーティションが発生しないようにすることをお勧めします。 このエラーは、データが均等ではない場合、つまり、1 つのパーティション キーに大量の (20 GB を超える) データが偏っている場合にのみ発生する可能性があります。 ストレージ ポータルを使用して、データの分散を確認できます。 このエラーを解決するには、テーブルを作成し直し、より細分化されたプライマリ (パーティション キー) を選択すると、データの分散が改善されます。

Azure Cosmos DB はストレージをスケールアウトすることで無制限のデータを格納できます。 このストレージはスループットに依存しません。 そのため、Cassandra 用 API を使用すると、常にキーと値を格納し、適切な主キーまたはパーティション キーを指定して取得することができます。 これらの個々のキーには独自の論理パーティションが割り当てられ、物理パーティションに問題なく配置されます。

はい、Cassandra 用 API を使用して複数のテーブルを作成できます。 これらの各テーブルは、スループットとストレージのユニットとして扱われます。

Azure Cosmos DB は、データ アクティビティとコントロール プレーン アクティビティ両方のリソース管理システムです。 コレクションやテーブルなどのコンテナーは、特定のスループット容量に対してプロビジョニングされるランタイム エンティティです。 これらのコンテナーの連続的な作成は予期されるアクティビティではないため、調整される可能性があります。 テーブルを即時に削除または作成するテストを行う場合は、間隔を空けるようにしてください。

テーブル数に物理的な制限はありません。 通常の数十個や数百個ではなく、多数のテーブル (合計のサイズが常に 10 TB を超えるデータ) を作成する必要がある場合は、askcosmosdbcassandra@microsoft.com にメールを送信してください。

キースペースはメタデータ コンテナーであるため、その数に物理的な制限はありません。 キースペースが多数ある場合は、askcosmosdbcassandra@microsoft.com にメールをお送りください。

はい。 パーティションが均等に分散されていると仮定した場合、ストレージ容量は自動的に管理され、取り込むデータが増えると拡大されます。 そのため、必要に応じて任意の量のデータを安心してインポートできます。ノードの管理やプロビジョニングなどは必要ありません。 ただし、大量のデータの急速な増加が予想される場合は、少量のものから始めて、すぐに増やすのではなく、予想されるスループットに対してプロビジョニングを直接行うことをお勧めします。

Azure Cosmos DB の Cassandra 用 API を使用すると、操作の実行に関してプロトコルレベルの互換性を実現できます。 管理、監視、および構成の複雑な部分は隠されています。 開発者やユーザーは、可用性、廃棄標識、キー キャッシュ、行キャッシュ、ブルーム フィルター、他のさまざまな設定について心配する必要はありません。 Cassandra 用 API は、構成と管理のオーバーヘッドを発生させることなく、必要な読み取りと書き込みのパフォーマンスを実現することに重点を置いています。

Cassandra 用 API を使用すると、容量計画を簡素化し、スループットとストレージに対する弾力性要求に対応できます。 Azure Cosmos DB を使って必要なスループットをプロビジョニングします。 その後は、ノードの追加、削除、管理を心配せずに、1 日に何度でもスケールアップおよびスケールダウンできます。 ノードとクラスターの管理にツールを使用する必要はありません。

Azure Cosmos DB では、可用性と低待機時間のために、最初からグローバルな分散が提供されています。 レプリカやなどを設定する必要はありません。 書き込みは、書き込み対象のすべてのリージョンで常に永続的にクォーラム コミットされ、パフォーマンスが保証されます。

Azure Cosmos DB では、読み取り、書き込み、スループットのパフォーマンスが保証されています。 そのため、構成設定に触れて誤って操作することを心配する必要はありません。 このような設定には、ブルーム フィルター、キャッシュ、読み取り修復の可能性、gc_grace、圧縮の memtable_flush_period などがあります。

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

Azure Cosmos DB はプラットフォーム サービスであり、生産性を向上させ、インフラストラクチャの管理と監視の心配を取り除きます。 たとえば、以前のようにさまざまなツールを使用してノードの状態、レプリカの状態、gc、OS パラメーターを監視する必要はありません。 ポータルのメトリックで使用できるスループットを監視し、調整されているかどうかを確認し、そのスループットを増減するだけです。 次のようにすることができます。

• SLA を監視する
• メトリックを使用する
• 診断ログを使用する

CQLv3 を使用する Apache Cassandra SDK のクライアント ドライバーがクライアント プログラムに使用されていました。 他のドライバーを使用している場合、または問題が発生している場合は、askcosmosdbcassandra@microsoft.com まで電子メールでお問い合わせください。

はい。通常の構文を使って、複合パーティション キーを作成できます。

いいえ。sstableloader はサポートされていません。

現在、Azure Cosmos DB では、操作のオーバーヘッドがないクラウド環境に合わせてエクスペリエンスが最適化されています。 ペアリングが必要な場合は、シナリオの説明を添えて askcosmosdbcassandra@microsoft.com まで電子メールでお問い合わせください。 Microsoft では、オンプレミスまたはクラウドの Cassandra クラスターと Azure Cosmos DB の Cassandra 用 API を組み合わせることができるオファリングに取り組んでいます。

Azure Cosmos DB では、すべての API について 4 時間間隔で 2 つの無料の完全バックアップが提供されています。 そのため、バックアップ スケジュールを設定する必要はありません。

バックアップの保有期間と頻度は自分で管理できます。

保有期間と頻度を変更したい場合は、askcosmosdbcassandra@microsoft.com までメールでお問い合わせいただくか、サポート ケースを作成してください。 バックアップ機能については、「Azure Cosmos DB での自動オンライン バックアップと復元」の記事を参照してください。

Cassandra 用 API には、Azure Cosmos DB のグローバルに分散されたプラットフォームが利用されています。 アプリケーションでデータ センターのダウンタイムが確実に許容されるようにするには、Azure portal でアカウントのリージョンを少なくとももう 1 つ有効にします。 詳細については、「Azure Cosmos DB での高可用性」を参照してください。

アカウントのリージョンを必要な数だけ追加し、フェールオーバーの優先順位を指定してフェールオーバー先を制御できます。 データベースを使用するには、そのリージョンでもアプリケーションを提供する必要があります。 そうすれば、ダウンタイムが発生しなくなります。

いいえ。 Cassandra 用 API ではセカンダリ インデックスがサポートされます。これは Apache Cassandra と同様に動作します。 API の既定では、すべての属性のインデックスが作成されるわけではありません。

はい、これはサポートされています。 これを有効にする方法の詳細については、「ローカルでの開発とテストに Azure Cosmos DB Emulator を使用する」という記事を参照してください。

移行オプションの詳細については、「Azure Cosmos DB の Cassandra 用 API アカウントにデータを移行する」のチュートリアルを参照してください。

関連するコンテンツ

• Azure Cosmos DB for Apache Cassandra アカウントのエラスティック スケーリング を開始する

次のステップ