製品プロフィール

Apache Cassandra

Apache(元 Facebook) / 2008年登場

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

3つの要点
TL;DR
  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 / ログ / 時系列)高可用・地理分散大規模スケール
公式サイト