Cassandraとは｜分散NoSQLの特徴・Redis／MongoDBとの違い・案件単価をフリーランス視点で解説

Cassandraとは：Apache発の分散ワイドカラムDB

結論として、CassandraはApache Software Foundationが管理するオープンソースの分散ワイドカラム型NoSQLデータベースです。複数台のノードを横並びにつなぎ、書き込みと読み込みを分散して処理する設計になっています。

もともとはFacebookが社内のメッセージ受信箱検索のために開発し、2008年にオープンソース化、2010年にApacheのトップレベルプロジェクトへ昇格しました。現在は商用ディストリビューションをDataStax社が提供しており、AWSも互換マネージドサービスとしてAmazon Keyspacesを出しています。一次情報はApache Cassandra 公式サイトが中心です。

執筆時点（2026年6月）で公開されているメジャーリリースは4.1系・5.0系が中心です。バージョン間で機能差が大きいため、参画する案件でどの系統が動いているかは入場前に必ず確認してください。採用状況やサポート対象は案件ごとに差があるため、対応バージョンとサポート状況はApache公式のリリース情報で必ず確認してください。 古い3.x系が残っている現場では、サポート状況とアップデート計画の有無を入場前に確認しておくと安全です。

ワイドカラムストアの考え方

Cassandraの結論は「1行に可変な列を持てるテーブル構造を、複数ノードに分散保存する」ことです。RDBのように「すべての行が同じ列を持つ」前提ではなく、行ごとに必要な列だけ持たせられます。

データモデル上の階層は、パーティションキーで物理配置を決め、クラスタリングキーで行内の並びを決め、その下に値となるカラム群が並ぶ構造です。読み出しはこのキー順に最適化されるため、検索パターンを先に決めてからテーブル設計をするのが定石になります。

RDBの正規化を前提に「とりあえずテーブルを切る」発想はうまく機能しません。同じデータを複数のテーブルに重複して持つことを許容し、検索パターンごとにテーブルを増やすのが基本姿勢です。

CAP定理におけるAP特性

CassandraはCAP定理の中で可用性（Availability）と分割耐性（Partition tolerance）を優先する設計とされています。整合性（Consistency）はデフォルトで結果整合（Eventually Consistent）になります。

ただし、整合性レベルは書き込み・読み込み単位で細かく指定でき、過半数のレプリカで一致を待つQUORUM、すべてのレプリカで一致を待つALLなど、強整合寄りの設定にもチューニングできます。「常に結果整合」ではなく、可用性側に振りやすいがチューニング可能という理解が正確です。

アーキテクチャと内部の仕組み

結論として、Cassandraは特定の管理ノードを持たないピアツーピア構成で、どのノードも対等にリクエストを受け付けます。リーダー選出が不要で、1台落ちてもクラスタ全体の機能は維持されます。

マスターレス構成（リング型）

クラスタはノードが論理的なリング状に並ぶ構造で表現されます。クライアントはどのノードに接続してもよく、接続先（コーディネーターと呼びます）が他ノードへの転送を裁きます。

このため、ワークロード次第ではノード追加で比較的線形に近い拡張がしやすい設計とされ、大量の書き込みが必要なワークロードで採用される背景になっています。リーダー再選出のダウンタイムを避けたい現場では有力候補に挙がりやすい構造です。実際のスケール特性はパーティション設計・ネットワーク・コンパクション条件で変動します。

パーティショニングとレプリケーション

データはパーティションキーをハッシュ化し、リング上のどのノードに置くかが決まります。複数台にレプリカを持たせることで、ノード障害時にも別ノードからデータを返せます。

レプリケーション係数（RF）は事前に決めて運用します。単一データセンター構成ではRF=3がよく採られ、1ノード障害でも止まらない水準を出しやすい設定です。データセンター間のレプリケーション設定（NetworkTopologyStrategy）を使うと、地理的な可用性も確保できます。複数DC構成や可用性・コスト要件によってRFは変わるため、絶対値ではなく設計時に必ず見直すパラメータとして扱うのが安全です。

整合性レベルのチューニング

書き込み・読み込みごとに、何台のレプリカで一致を待つかを指定できます。ONEなら1台で確定、QUORUMなら過半数、ALLなら全レプリカで一致を待つ挙動です。

