Cassandraとは？分散NoSQLの仕組み・データモデル・採用判断を実装者目線で解説

Apache Cassandraは、複数のノードに同じデータを複製して持たせることで、一部のサーバーが落ちても読み書きを止めない設計の分散データベースです。書き込みを受け付ける親役のノードを置かず、どのノードに投げても同じように処理できるところに他のデータベースとの一番の差があります。

この記事では、これから分散データ基盤の技術選定に入る実装者に向けて、Cassandraがどういう仕組みで分散と複製を成立させているのか、なぜリレーショナルデータベースの設計をそのまま持ち込むと失敗するのか、そして運用に入ったあと何にコストを払うことになるのかを整理します。採用してよい条件と見送るべき場面も、要件の形に落として言い切ります。

まとめ：Cassandraの仕組みと採用判断の要点

• 構成：親子関係を持たないピアツーピアのリング構成。単一障害点がなく、ノードを足せば書き込み容量がほぼ線形に伸びます
• 整合性：強い整合性か低遅延かをクエリ単位で選べます。読み書きの整合性レベルの合計がレプリケーション係数を超える組み合わせにすると、常に最新の値を読めます
• データモデル：テーブルを先に決めるのではなく、投げたいクエリを先に決めて、それ専用のテーブルを並べる設計です。同じ事実を複数テーブルへ二重に書きます
• 運用コスト：肥大したパーティションと削除マーカーの滞留が二大障害。修復とコンパクションが定常的にディスクとCPUを食います
• 判断：書き込みが読み出しを上回り、複数拠点で止められず、クエリ形がほぼ固定という3条件が揃うときに効きます。集計や結合が要る分析用途なら別の手段を選んでください

Cassandraの実体｜マスターを持たない分散型データベース

リング構成とコンシステントハッシュでデータを分散させる仕組み

Cassandraはクラスタ内の全ノードを対等に扱います。書き込みを受け取ったノードがコーディネーターとなり、パーティションキーをハッシュしたトークン値から担当ノードを割り出して転送する、という流れです。ハッシュ空間を円環に見立てて担当範囲を割り当てるため、この構成はリングと呼ばれます。

各ノードは物理的に1台であっても、トークン空間上では複数の担当範囲を持ちます。これが仮想ノードで、4.0系以降のデフォルトは1ノードあたり16です。担当範囲を細かく刻んでおくと、ノードを1台追加したときのデータ移動が特定のノードに偏らず、増設と縮退がなだらかになります。ノードの生死や参加離脱はゴシッププロトコルで相互に伝播し、参加時の入口となるシードノードだけを設定で指定しておく形です。

この分散の考え方は、リレーショナルデータベースの水平分割とは前提が違います。データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説で整理しているRDBとNoSQLの分岐を踏まえると、Cassandraは可用性と分割耐性を先に取り、整合性を後から調整するタイプに位置づけられます。

レプリケーション係数と整合性レベルをどう組み合わせて決めるか

複製の本数はキースペース単位で決定する仕組みです。レプリケーション係数を3にすれば、1件のデータはリング上の連続する3ノードに書かれます。複数のデータセンターにまたがるクラスタなら、拠点ごとに別々の係数を指定する方式を選び、東京に3本・大阪に3本といった配置ができます。

整合性レベルはクエリごとに指定します。読み書きそれぞれ何ノードからの応答を待つかという設定で、この2つの和がレプリケーション係数を上回れば、必ず最新の書き込みを含むノードに当たります。係数3で読み書きともに過半数を要求する組み合わせが実務上の基準線でしょう。拠点をまたぐ待ち時間を避けたい場合は、自拠点内の過半数だけを待つ指定に切り替えます。

書き込みと読み出しの経路とLSMツリーによる保存の仕組みの全体像

書き込みは、まず追記専用のコミットログに落とし、同時にメモリ上のメムテーブルへ反映して完了を返します。ディスク上の既存データを探しに行かないため、書き込みは一貫して速い。メムテーブルが一定量を超えるとディスクへ書き出され、SSTableという不変ファイルになります。既存ファイルを書き換えることはせず、更新も削除も新しいファイルへの追記として表現する、というのがLSMツリーの構造です。

読み出しはその裏返しで、同じ行の断片が複数のSSTableに散らばっている前提で動きます。各SSTableのブルームフィルタで「このファイルに無い」を高速に弾き、残った候補だけをインデックス経由で読んでマージし、タイムスタンプの新しい値を返す流れです。断片が増えるほど読み出しは遅くなるため、後述するコンパクションでファイルを畳む処理が定常的に走り続けます。

Cassandraのデータモデル｜クエリ起点で設計する考え方

パーティションキーとクラスタリングカラムが決める物理的な配置

