このページでは、Apache Cassandra と Spanner のアーキテクチャを比較し、Spanner の Cassandra インターフェースの機能と制限事項について説明します。ここでは、Cassandra に精通しており、Spanner をデータベースとして使用しながら既存のアプリケーションを移行または新しいアプリケーションを設計することを前提としています。
Cassandra と Spanner はどちらも、高いスケーラビリティと低レイテンシを必要とするアプリケーション向けに構築された大規模な分散データベースです。どちらのデータベースも要求の厳しい NoSQL ワークロードをサポートできますが、Spanner にはデータモデリング、クエリ、トランザクション オペレーション用の高度な機能が用意されています。Spanner が NoSQL データベースの基準を満たす仕組みの詳細については、非リレーショナル ワークロード用の Spanner をご覧ください。
基本コンセプト
このセクションでは、Cassandra と Spanner の主なコンセプトを比較します。
用語
| Cassandra | Spanner |
|---|---|
| クラスタ |
インスタンス Cassandra クラスタは、Spanner インスタンス（サーバーおよびストレージ リソースのコレクション）と同等です。Spanner はマネージド サービスであるため、基盤となるハードウェアやソフトウェアを構成する必要はありません。インスタンスに予約するノードの数を指定するだけで、または自動スケーリングを使用してインスタンスを自動的にスケーリングするだけで済みます。インスタンスはデータベースのコンテナとして機能します。また、インスタンス レベルでデータ レプリケーション トポロジ（リージョン、デュアルリージョン、マルチリージョン）を選択します。 |
| キースペース |
データベース Cassandra キースペースは、テーブルやその他のスキーマ要素（インデックスやロールなど）のコレクションである Spanner データベースと同等です。キースペースとは異なり、レプリケーション ロケーションを構成する必要はありません。Spanner は、インスタンスで指定されたリージョンにデータを自動的に複製します。 |
| テーブル |
テーブル テーブルはテーブル スキーマで指定された主キーによって識別される行のコレクションです。Cassandra と Spanner とで意味は変わりません。 |
| パーティション |
スプリット Cassandra と Spanner はどちらも、データをシャーディングすることでスケーリングします。Cassandra では各シャードはパーティションと呼ばれ、Spanner では各シャードはスプリットと呼ばれます。Cassandra ではハッシュ パーティショニングが使用されます。つまり、各行は主キーのハッシュに基づいてストレージ ノードに個別に割り当てられます。Spanner は範囲でシャーディングされています。つまり、主キーのキースペースで連続している行は、ストレージでも連続しています（スプリット境界を除く）。Spanner は、負荷とストレージに基づいて分割と結合を行います。これはアプリケーションに対して透過的です。Cassandra との主な違いは、Spanner では主キーの接頭辞に対する範囲スキャンが効率的なオペレーションであるという点です。 |
| 行 |
行 行は主キーによって一意に識別される列のコレクションです。Cassandra と Spanner とで意味は変わりません。Cassandra と同様に、Spanner は複合主キーをサポートしています。Cassandra とは異なり、Spanner ではデータが範囲でシャーディングされるため、パーティション キーと並べ替えキーを区別しません。Spanner には並べ替えキーのみがあり、パーティショニングはバックグラウンドで管理されていると考えることができます。 |
| 列 |
列 列は同じ型のデータ値のセットです。Cassandra と Spanner とで意味は変わりません。テーブルの行ごとに 1 つの値があります。Cassandra 列型と Spanner の比較の詳細については、データ型をご覧ください。 |
アーキテクチャ
Cassandra クラスタは、一連のサーバーと、それらのサーバーと共存するストレージで構成されます。ハッシュ関数は、パーティション キースペースの行を仮想ノード（vnode）にマッピングします。その後、一連の vnode が各サーバーにランダムに割り当てられ、クラスタ キースペースの一部を処理します。vnode のストレージは、ローカルでサービス提供ノードに接続されます。クライアント ドライバはサービス提供ノードに直接接続し、ロード バランシングとクエリ ルーティングを処理します。
Spanner インスタンスは、レプリケーション トポロジ内の一連のサーバーで構成されます。Spanner は、CPU とディスクの使用状況に基づいて各テーブルを動的に行範囲にシャーディングします。シャードは、サービス提供用にコンピューティング ノードに割り当てられます。データは、コンピューティング ノードとは別に、Google の分散ファイル システムである Colossus に物理的に保存されます。クライアント ドライバは、リクエストのルーティングとロード バランシングを行う Spanner のフロントエンド サーバーに接続します。詳細については、Spanner の読み取りと書き込みのライフサイクルのホワイトペーパーをご覧ください。
大まかに言えば、どちらのアーキテクチャも、基盤となるクラスタにリソースが追加されるとスケーリングされます。Spanner のコンピューティングとストレージの分離により、ワークロードの変化に応じてコンピューティング ノード間の負荷をより迅速に再分散できます。Cassandra とは異なり、シャードの移動ではデータが Colossus に残るため、データの移動は行われません。さらに、Spanner の範囲ベースのパーティショニングは、データがパーティション キーで並べ替えられることを想定するアプリケーションに適しています。範囲ベースのパーティショニングの欠点は、追加のスキーマ設計が考慮されていない場合、キースペースの一端に書き込むワークロード（現在のタイムスタンプでキー設定されたテーブルなど）にホットスポットが発生する可能性があることです。ホットスポットを回避する手法の詳細については、スキーマ設計のベスト プラクティスをご覧ください。
整合性
Cassandra では、オペレーションごとに整合性レベルを指定する必要があります。クォーラム整合性レベルを使用する場合、オペレーションが成功したと見なされるには、レプリカノードの過半数がコーディネーター ノードに応答する必要があります。整合性レベルが 1 の場合、オペレーションが成功と見なされるには、Cassandra が単一のレプリカノードに応答する必要があります。
Spanner は強整合性を提供します。Spanner API は、レプリカをクライアントに公開しません。Spanner クライアントは、Spanner を単一マシンのデータベースとして操作します。Spanner が成功をユーザーに報告する前に、書き込みは常に過半数のレプリカに行われます。その後の読み取りでは、新しく書き込まれたデータが反映されます。アプリケーションでは、過去のある時点でデータベースのスナップショットを読み取るように選択できます。これにより、強力な読み取りよりもパフォーマンス上のメリットが得られる場合があります。Spanner の整合性プロパティの詳細については、トランザクションの概要をご覧ください。
Spanner は、大規模なアプリケーションに必要な整合性と可用性をサポートするように構築されています。Spanner は、大規模で高パフォーマンスの強整合性を提供します。必要なユースケースでは、Spanner はスナップショット（古い）読み取りをサポートし、鮮度の要件を緩和します。
Cassandra インターフェース
Cassandra インターフェースを使用すると、使い慣れた Cassandra ツールと構文を使用して、Spanner のフルマネージド、スケーラブル、高可用性のインフラストラクチャを活用できます。このページでは、Cassandra インターフェースの機能と制限事項について説明します。
Cassandra インターフェースのメリット
- ポータビリティ: Cassandra インターフェースを使用すると、Cassandra と互換性のあるスキーマ、クエリ、クライアントを使用して、Spanner の幅広い機能にアクセスできます。これにより、Spanner で構築されたアプリケーションを別の Cassandra 環境に移動したり、その逆を行うことが簡単になります。このポータビリティにより、デプロイの柔軟性が向上し、強制退出などの障害復旧シナリオがサポートされます。
- 使いやすさ: Cassandra をすでに使用している場合は、多くの同じ CQL ステートメントと型を使用して Spanner をすぐに使い始めることができます。
- 妥協のない Spanner: Cassandra インターフェースは Spanner の既存の基盤上に構築されているため、補完的な GoogleSQL エコシステムで利用可能な機能に妥協することなく、Spanner の既存の可用性、整合性、コスト パフォーマンスのメリットをすべて提供します。
CQL の互換性
CQL 言語のサブセットのサポート: Spanner は、データクエリ言語（DQL）、データ操作言語（DML）、軽量トランザクション（LWT）、集計関数、日時関数など、CQL 言語のサブセットを提供します。
サポートされている Cassandra 機能: Cassandra インターフェースは、Cassandra で最もよく使用される機能の多くをサポートしています。これには、スキーマと型システムのコア部分、多くの一般的なクエリの形状、さまざまな関数と演算子、Cassandra のシステム カタログの重要な側面が含まれます。アプリケーションは、Spanner の Cassandra ワイヤ プロトコル実装を介して接続することで、多くの Cassandra クライアントまたはドライバを使用できます。
クライアントとワイヤ プロトコルのサポート: Spanner は、アプリケーションと一緒に実行される軽量クライアントである Cassandra Adapter を使用して、Cassandra ワイヤ プロトコル v4 のコアクエリ機能をサポートしています。これにより、多くの Cassandra クライアントは、Spanner のグローバル エンドポイントと接続管理、IAM 認証を活用しながら、Spanner Cassandra インターフェース データベースでそのまま動作できます。
サポートされている Cassandra データ型
次の表に、サポートされている Cassandra データ型と、各データ型に対応する Spanner GoogleSQL データ型を示します。
| サポートされている Cassandra データ型 | Spanner GoogleSQL のデータ型 | |
|---|---|---|
| 数値型 | tinyint（8 ビット符号付き整数） |
INT64（64 ビット符号付き整数）Spanner は、符号付き整数に 64 ビット幅の単一データ型をサポートしています。 |
smallint（16 ビット符号付き整数） |
||
int（32 ビット符号付き整数） |
||
bigint（64 ビット符号付き整数） |
||
float（32 ビット IEEE-754 浮動小数点） |
FLOAT32（32 ビット IEEE-754 浮動小数点） |
|
double（64 ビット IEEE-754 浮動小数点） |
FLOAT64（64 ビット IEEE-754 浮動小数点） |
|
decimal |
固定精度の小数数の場合は、NUMERIC データ型（精度 38、スケール 9）を使用します。 |
|
varint（可変精度の整数） |
||
| 文字列型 | text |
STRING(MAX)
|
varchar |
||
ascii |
STRING(MAX) |
|
uuid |
STRING(MAX) |
|
inet |
STRING(MAX) |
|
blob |
BYTES(MAX)
バイナリデータを保存するには、 |
|
| 日時型 | date |
DATE |
time |
INT64
Spanner は専用の時間データ型をサポートしていません。ナノ秒の期間を保存するには、 |
|
timestamp |
TIMESTAMP |
|
| コンテナタイプ | set |
ARRAY
Spanner は専用の |
list |
ARRAY
|
|
map |
JSON
Spanner は専用のマップ型をサポートしていません。地図を表すには、 |
|
| その他の型 | boolean |
BOOL |
counter |
INT64 |
データ型のアノテーション
cassandra_type 列オプションを使用すると、Cassandra と Spanner のデータ型のマッピングを定義できます。Cassandra 互換のクエリを使用して操作するテーブルを Spanner に作成する場合は、cassandra_type オプションを使用して、各列に対応する Cassandra データ型を指定できます。このマッピングは、2 つのデータベース システム間でデータを転送するときに、Spanner でデータの正しい解釈と変換を行うために使用されます。
たとえば、Cassandra に次のスキーマを持つテーブルがあるとします。
CREATE TABLE Albums (
albumId uuid,
title varchar,
artists set<varchar>,
tags map<varchar, varchar>,
numberOfSongs tinyint,
releaseDate date,
copiesSold bigint,
....
PRIMARY KEY(albumId)
)
Spanner では、次に示すように、型アノテーションを使用して Cassandra データ型にマッピングします。
CREATE TABLE Albums (
albumId STRING(MAX) OPTIONS (cassandra_type = 'uuid'),
title STRING(MAX) OPTIONS (cassandra_type = 'varchar'),
artists ARRAY<STRING(max)> OPTIONS (cassandra_type = 'set<varchar>'),
tags JSON OPTIONS (cassandra_type = 'map<varchar, varchar>'),
numberOfSongs INT64 OPTIONS (cassandra_type = 'tinyint'),
releaseDate DATE OPTIONS (cassandra_type = 'date'),
copiesSold INT64 OPTIONS (cassandra_type = 'bigint')
...
) PRIMARY KEY (albumId);
上の例では、OPTIONS 句は列の Spanner データ型を対応する Cassandra データ型にマッピングします。
albumId（SpannerSTRING(MAX)）は、Cassandra のuuidにマッピングされます。title（SpannerSTRING(MAX)）は、Cassandra のvarcharにマッピングされます。artists（SpannerARRAY<STRING(MAX)>）は、Cassandra のset<varchar>にマッピングされます。tags（SpannerJSON）は、Cassandra のmap<varchar,varchar>にマッピングされます。numberOfSongs（SpannerINT64）は、Cassandra のtinyintにマッピングされます。releaseDate（SpannerDATE）は、Cassandra のdateにマッピングされます。copiesSold（SpannerINT64）は、Cassandra のbigintにマッピングされます。
cassandra_type オプションを変更する
ALTER TABLE ステートメントを使用すると、既存の列の cassandra_type オプションを追加または変更できます。
まだ cassandra_type オプションがない列にこのオプションを追加するには、次のステートメントを使用します。
ALTER TABLE Albums ALTER COLUMN uuid SET OPTIONS (cassandra_type='uuid');
この例では、Albums テーブルの uuid 列が更新され、cassandra_type オプションが uuid に設定されています。
既存の cassandra_type オプションを変更するには、ALTER TABLE ステートメントを使用して新しい cassandra_type 値を指定します。たとえば、Albums テーブルの numberOfSongs 列の cassandra_type を tinyint から bigint に変更するには、次のステートメントを使用します。
ALTER TABLE Albums ALTER COLUMN numberOfSongs SET OPTIONS (cassandra_type='bigint');
次の型のみを変更できます。
| 変更前 | 変更後 |
|---|---|
| tinyint | smallint、int、bigint |
| smallint | int、bigint |
| int | bigint |
| float | double |
| text | varchar |
| ascii | varchar、text |
直接的なマッピングと調整が必要なマッピング
多くの場合、Spanner と Cassandra のデータ型間のマッピングは簡単です。たとえば、Spanner STRING(MAX) は Cassandra varchar にマッピングされ、Spanner INT64 は Cassandra bigint にマッピングされます。
ただし、マッピングにさらに注意と調整が必要な場合があります。たとえば、Cassandra smallint を Spanner INT64 にマッピングする必要があります。
サポートされている Cassandra 関数
このセクションでは、Spanner でサポートされている Cassandra 関数について説明します。
次のリストに、Spanner でサポートされている Cassandra 関数を示します。
- すべての集計関数
currentTimeUUIDを除くすべての日時関数- blob 変換関数を除くすべてのキャスト関数
BATCH条件を除くすべての軽量トランザクション関数- 次のクエリ関数はいずれも使用不可
Spanner でサポートされていない Cassandra 関数
Cassandra インターフェースは、Cassandra と互換性のあるスキーマ、型、クエリ、クライアントを介して Spanner の機能を提供します。Cassandra の一部の機能はサポートされていません。既存の Cassandra アプリケーションを Spanner に移行する場合、Cassandra インターフェースを使用している場合でも、サポートされていない Cassandra 機能や、クエリの最適化や主キーの設計などの動作の違いに対応するために、ある程度の変更が必要になる可能性があります。ただし、移行後は、ワークロードで Spanner の信頼性と独自のマルチモデル機能を利用できます。
次のリストは、サポートされていない Cassandra 機能の詳細を示しています。
- サポートされていない CQL 言語機能: ユーザー定義型と関数、TimeUUID、TTL、書き込みタイムスタンプ。
- Spanner と Spanner コントロール プレーン: Cassandra インターフェースを使用するデータベースは、Spanner と Google Cloudのツールを使用して、インスタンスのプロビジョニング、保護、モニタリング、最適化を行います。Spanner は、管理アクティビティ用の
nodetoolなどのツールをサポートしていません。
DDL のサポート
CQL DDL ステートメントは、Cassandra インターフェースでは直接サポートされていません。DDL の変更を行うには、Spanner Google Cloud コンソール、gcloud コマンド、またはクライアント ライブラリを使用する必要があります。
接続
Cassandra クライアント サポート
Spanner では、さまざまなクライアントからデータベースに接続できます。
- Cassandra アダプタは、プロセス内ヘルパーとして、またはサイドカー プロキシとして使用して、Cassandra アプリケーションを Cassandra インターフェースに接続できます。詳細については、Cassandra アダプタを使用して Spanner に接続するをご覧ください。
- Cassandra アダプタは、ローカルでスタンドアロン プロセスとして起動でき、
CQLSHを使用して接続できます。詳細については、Cassandra アダプタをアプリケーションに接続するをご覧ください。
Identity and Access Management を使用したアクセス制御
Cassandra エンドポイントに対して読み取りオペレーションと書き込みオペレーションを実行するには、spanner.databases.adapt、spanner.databases.select、spanner.databases.write の権限が必要です。詳細については、IAM の概要をご覧ください。
Spanner IAM 権限を付与する方法については、IAM ロールを適用するをご覧ください。
モニタリング
Spanner には、Cassandra Adapter のモニタリングに役立つ次の指標が用意されています。
spanner.googleapis.com/api/adapter_request_count: Spanner が 1 秒間に実行するアダプタ リクエストの数、または 1 秒間に Spanner サーバーで発生するエラーの数をキャプチャして公開します。spanner.googleapis.com/api/adapter_request_latencies: Spanner がアダプタ リクエストを処理するのにかかる時間をキャプチャして公開します。
カスタム Cloud Monitoring ダッシュボードを作成し、Cassandra アダプタの指標を表示してモニタリングできます。カスタム ダッシュボードには、次のグラフが含まれます。
P99 リクエストのレイテンシ: データベースの
message_typeあたりのサーバー リクエスト レイテンシの 99 パーセンタイルの分布。P50 リクエストのレイテンシ: データベースの
message_typeあたりのサーバー リクエスト レイテンシの 50 パーセンタイルの分布。メッセージ タイプ別の API リクエスト数: データベースの
message_typeあたりの API リクエスト数。オペレーション タイプ別の API リクエスト数: データベースの
op_typeあたりの API リクエスト数。エラー率: データベースの API エラー率。
Google Cloud コンソール
cassandra-adapter-dashboard.jsonファイルをダウンロードします。このファイルには、Monitoring のカスタム ダッシュボードにデータを入力するために必要な情報が含まれています。-
Google Cloud コンソールで [
ダッシュボード] ページに移動します。検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。
- [ダッシュボードの概要] ページで、[カスタム ダッシュボードを作成します] をクリックします。
- ダッシュボード ツールバーで、ダッシュボードの設定アイコンをクリックします。次に、[JSON]、[JSON エディタ] の順に選択します。
- [JSON エディタ] ペインで、ダウンロードした
cassandra-adapter-dashboard.jsonファイルの内容をコピーしてエディタに貼り付けます。 - 変更をダッシュボードに適用するには、[変更を適用] をクリックします。このダッシュボードを使用しない場合は、[ダッシュボードの概要] ページに戻ります。
- ダッシュボードを作成したら、[フィルタを追加] をクリックします。次に、
project_idまたはinstance_idを選択して Cassandra アダプタをモニタリングします。
gcloud CLI
cassandra-adapter-dashboard.jsonファイルをダウンロードします。このファイルには、Monitoring のカスタム ダッシュボードにデータを入力するために必要な情報が含まれています。プロジェクトでダッシュボードを作成するには、
gcloud monitoring dashboards createコマンドを使用します。gcloud monitoring dashboards create --config-from-file=cassandra-adapter-dashboard.json詳細については、
gcloud monitoring dashboards createリファレンスをご覧ください。
また、次の Spanner 指標は、アダプタのモニタリングに役立ちます。
CPU utilization metricsには、ユーザータスクとシステムタスクの CPU 使用率に関する情報と、優先度とオペレーション タイプ別の内訳が表示されます。Storage utilization metricsは、データベースとバックアップ ストレージに関する情報を提供します。Spanner built-in statistics tablesは、クエリ、トランザクション、読み取りに関する分析情報を提供して、データベースの問題を検出します。
システム分析情報の一覧については、システム分析情報を使用してインスタンスをモニタリングするをご覧ください。Spanner リソースのモニタリングの詳細については、Cloud Monitoring を使用してインスタンスをモニタリングするをご覧ください。
料金
Cassandra エンドポイントの使用に追加料金はかかりません。インスタンスで使用されるコンピューティング容量とデータベースで使用されるストレージの量に対して、標準の Spanner 料金が請求されます。
詳細については、Spanner の料金をご覧ください。
次のステップ
- Cassandra から Spanner に移行する方法を確認する。
- Cassandra アダプタを使用して Spanner に接続する方法を確認する。