可用性とレイテンシを優先するならONE、整合性を高めたいならQUORUMがよく使われます。実際の整合性は、RFと読み書きCLの組み合わせで決まる点に注意してください（例：RF=3／読み書きともQUORUMで強整合に近い挙動になる）。ALLは整合性を最も強くできますが1ノード落ちただけで失敗するため、運用では避けられがちです。

ストレージエンジン（LSMツリー）

書き込みはコミットログとメモリ上のテーブル（Memtable）にいったん書かれ、後でディスク上のSSTableにフラッシュされます。書き込みは速く、更新・削除はあとから整理される設計のため、ランダムな大量書き込みワークロードに強い構造です。

その代わり、削除は「墓石（tombstone）」として残り、コンパクションで掃除されるまで読み取りコストに影響します。tombstoneの大量発生は運用上の代表的なつまずきポイントなので、削除頻度の高いデータモデリングは避けるのが無難です。

CassandraとRedis／MongoDB／RDBの違い

結論として、CassandraとRedis・MongoDB・RDBは「同じNoSQLや同じDB」とまとめてしまうと使い分けを誤ります。用途・データモデル・整合性の3軸で見ると棲み分けがはっきりします。

主要DBとの比較表

Redisとの違い：永続化前提か、キャッシュ前提か

Redisとの結論は「Redisは揮発前提のインメモリ高速層、Cassandraは永続化前提の分散DB」で、そもそも層が違います。Redisにも永続化機能はありますが、メインの用途はキャッシュやセッション、レート制限、ランキングなどの一時データです。

Cassandraはディスク永続化を前提に、テラバイト級以上のデータを継続的に書き続ける場面で使われます。RedisとCassandraを並べて検討する場面は実は少なく、組み合わせて使う現場のほうが多いのが実情です。読み取りキャッシュをRedis、本データをCassandraという構成は定番のひとつです。

MongoDBとの違い：ドキュメント型かワイドカラムか

MongoDBとの結論は「MongoDBはネストしたJSONドキュメントを扱うことに向き、Cassandraは大量書き込み・時系列・地理分散に向く」で、データモデルの自由度と書き込みワークロードのスケーラビリティが論点になります。

MongoDBは1ドキュメント内の構造が柔軟で、コンテンツ管理・カタログ・ログのような「形が変わりやすい」データに向きます。レプリカセットによる可用性はあるものの、設計思想としてはCP寄りです。

Cassandraはドキュメント単位の柔軟性は低い代わりに、書き込みを止めずにノード追加で拡張しやすい設計で勝ります。書き込みが秒間数万件以上で常時走るような現場、複数リージョンに書き込み点を分散したい現場では、Cassandraが候補に挙がりやすくなります。

RDBとの違い：トランザクションを諦めて分散性を取る

RDBとの結論は「トランザクションの強さを取るならRDB、書き込み分散と無停止性を取るならCassandra」です。

CassandraにもACIDに近い軽量トランザクション（LWT）はありますが、これは単一パーティション内の限定的な仕組みです。複数テーブル・複数パーティションをまたぐACIDトランザクションは想定されていません。会計・決済・在庫など、複数行を一貫して書き換える必要がある業務系は、引き続きPostgreSQLやMySQLなどのRDBが適します。

AWS RDSのようなマネージドRDBで足りる規模であれば、わざわざCassandraを入れる必要はありません。「RDBでは無理だった」が出てきてから検討するDBという位置付けが現実的です。

Cassandraの主なユースケース

結論として、Cassandraが選ばれるのは「大量の書き込みを止められない／結果整合で許容できる／構造がそろっている」3条件が揃う場面です。

時系列・IoTデータ

センサーや端末から大量のメトリクスを継続的に取り込む用途は、Cassandraの代表的な活用領域です。書き込みが秒間数千〜数万に達するワークロードでも、パーティションキー設計を整えれば線形にスケールできます。

時系列特化のClickHouseやInfluxDBとも競合しますが、マルチデータセンター運用と書き込み可用性が要件ならCassandraが優位に出ます。

メッセージ・通知・アクティビティログ

