分散型データベース管理システム(DBMS)として設計されたCassandraは、ピア・ツー・ピア・アーキテクチャーに基づいています。Cassandraクラスター内のすべてのノード、つまりデータの一部を保持する個々のサーバーは平等であり、マスター・ノードに依存しません。
データは集中管理された場所に保存されるのではなく、ピア間で分割されるため、1つの障害が連鎖的に多重障害へと発展する単一障害点を排除します。この設計により、シームレスな複製、効率的なデータ分散、計画停止や突発的な変更時においても継続的なサービス提供が可能になります。
Cassandraは自動化、データバックアップ、統合メトリクスを提供し、接続されたモノのインターネット(IoT)デバイスの管理などのユースケースに活用できます。さらに、追加した分だけ性能が向上する直線的な拡張性、高可用性、フォールトトレランスを実現し、ビッグデータ・アプリケーションやリアルタイムのワークロードに適した選択肢となっています。2024年9月時点で、Cassandraは世界中の30,000を超える組織で利用されていました。
IBMニュースレター
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
ニュースレターは日本語で配信されます。すべてのニュースレターに登録解除リンクがあります。サブスクリプションの管理や解除はこちらから。詳しくはIBMプライバシー・ステートメントをご覧ください。
Cassandraのストーリーは2007年、Facebookにおいて同社の拡大するメッセージング・プラットフォーム向けにデータを保存できるシステムを求めたエンジニアたちによって始まりました。Amazon社のDynamoやGoogle社のBigtableといった既存のNoSQLデータベースモデルを組み合わせることで、効率的なデータ構造と「結果整合性」(更新が伝播し、最終的にすべてのレプリカが一致する仕組み)を備えたシステムを構築しました。
2008年、Cassandraはオープンソース・プロジェクトとして公開され、従来のリレーショナル・データベースに代わる選択肢を求める開発者の間で急速に注目を集めました。2009年にはApache Software Foundationが運営責任を引き継ぎ、そのガバナンスを正式化し、コミュニティーでの採用を加速させました。
eBay、Spotify、Instagramといったアーリー・アダプターがビッグデータ処理のためにCassandraを導入したことで、その勢いはさらに増しました。IoTの台頭やリアルタイムのパーソナライゼーションが進む中で、Cassandraはスケールと可用性を重視するデータベースとしての地位を確立しました。
DataStaxによる商用サポートは、エンタープライズ・グレードのツール、チュートリアル、サービスを追加し、一方でオープン・コミュニティーはツールを開発し、ドキュメントを拡充しました。現在、Cassandraは多くの分散システムの中心的存在であり、オープンソース・エコシステムと企業導入の両方で活発に利用されています。
ストリーミング・サービスやソーシャルメディア、オンラインショッピングに至るまで、顧客は常時稼働のデジタル体験を期待しています。企業にとって、稼働時間はもはやITの目標ではなくビジネス指標です。その期待を裏切る代償は大きく、世界の主要企業は計画外のダウンタイムによって年間推定4,000億米ドルを失っています。
同時に、イベントログ、テレメトリー、データ・ストリームから発生する非構造化データの急増により、リージョンやクラウド環境全体での運用はより複雑になり、システム障害の可能性が高まっています。組織には、多様なデータタイプを処理し、グローバルなインフラストラクチャー全体で需要に応じてスケールできる信頼性の高いデータベースが必要です。Cassandraはこれらの要求を満たすように設計されています。
各業界はCassandraの高性能を活用し、数十億件規模の書き込み処理(挿入、更新、削除)をリアルタイムの正確性を維持しながら実行しています。そのレジリエンスは、汎用サーバー(市販の標準マシン)間でデータを複製する仕組みによって実現され、障害のリスクを最小化し、ハードウェア障害が発生してもデータの永続性を確保します。
Cassandraは複数のデータセンターにわたるワークロードを管理できるため、世界中の企業に整合性と可用性を提供します。Netflix社やAmazon社のような企業は、ダウンタイムやデータ損失から守りつつ、パーソナライズされた体験を提供するためにCassandraを活用しています。実際、Netflix社のアセット管理プラットフォーム・チームは、Cassandraを用いて約19億件のアノテーション(約2.6TB)を管理しており、クラスターを12ノードから24ノードに倍増させています。
従来のリレーショナル・データベースは、厳格なスキーマ定義と集中制御に依存しています。リレーショナル・システムでは、プライマリー・キーは厳密なデータ・モデリングと限定的な拡張性に結び付けられています。これに対しCassandraは、パーティション・キーと複製係数を用いて、データセットをノードやデータセンター間にどのように分散して保存するかを決定します。
SQL(構造化問合せ言語)システムは複雑な結合や集計に優れていますが、ボトルネックや単一障害点のリスクを抱えることが多いのが現実です。Cassandraは分散アーキテクチャーと結果整合性を採用することで、これらの問題を回避します。MongoDBと比較すると、Cassandraデータベースは書き込み中心で、複数データセンターにわたり直線的に拡張可能なワークロードに適しています。
大量のデータを管理する組織には、Cassandraは高スループット、低レイテンシー、障害耐性といった明確なメリットを提供します。ただし、Cassandraは一部のリレーショナル・データベースが提供するようなアドホック・クエリーの柔軟性を同じレベルで備えているわけではありません。Cassandraを利用する開発者は、書き込み処理、レプリカ、データ完全性を最適化するために、データ・モデリング戦略を慎重に設計する必要があります。
Cassandraは、分散システムにおけるイノベーションと、エンタープライズ・グレードのデータ管理のためのツールを組み合わせています。主な機能には以下が含まれます。
CassandraはApache Software Foundationの下でオープンソースとして提供されており、組織がベンダー・ロックインを回避し、ニーズに合わせてデータベースをカスタマイズできるようにしています。エンタープライズ・グレードのサポートが必要な場合、チームはコミュニティ・リソースを利用するか、商用サポートやマネージド・サービスを選択できます。
Cassandraのストレージ・エンジンは、コミット・ログ、インメモリー・テーブル(memtable)、ソート済み文字列テーブル(SSTable)ファイルからなるステップ・バイ・ステップのフロー(書き込みパス)を使用します。このフローは書き込み処理を素早く受け入れ、それを保護します。頻繁にアクセスされるデータはキャッシュに保持され、低レイテンシーのクエリーを実現します。一方、自動ハウスキーピング機能であるコンパクションによって、長期的なデータ保存の効率性が確保されます。
CAP定理によると、ネットワーク分割が発生した場合、分散システムは整合性、可用性、分割耐性(CAP)の3つの特性のうち2つしか満たすことができません。Cassandraは調整可能な整合性レベルを通じてこのトレードオフに対応し、ユースケースに応じて可用性か整合性のどちらを優先するかを選択できるようにしています。
Cassandraはサービスを中断することなく新しいノードを追加することでキャパシティーを拡張し、高価な垂直方向のアップグレードではなく汎用サーバー上で直線的な拡張性を実現します。ノードが追加されると、Cassandraはデータとトラフィックを自動的にクラスター全体に再分配するため、ワークロードはスケールアウトし、スループットも比例して向上します。
Cassandraはノードやデータセンター間でデータを複製し、ローカル・ユーザーが低レイテンシーを体験できるようにしながら、単一障害点を回避します。また、Kubernetesやアプリケーション・プログラミング・インターフェース(API)フレームワーク、Amazon Web Services(AWS)環境と統合可能です。CassandraはJavaで記述され、Java Virtual Machine(JVM)上で動作します。
チームはSQLに似たCassandra Query Language(CQL)を使用して、キースペース、テーブル、プライマリー・キーなどの主要な構成要素を迅速に定義できます。CQLシェル(cqlsh)や公式チュートリアルのような対話型ツールも、新しい開発者のオンボーディング時間を短縮するのに役立ちます。
Cassandraは、SQLを参考にしたドメイン固有言語であるCQLを通じてアプリケーションとやり取りします。CQLの構文はデータベース開発者に馴染みがあり、キースペース、スキーマ、データ型、プライマリー・キーやパーティション・キーを定義できます。
例えば、グローバルでのゲーム・ローンチ時に、開発者はまずキースペース(Cassandraにおける最上位のデータベースに相当し、複製設定を定義するもの)を作成します。その後、プレイヤーIDや地域といったパーティション・キーを利用して関連データを同一ノード上に保持し、効率的なデータ分散を可能にするテーブルを設計できます。cqlshを使えば、チームはチュートリアルを実行し、クエリーを検証し、プレイヤー数の増加に対応するために新しいノードを追加しながらCassandraクラスターを管理することができます。
Cassandraは書き込み処理とスループットを重視しているため、複雑な結合のようにパフォーマンスを低下させる機能は構文に含まれていません。その代わりに、開発者はセカンダリー・インデックス、集計、最適化されたデータ・モデリングに依存して柔軟性を実現します。
CQLはSQLに似ていますが、両者はデータ管理に対して異なるアプローチを反映しています。
SQLは正規化されたテーブルを操作しますが、CQLはパーティション・キーに基づいて設計された非正規化データを扱うCassandra向けに設計されています。
SQLは厳格なデータ完全性を前提としますが、Cassandraは最終的な整合性を前提とし、調整可能な整合性レベルとのバランスを取ります。
SQLシステムは通常、垂直スケーリングに依存していますが、Cassandraはクラスターに新しいノードを追加することで直線的な拡張性を実現します。
SQLはトランザクション処理に最適化されていますが、CQLはリアルタイム・クエリーや大量の書き込み処理に対応するよう設計されています。
SQLから移行する開発者は、CQLの構文に素早く適応できますが、Cassandraの分散システム・アプローチを活かすためにデータ・モデリング戦略を再考する必要があります。
Cassandraは、高いパフォーマンス、低レイテンシー、レジリエンスを求める業界において、ミッションクリティカルなワークロードを支えています。例えば、以下のような例が挙げられます。
これらの業種を超えて、Cassandraはビッグデータや拡張可能なデータ保存のための分散システムを構築する組織をサポートします。APIサポート、エンタープライズ向けツール群、オープン・コミュニティーによるチュートリアルを組み合わせることで、Cassandraはモダンなデータベース管理システムの基盤であり続けています。
企業が繁栄するには、データを活用して顧客ロイヤルティーを構築し、ビジネス・プロセスを自動化し、AI駆動型のソリューションで業務を刷新する必要があります。
IBMコンサルティングと連携することで、企業データの価値を引き出し、ビジネス上の優位性をもたらす洞察を活用した組織を構築します。
より良い意思決定を可能にする、AIを活用して洞察を引き出すCognos Analytics 12.0をご紹介します。
†Apache CassandraおよびCassandraは、The Apache Software Foundationの登録商標です。