Cassandraの主キーは2つの役割に分かれます。前半のパーティションキーがどのノードに置くかを決め、後半のクラスタリングカラムがパーティション内での並び順を決めます。時系列データなら、機器IDと時間バケットをパーティションキーにし、計測時刻をクラスタリングカラムに置くのが定石です。

CREATE TABLE sensor_readings (
  device_id text,
  time_bucket text,
  reading_at timestamp,
  value double,
  PRIMARY KEY ((device_id, time_bucket), reading_at)
) WITH CLUSTERING ORDER BY (reading_at DESC);

この設計だと、機器と時間バケットを指定した範囲読み出しが1パーティションへの連続アクセスで済みます。逆に、パーティションキーを与えずに値の条件だけで検索しようとすると全ノードを舐める動きになり、CQLは明示的な許可指定を求めてきます。その指定を本番のクエリに書いた時点で設計を間違えている、と考えたほうが安全です。

RDBの正規化をそのまま持ち込むと破綻する理由と回避の考え方

Cassandraには結合がありません。正規化して複数テーブルに分けた設計をそのまま持ち込むと、アプリケーション側で何度も往復して手作業で突き合わせる羽目になります。分散環境では、その往復1回ごとにネットワーク越しの遅延が積み上がっていきます。

そこで取るのが、クエリ起点でテーブルを設計する進め方です。画面や機能から「この条件でこの順に取りたい」を先に列挙し、その1本ごとに専用テーブルを作ります。同じ事実が3つの画面から引かれるなら、テーブルを3つ用意して同じ内容を3回書く。ディスクは安く、書き込みは速いという特性を前提に、読み出し側の都合へ寄せる割り切りです。この二重書きの整合はアプリケーションの責任になるため、書き込み処理をひとつの関数に集約しておく設計が後から効いてきます。

5.0系で追加されたSAIとベクトル型が緩めた検索まわりの制約

従来のセカンダリインデックスは、全ノードへ問い合わせが飛ぶ構造から本番での使用を避けられてきました。5.0系で入ったストレージ接続型インデックス（SAI）は、SSTableと同じライフサイクルで管理される仕組みに変わり、複数カラムへのインデックス付与と条件の組み合わせが現実的なコストで扱えるようになっています。

同じく5.0系ではベクトル型と近似近傍検索が追加されました。埋め込みベクトルを別のベクトルデータベースへ逃さず、業務データと同じテーブルに置いたまま類似検索をかけられます。ただしこれらは制約を緩めたのであって、無制限に条件を投げてよくなったわけではありません。パーティションキーで絞ってからインデックスで絞る、という基本の順序は変わらないままです。

Cassandraの運用で特に効いてくる負荷と設計上の落とし穴

大きすぎるパーティションとトゥームストーンが招く深刻な性能の劣化

運用で最初に踏むのが、1つのパーティションが太りすぎる問題です。パーティションは分割されずに1ノードへ載るため、時間バケットを入れずに機器IDだけをキーにすると、データが増え続けて片端から遅くなります。目安として100MB前後、行数で10万行あたりを超え始めたら設計の見直し時期と捉えてください。バケット幅を日単位から時間単位へ刻み直すのが定番の手当てです。

もうひとつがトゥームストーンと呼ばれる削除マーカーです。Cassandraは削除を「削除した」という記録の追記で表現するため、消した分だけ読み出し時に読み飛ばす対象が増えます。この記録は既定で10日間保持され、その間に修復が完走しないと削除したはずのデータが復活する。閾値を超えるとクエリ自体が失敗する保護も入っているので、頻繁な削除を前提とした設計は避け、期限切れで消える仕組みや時間帯別テーブルの入れ替えへ寄せるのが現実的な進め方です。

修復とコンパクションという定常運用で食われるリソースの見積り

ノード間のデータのずれは3つの経路で埋められます。書き込み時に落ちていたノードの分を代理保持して後で渡すヒンテッドハンドオフ、読み出し時に古い値を見つけて直すリードリペア、そして全体を突き合わせる修復処理です。前2つは自動で効きますが、削除マーカーの保持期間内に全ノードを1周する修復を回し切ることは運用者の責任として残ります。

コンパクションは、散らばったSSTableを畳んで読み出し性能を保つ処理です。従来は書き込み重視・読み出し重視・時系列向けの戦略から選ぶ形でしたが、5.0系では設定値でその中間を連続的に指定できる統合戦略が入りました。いずれにせよ、畳み込み中は元ファイルと新ファイルが同時に存在するため、ディスクは使用量の実測値に対して余裕を持たせる前提になります。CPUとI/Oも定常的に持っていかれるので、ピーク時の空き容量だけを見た容量計画は外れます。

5.0.8系と6.0系alphaという版の現在地と選び方の基準

