製品プロフィール

Apache Cassandra

Apache(元 Facebook) / 2008年登場

複数ノードに分散して大量の書き込みを捌くワイドカラム型 NoSQL。マスターレスで単一障害点がなく、線形にスケールする。

3つの要点
  1. 大量書き込みを分散で捌くワイドカラム型 NoSQL。
  2. マスターレスで単一障害点がなく線形にスケール。
  3. IoT やログの大量書き込みに。結合主体なら不向き。

基本情報

仕様と立ち位置

Apache Cassandra のロゴ
製品・技術の概要Apache Cassandra複数ノードに分散して大量の書き込みを捌くワイドカラム型 NoSQL。マスターレスで単一障害点がなく、線形にスケールする。
種別
ワイドカラム
クエリ
CQL
ライセンス
オープンソースApache 2.0)
登場
2008年
最大の強み
書き込みに非常に強いマスターレスで高可用・無停止スケール
代表的な用途
大量書き込みIoT / ログ / 時系列)高可用・地理分散 / 大規模スケール

選定ガイド

選定ポイント

採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。

採用に向く条件

選ぶ理由

  1. 書き込みに非常に強い
  2. マスターレスで高可用・無停止スケール
  3. 地理分散に対応

事前に確認する条件

考慮すべき点

  1. 結合 / アドホッククエリが苦手
  2. クエリ前提のテーブル設計が必要
  3. 基本は結果整合性

詳しい解説

もっと詳しく

どんな DB か

Apache Cassandra は、2008 年に Facebook で開発され、その後 Apache プロジェクトとして公開されたワイドカラム型の NoSQL データベースです。ライセンスは Apache License 2.0 です。

「結局なに?」を一言でいえば、書き込みに非常に強く、サーバーを足すほど素直に性能が伸びる分散データベースです。大量データを多数のノードに分散して保持することを前提に設計されています。

横にスクロール

Cassandraのコーディネーターがパーティションキーから複製先を選び、各レプリカのcommit logとmemtableへ書込み、整合性レベル分の応答後に成功を返し、読取り時は複数値を照合・修復する流れ
Cassandraでは任意ノードがコーディネーターとなり、パーティションキーのトークンと複製戦略からレプリカを選びます。各レプリカはcommit logとmemtableへ書いた後にACKし、指定した整合性レベルの台数で成功を返します。読取りは複数レプリカを照合し、hinted handoff、read repair、定期repairで複製差を収束させます。

データモデル・仕組み

データモデルはキーごとに列の集まりを持つワイドカラム型で、行によって列の構成が異なっても扱えます。

最大の特徴はマスターレス構成です。すべてのノードが対等で、特定の親ノードに依存しません。

  • 単一障害点がなく、一部のノードが落ちても動き続けます。
  • ノードを追加すると、ほぼ線形にスループットが伸びます。
  • 複数データセンターへの地理分散(レプリケーション)に対応します。

整合性は、書き込みと読み込みでそれぞれ「何台の応答を待つか」を指定でき、基本は結果整合性(時間が経つと揃う)として運用されます。

得意・不得意

得意なのは、絶え間ない大量書き込みと、止まらないことが求められる用途です。一方で、結合(JOIN)や事前に想定していないアドホックなクエリは苦手です。

Cassandra ではまず「どう問い合わせるか」を決め、それに合わせてテーブルを設計します。後から自由な条件で検索しようとすると、うまく機能しないことがあります。

いつ選ぶか(RDB との違い)

複雑な結合や柔軟な集計が中心なら RDB が向きます。逆に、IoT のセンサーデータ、アクセスログ、時系列データのように「書き込みが膨大で、読み方は決まっている」ケースで Cassandra が活きます。

可用性とスケールを最優先し、クエリパターンを設計段階で固定できるなら、有力な選択肢になります。

実装・運用の視点

Apache Cassandraを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

大量書き込み(IoT / ログ / 時系列)

比較で見る軸

種別: ワイドカラム / クエリ: CQL / ライセンス: オープンソース(Apache 2.0)

導入後に効く点

マスターレスで高可用・無停止スケール

先に潰すリスク

結合 / アドホッククエリが苦手

数字・仕様の読み方
種別
ワイドカラム
クエリ
CQL
ライセンス
オープンソース(Apache 2.0)
登場
2008年

判断チェックリスト

  • 自社の用途が「大量書き込み(IoT / ログ / 時系列) / 高可用・地理分散」に近いか確認する。
  • 強みである「書き込みに非常に強い」が本当に評価軸になるか確認する。
  • 注意点の「結合 / アドホッククエリが苦手」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

大量書き込み(IoT / ログ / 時系列)高可用・地理分散大規模スケール

向いている用途

こんな用途に向く

大量書き込み(IoT / ログ / 時系列)高可用・地理分散大規模スケール
公式サイト