Why It Fits
選ぶ理由
- 書き込みに非常に強い
- マスターレスで高可用・無停止スケール
- 地理分散に対応
Product Profile
Apache(元 Facebook) / 2008年登場
複数ノードに分散して大量の書き込みを捌くワイドカラム型 NoSQL。マスターレスで単一障害点がなく、線形にスケールする。
Specifications
Introducing
Decision Guide
採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。
Why It Fits
Trade-offs
Deep Dive
Apache Cassandra は、2008 年に Facebook で開発され、その後 Apache プロジェクトとして公開されたワイドカラム型の NoSQL データベースです。ライセンスは Apache License 2.0 です。
「結局なに?」を一言でいえば、書き込みに非常に強く、サーバーを足すほど素直に性能が伸びる分散データベースです。大量データを多数のノードに分散して保持することを前提に設計されています。
データモデルはキーごとに列の集まりを持つワイドカラム型で、行によって列の構成が異なっても扱えます。
最大の特徴はマスターレス構成です。すべてのノードが対等で、特定の親ノードに依存しません。
整合性は、書き込みと読み込みでそれぞれ「何台の応答を待つか」を指定でき、基本は結果整合性(時間が経つと揃う)として運用されます。
得意なのは、絶え間ない大量書き込みと、止まらないことが求められる用途です。一方で、結合(JOIN)や事前に想定していないアドホックなクエリは苦手です。
Cassandra ではまず「どう問い合わせるか」を決め、それに合わせてテーブルを設計します。後から自由な条件で検索しようとすると、うまく機能しないことがあります。
複雑な結合や柔軟な集計が中心なら RDB が向きます。逆に、IoT のセンサーデータ、アクセスログ、時系列データのように「書き込みが膨大で、読み方は決まっている」ケースで Cassandra が活きます。
可用性とスケールを最優先し、クエリパターンを設計段階で固定できるなら、有力な選択肢になります。
Implementation View
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
大量書き込み(IoT / ログ / 時系列)
種別: ワイドカラム / クエリ: CQL / ライセンス: オープンソース(Apache 2.0)
マスターレスで高可用・無停止スケール
結合 / アドホッククエリが苦手
Best Fit