DiscordがMongoDBからCassandra（および後継のScyllaDB）へ移行した事例はDiscordの技術ブログ等で公開されています。チャットやアクティビティのような「過去ログを残し続ける」用途は、追記型ストレージのCassandraと相性が良い領域です。

大規模Webサービスのユーザーデータ

Netflixはユーザーアクティビティ・視聴履歴・パーソナライズ用データの一部にCassandraを採用してきたことを技術ブログで公開しています。1リージョン障害でサービスを止めない水準を狙う場面で、地理分散レプリケーションが効きます。

広告・ゲーム・金融市場データ

イベント発生数がきわめて多い領域でも採用例があります。ただし、強整合が必要な決済系トランザクションには向きません。「書き込み点が多く、結果整合で問題ない要件」を見極めるのがポイントです。

Cassandra案件の単価相場とフリーランス需要

結論として、フリコンが確認できる公開案件ベースで見る限り、Cassandra単独で募集されるケースは少なく、データ基盤エンジニア／バックエンドエンジニアのスタック要件のひとつとして登場するパターンが中心です。

公開案件で見る単価帯の目安

※2026年6月時点でフリコンおよび主要フリーランスエージェントの公開案件のうち、Cassandraを必須または歓迎要件に含む首都圏中心・週4〜5日・業務委託のものを参考にした目安です。個別の年収・スキル・契約形態で大きく変動します。

求人数で見ると、MySQL・PostgreSQLの案件と比べてCassandra単独募集はかなり限定的です。「Cassandraが書ける」より「分散NoSQLの設計・運用が任せられる」レベルが評価される傾向があります。

求められるスキルセット

公開案件で頻出する併用技術には以下のような傾向があります。NoSQLだけでなくクラウド基盤・データ基盤の周辺技術がセットで求められます。

• クラウド基盤：AWS ／GCP ／Azure（マネージドサービスとしてはAmazon KeyspacesやBigtable等の経験も評価対象）

• データ基盤：Snowflake ・Apache Kafka・Spark等のストリーミング／バッチ処理基盤

• 言語：Java・Scala・Python・Goなど分散システムで採用されやすい言語

• 監視・運用：Datadog ・Prometheus等での監視設計、JVMチューニング経験

• DB設計力：CQLとデータモデリング、パーティション設計、tombstone対策の理解

Cassandra案件に近づくための立ち位置

直接Cassandraに触れたことがない場合でも、データエンジニアやバックエンドエンジニアとしてMySQL／PostgreSQLとMongoDBの両方の実務を踏んでいると、案件側からのキャッチアップ許容度は上がります。「RDBとドキュメント型を両方分かったうえでワイドカラムを扱える」人材として説明しやすいためです。

データベーススペシャリスト試験などの資格があると、設計レベルでの信頼性を補強しやすい点も覚えておいてよいでしょう。

採用前のチェックリスト：Cassandraを入れるべきか

結論として、Cassandraは万能ではありません。「データ規模・書き込みパターン・整合性要件・運用体制」の4軸で必要性を判定してから採用するのが現実的です。

採用前に必ず確認したい質問

1. データ量はテラバイト級以上に伸びる見込みがあるか（数十GB止まりならRDBで十分なケースが多い）

2. 書き込みが秒間数千件以上で常時走り続ける見込みがあるか

3. 強整合が必要なトランザクション境界はないか（決済・在庫など）

4. 結果整合で許容できる業務要件かを関係者と合意できているか

5. ノード追加・コンパクション・JVM運用を担える人員・体制を確保できるか

6. マネージド版（Amazon Keyspaces等）で代替できないか

複数項目で「No」が付く、または重要項目（書き込み量・整合性要件・運用体制）で「No」が出るなら、まずはAWS RDSやMongoDBなどより導入負担の軽い選択肢を検討するのが妥当です。

向いていないユースケース

• 数十万〜数百万行程度の小〜中規模データで完結する業務システム

• 複数テーブルにまたがる頻繁なJOINと集計が必要な分析要件（ここはRDBやSnowflakeなど分析向けが得意）

• 強整合トランザクションが業務要件として外せないシステム

• 運用人員が極端に薄く、トラブル時にJVMやノードの状態を読める人がいない体制