2026年7月時点で公開されている系列は3つです。5.0系の最新は5.0.8で、8.0のリリースまで維持されると案内されています。4.1系は4.1.11で7.0まで、4.0系は4.0.20で6.0までという扱いです。新規に構築するなら5.0系を選び、SAIとベクトル型を前提に設計できる状態から始めるのが素直でしょう。

6.0系については、2026年3月21日にalpha1がApacheの成果物として公開された段階です。汎用の分散トランザクションを入れるCEP-15と、クラスタメタデータの扱いを変えるCEP-21が主題で、実現すれば「軽量トランザクションは遅いので使わない」という現在の前提が変わります。ただしalphaは本番の判断材料にはなりません。いま設計するなら5.0系の機能だけで成立させ、6.0系は移行時の選択肢として頭の隅に置く程度に留めてください。

他のNoSQLとRDBに対するCassandraの使い分けの基準

DynamoDBやBigtableとの違いをどこで見分けるか

Cassandraと同じ系譜のデータベースはいくつもあります。AWS DynamoDBとは？特徴・使い方・料金・RDSとの違いを実装目線で解説で扱っているDynamoDBは、分散の考え方こそ近いものの、運用をAWSへ丸ごと預ける代わりにクラスタの内部設定へ手を入れられません。テーブル設計の自由度とチューニングの余地を取るならCassandra、運用人員を持たない前提ならDynamoDBという分かれ方をします。

Cloud Bigtableとは？GCPのワイドカラム型NoSQLの仕組みと採用判断を実装目線で解説で解説しているBigtableは、データモデルの発想がCassandraと同じワイドカラム型です。違いは複製の設計にあり、Bigtableは行キー順に並べた1本の空間を分割する方式を取ります。GCPに寄せた構成で、行キーの範囲スキャンを主軸にするならBigtable、拠点をまたいで書き込みを受けたいならCassandraという切り分けになります。

RDBやドキュメント型へ寄せたほうがよい場面の切り分けの基準

結合、集計、任意条件での検索が業務の中心にあるなら、Cassandraは向きません。分析用のクエリを毎回テーブル追加で解決するのは現実的ではなく、集計処理を別基盤へ逃がす構成が前提になります。トランザクションで複数行の整合を担保したい要件も、軽量トランザクションで書けはするものの遅く、常用する設計にはなりません。

データの形が案件ごとに揺れる、スキーマを頻繁に足すといった性質ならドキュメント型のほうが素直です。逆に、行数は多いがアクセスパターンが決まりきっていて、拠点障害でも書き込みを止められないという要件では、Cassandraの分が明確に良くなります。判断軸は規模ではなくクエリ形の固定度合いだと考えてください。

マネージドとセルフホストのどちらを選ぶかという判断の分かれ目

Cassandraをそのまま自前で運用する場合、修復のスケジュール管理、コンパクション戦略の調整、JVMのメモリ設定、ノード増設時の手順といった作業が継続的に発生します。専任がいないチームでこれを抱えると、障害時の初動が遅れて可用性を取りに来たはずの構成が裏目に出ます。

Cassandra互換のインタフェースを保ったままこれらを預ける選択肢が、AWSのマネージドサービスです。Amazon Keyspacesとは？Cassandra互換サーバーレスDBの仕組み・料金・採用判断を実装者目線で解説に料金モデルと機能の対応範囲をまとめてあります。CQLとドライバーはそのままに、クラスタ管理だけを外に出せるかたちですが、細かいチューニングの余地は減ります。運用に人を割けるならセルフホスト、割けないならマネージド、という分かれ目で先に決めておくと、後の設計判断がぶれません。

Cassandraを採用してよい条件と見送るべき場面の判断整理

Cassandraの採用が効く条件をワークロードから見極める

採用が効くのは、次の3つが揃うときです。第一に、書き込みの量が読み出しを上回るか同程度であること。センサーの計測値、機器のイベントログ、課金の明細といった追記中心のデータが該当します。第二に、単一拠点の障害でも書き込みを止められないこと。複数データセンターへ複製を分け、拠点内の過半数だけを待つ指定にすれば、片方が落ちても書き込みは継続できます。

第三が、クエリの形がほぼ固定されていることです。画面や機能から引かれる条件が数種類に収まっていれば、専用テーブルを並べる設計が破綻しません。この3つが揃った上で、データ量が単一ノードのディスクに収まらない規模まで伸びる見込みがあるなら、Cassandraを本命に置いてよいでしょう。

Cassandraを見送るべき場面と別の手段へ振り替える目安

逆に、次のいずれかに当たるなら見送りが妥当です。データ量が数百GB程度で頭打ちになる見込みなら、リレーショナルデータベースのレプリケーション構成のほうが運用も検索の自由度も上回ります。集計や結合を伴う分析が主目的なら、列指向のデータウェアハウスへ振り替えてください。要件がまだ固まらず、クエリの形が今後変わり続けるという段階でも、テーブルを作り直す負担が重いため向きません。

