このページは Cloud Translation API によって翻訳されました。

Cassandra インターフェース

このページでは、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`（可変精度の整数）	固定精度の小数数の場合は、`NUMERIC` データ型（精度 38、スケール 9）を使用します。
文字列型	`text`	`STRING(MAX)` `text` と `varchar` の両方が、UTF-8 文字列の保存と検証を行います。Spanner では、`STRING` 列の最大長を指定する必要があります。ストレージへの影響はありません。これは検証を目的としています。
	`varchar`
	`ascii`	`STRING(MAX)`
	`uuid`	`STRING(MAX)`
	`timeuuid`	`STRING(MAX)`
	`inet`	`STRING(MAX)`
`blob`	`BYTES(MAX)` バイナリデータを保存するには、`BYTES` データ型を使用します。
日時型	`date`	`DATE`
	`time`	`INT64` Spanner は専用の時間データ型をサポートしていません。ナノ秒の期間を保存するには、`INT64` を使用します。
	`timestamp`	`TIMESTAMP`
	`duration`	`STRING(MAX)` Spanner は保存された期間型をサポートしていません。期間を保存するには、`STRING` を使用します。
コンテナタイプ	`set`	`ARRAY` Spanner は専用の `set` データ型をサポートしていません。`set` を表すには、`ARRAY` 列を使用します。
	`list`	`ARRAY` `ARRAY` を使用して、型付きオブジェクトのリストを保存します。
	`map`	`JSON` Spanner は専用のマップ型をサポートしていません。地図を表すには、`JSON` 列を使用します。
その他の型	`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,
  score frozen<set<int>>
  ....
  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'),
  score         ARRAY<INT64> OPTIONS (cassandra_type = 'frozen<set<int>>')
  ...
) PRIMARY KEY (albumId);

上の例では、OPTIONS 句は列の Spanner データ型を対応する Cassandra データ型にマッピングします。

albumId（Spanner STRING(MAX)）は、Cassandra の uuid にマッピングされます。
title（Spanner STRING(MAX)）は、Cassandra の varchar にマッピングされます。
artists（Spanner ARRAY<STRING(MAX)>）は、Cassandra の set<varchar> にマッピングされます。
tags（Spanner JSON）は、Cassandra の map<varchar,varchar> にマッピングされます。
numberOfSongs（Spanner INT64）は、Cassandra の tinyint にマッピングされます。
releaseDate（Spanner DATE）は、Cassandra の date にマッピングされます。
copiesSold（Spanner INT64）は、Cassandra の bigint にマッピングされます。
score（Spanner ARRAY<INT64>）は、Cassandra の frozen<set<int>> にマッピングされます。

`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 条件を除くすべての軽量トランザクション関数
次のクエリ関数はいずれも使用不可

有効期間（TTL）

Cassandra から移行する場合は、INSERT ステートメントまたは UPDATE ステートメントの USING TTL オプションまたは Spanner TTL を使用するために、Spanner テーブルに行削除ポリシーを追加します。

Spanner の TTL ロジックは行レベルで動作します。これに対し、Cassandra では TTL ロジックをセルレベルで適用できます。Spanner TTL を使用するには、行削除ポリシーにタイムスタンプ列と時間間隔を含める必要があります。Spanner は、行がタイムスタンプを基準として指定された期間を超えると、その行を削除します。

Spanner TTL の削除は瞬時には行われません。非同期のバックグラウンドプロセスで期限切れの行が削除されます。削除には最大 72 時間かかることがあります。

詳細については、Cassandra データで TTL を有効にするをご覧ください。

Spanner でサポートされていない Cassandra 関数

Cassandra インターフェースは、Cassandra と互換性のあるスキーマ、型、クエリ、クライアントを介して Spanner の機能を提供します。Cassandra の一部の機能はサポートされていません。既存の Cassandra アプリケーションを Spanner に移行する場合、Cassandra インターフェースを使用している場合でも、サポートされていない Cassandra 機能や、クエリの最適化や主キーの設計などの動作の違いに対応するために、ある程度の変更が必要になる可能性があります。ただし、移行後は、ワークロードで Spanner の信頼性と独自のマルチモデル機能を利用できます。

次のリストは、サポートされていない Cassandra 機能の詳細を示しています。

サポートされていない CQL 言語機能: ユーザー定義型と関数、書き込みタイムスタンプ。
Spanner と Google Cloud コントロールプレーン: 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 指標は、Cassandra Adapter のモニタリングに役立ちます。

CPU 使用率指標には、ユーザータスクとシステムタスクの CPU 使用率に関する情報と、優先度とオペレーションタイプ別の内訳が表示されます。
ストレージ使用率の指標は、データベースとバックアップストレージに関する情報を提供します。
Spanner の組み込み統計テーブルは、クエリ、トランザクション、読み取りに関する分析情報を提供して、データベースの問題を検出します。

システム分析情報の一覧については、システム分析情報を使用してインスタンスをモニタリングするをご覧ください。Spanner リソースのモニタリングの詳細については、Cloud Monitoring を使用してインスタンスをモニタリングするをご覧ください。

料金

Cassandra エンドポイントの使用に追加料金はかかりません。インスタンスで使用されるコンピューティング容量とデータベースで使用されるストレージの量に対して、標準の Spanner 料金が請求されます。

詳細については、Spanner の料金をご覧ください。

次のステップ

Cassandra から Spanner に移行する方法を確認する。
Cassandra アダプタを使用して Spanner に接続する方法を確認する。
Cassandra ユーザー向け Spanner の Codelab を試す。

Cassandra インターフェース コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

基本コンセプト

用語

アーキテクチャ

整合性

Cassandra インターフェース

Cassandra インターフェースのメリット

CQL の互換性

サポートされている Cassandra データ型

データ型のアノテーション

cassandra_type オプションを変更する

直接的なマッピングと調整が必要なマッピング

サポートされている Cassandra 関数

有効期間（TTL）

Spanner でサポートされていない Cassandra 関数

DDL のサポート

接続

Identity and Access Management を使用したアクセス制御

モニタリング

Google Cloud コンソール

gcloud CLI

料金

次のステップ

Cassandra インターフェース

`cassandra_type` オプションを変更する