よくある失敗と運用での落とし穴

結論として、Cassandraで詰まる典型はデータモデリング・tombstone・運用観点の3カテゴリに集中します。事前に押さえておくと、参画後の地雷を避けやすくなります。

モデリングの失敗

• パーティションキーに偏りがあり、特定ノードにアクセスが集中する（ホットパーティション）

• パーティション内のデータが大きくなりすぎて、読み出しが遅くなる（巨大パーティション）

• 検索パターンを後から増やそうとして、既存テーブルでは対応できないことに気付く

先にクエリを決めてからテーブルを切る原則を守ることが、もっとも事故を減らすポイントになります。

tombstoneと削除パターン

頻繁な削除・更新が走るモデルではtombstoneが大量発生し、読み取りが急に重くなります。TTLによる自動失効も内部的にはtombstoneを発生させる点に注意が必要です。TTL活用、論理削除への切り替え、書き換え頻度の高いデータを別テーブルに分離するなど、tombstoneの影響を抑えやすい設計を最初に組むのが安全です。

運用の見落とし

• JVMヒープ・GC設定が初期値のまま放置されている

• コンパクション戦略がワークロードに合っていない

• レプリケーション係数（RF）と整合性レベル（CL）の組み合わせを意識せず可用性が下がっている

• ノード追加・除去時のデータ移動量を見積もっていない

これらは公式ドキュメントやDataStaxのアーキテクトガイドなど実運用ベースの一次情報を参照しながら、テスト環境で必ず再現確認しておくことを推奨します。

Cassandra習得ロードマップ

結論として、Cassandraの学習は「データモデルの考え方→クラスタ運用→チューニング」の3段階で進めるのが効率的です。RDB経験者ほど発想の転換が必要になる点を意識してください。

ステップ1：データモデルの考え方を切り替える

最初に詰まる人が多いのが、RDBの正規化発想からの転換です。クエリ駆動でテーブルを増やす感覚をつかむため、書籍やDataStaxの無料教材で簡単な事例を写経することから始めるのが近道です。

ステップ2：ローカルクラスタでクラスタ運用を体験する

Dockerで3〜5ノードのテストクラスタを立ち上げ、ノード追加・削除、整合性レベルの違い、レプリケーションの挙動を手で確認します。マネージドサービス経由でしか触ったことがない人は、ここで運用上の勘所がつかみやすくなります。

ステップ3：チューニングと監視

JVM設定、コンパクション、tombstone対策、ノードあたりのデータ量目安など、運用フェーズで効くチューニングポイントを把握します。Prometheus／GrafanaやDatadogなどの監視基盤と組み合わせて、メトリクスの読み方を整理しておくと、現場で即戦力扱いされやすくなります。

まとめ

Cassandraは「書き込みを止めずに線形にスケールする分散NoSQL」と一言で言い切れるデータベースです。RDBで足りる規模に無理に入れるDBではありませんが、テラバイト級以上のデータと大量書き込みが前提の現場では、強力な選択肢になります。

要点を整理すると以下のようになります。

• データモデルはクエリ駆動設計が原則で、RDBの正規化発想から切り替える必要がある

• CAP定理上はAP寄りだが、整合性レベルで強整合寄りにもチューニング可能

• Redisはキャッシュ層、MongoDBはドキュメント型、RDBはトランザクション中心と、それぞれ住み分けがある

• フリーランス案件では大規模Web・データ基盤・IoT領域で散発的に募集があり、月額60〜140万円前後の単価帯が公開案件で見られる

• 採用前はデータ量・書き込み頻度・整合性要件・運用体制の4軸で必要性を判定する

• tombstone・ホットパーティション・JVMチューニングなど、運用上のつまずきポイントは事前に押さえておく

技術選定で迷ったときは、まずRDBで足りるかどうかを最初に検証し、そのうえで「結果整合で許容できるか」「書き込み点が分散する設計か」を確認してから、Cassandraを含むNoSQLの導入を検討してください。フリコンで確認できる公開案件でも、時期によって波はあるものの、データ基盤エンジニア・分散NoSQL経験者の募集が見られます。スキルセットの幅を整えたうえで、案件選定に役立てていただければと思います。