判断に迷ったときは、「1年後にどんなクエリを投げているか説明できるか」を自問すると切り分けやすくなります。説明できるならCassandraの設計は書けます。説明できないうちは、いったん別の基盤で運び、アクセスパターンが固まってから移す進め方のほうが総コストは低く収まる。この段取りは実際の案件でもよく取る形です。

採用を決めたあとに最初に踏むべき検証ステップの組み立て方と順序

本番投入の前に踏むべき検証は3段階です。まず、想定クエリを列挙してテーブル定義に落とし、1パーティションが1年後にどこまで太るかを試算します。次に、本番と同じレプリケーション係数と整合性レベルで3ノード以上を組み、書き込み負荷をかけた状態でノードを1台落として応答が続くかを実測してください。最後に、修復を1周させて所要時間を測り、削除マーカーの保持期間内に収まるかを確認します。

この3つを踏まずに構築すると、運用開始から数か月後にパーティション設計のやり直しという最も高いコストを払うことになります。設計の妥当性判断や検証環境の構築に社内の手が足りない場合は、データ分析基盤構築・MLOps構築支援で、要件からのデータモデル設計と負荷検証の設計までを支援しています。分散データベースの選定は後戻りの費用が大きい領域なので、机上の比較で決め切らず、実測を挟んでから判断するのが確実です。

よくある質問

Cassandraは無料で使えますか？

Apache License 2.0のオープンソースソフトウェアなので、ソフトウェア自体のライセンス費用はかかりません。費用として乗ってくるのはサーバー、ストレージ、そして運用工数です。特に複製を3本持つ構成では実データ量の3倍のディスクに加えて、コンパクション用の空き容量も見込む必要があります。商用サポートが要るならDataStax系のディストリビューションやマネージドサービスという選択肢もあります。

CassandraとScyllaDBはどちらを選ぶべきですか？

ScyllaDBはCassandraと同じCQLとドライバーを使えるC++実装で、JVMのガベージコレクションに起因する遅延の揺れを避けられる点が売りです。レイテンシの上振れが業務に直結し、かつチームがCassandraの運用に慣れていない場合は検討に値します。一方でコミュニティの厚みやドキュメントの蓄積、周辺ツールの対応範囲ではApache Cassandraのほうが手厚く、情報が見つからずに詰まるリスクは低くなります。

ノードは最低何台から組めばよいですか？

検証なら1台でも起動しますが、Cassandraの利点は複製があって初めて出るため、実質の最小構成は3台です。レプリケーション係数3で過半数を要求する運用にすると、1台落ちても読み書きが継続します。2台構成では過半数が2になり、1台の障害で書き込みが止まるため意味がありません。複数拠点にするなら各拠点3台、合計6台からが基準線になります。

Cassandraでトランザクションは使えますか？

2026年7月時点の5.0系では、単一パーティション内の条件付き更新として軽量トランザクションが使えます。ただし合意形成のためにノード間の往復が複数回発生し、通常の書き込みと比べて明らかに遅い。在庫の引き当てなど本当に必要な箇所に限定して使う前提で設計してください。複数パーティションにまたがる汎用トランザクションは6.0系で扱われている段階で、alpha公開の状況にあります。

既存のRDBからCassandraへ移行できますか？

テーブル定義をそのまま移す形の移行はできません。結合と任意条件の検索を前提にしたスキーマは、クエリ起点で組み直す作業が必須になります。実務では、まず移行対象のクエリを洗い出し、Cassandra側のテーブル群を新規設計してから二重書きの期間を設け、読み出しを段階的に切り替える進め方を取ります。全テーブルを一度に移すのではなく、書き込み量の多いテーブルから部分的に外出しする形が安全です。

関連記事

• Amazon Keyspacesとは？Cassandra互換サーバーレスDBの仕組み・料金・採用判断を実装者目線で解説：Cassandra互換のまま運用を外に出す選択肢を料金モデルから整理しています
• Cloud Bigtableとは？GCPのワイドカラム型NoSQLの仕組みと採用判断を実装目線で解説：同じワイドカラム型で複製設計が異なるGCP側の選択肢です
• Azure Cosmos DBとは？マルチモデルNoSQLの仕組み・整合性レベル・RU課金と採用判断を実装者目線で解説：整合性レベルを5段階から選ぶ設計との比較材料になります
• データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説：RDBとNoSQLの分岐を上流から整理した記事です
• MongoDBとは？ドキュメント指向データベースの構造・ドキュメント・使い方入門：スキーマの揺れに強いドキュメント型との違いを確認できます