Cassandra: すぐに使える拡張性の高いデータベース

Cassandra は、分散型、非集中型、スケーラブルで可用性の高いワイドカラム データベースです。

CAP 定理の観点から言えば、Cassandra は AP (可用性とパーティション耐性) を表します。

これは、Cassandra が、すべてのノードが利用できない場合でもすべてのクライアントがデータを見つけられることを優先し、部分的なネットワーク障害が発生した場合でも期待どおりに動作することを意味します。ただし、これは、可用性とパーティション耐性を優先してデータの一貫性が損なわれる可能性があることも意味します。ユーザーにはデータが表示されますが、しばらくの間は古いままになる可能性があります。

Cassandra は、高スループットとより高速な書き込み操作を実現するように設計されています。

そして、Cassandra の高可用性を可能にする一貫性がまさに犠牲になっています。

Cassandra は NoSQL データベースであるため、テーブル結合、外部キー、またはクエリ中に WHERE 句に主キー以外の列を追加する機能をサポートしていません。 Cassandra の使用を選択する前に、これらの制限を考慮する必要があります。

カサンドラ ビルディングブロック

• 列: 列はキーと値のペアを表し、データ構造の基本単位として機能します。
• Row : 主キーによって参照される列のコンテナとして機能します。
• Keyspace : 1 つ以上の Cassandra ノードにまたがるテーブルのコンテナとして機能します。
• クラスター: Cassandra 内のキースペースのコンテナー。
• ノード: Cassandra のインスタンスを実行するコンピューター システムを指します。ノードは、物理ホスト、クラウド内のマシン インスタンス、さらには Docker コンテナにすることもできます。

Cassandra がデータを保存する方法

Cassandra はデータを列ファミリーとして保存します。これは、主キーによって参照される列のコンテナとして機能します。

列ファミリーの行には、キーと値を持つ複数の列が含まれており、行キーは主キーとして機能します。

列ファミリーには、行キーごとに異なる列のセットを格納できます。

Cassandra の主キーは何ですか?

主キーはテーブルの各行を一意に識別します。 Cassandra では、主キーには 2 つの部分があります。

Cassandra では、パーティション キーによってどのノードにデータが保存されるかが決まり、クラスタリング キーによってデータがノード内にどのように保存されるかが決まります。たとえば、次のテーブルがあるとします。

PRIMARY KEY (city_id, event_id) 。この主キーは 2 つの部分で構成され、2 つの列で表されます。

1. city_idパーティション キーとして機能します。つまり、データはcity_idフィールドに基づいてパーティション化され、その結果、同じcity_idを持つすべての行が同じノードに格納されます。

event_idクラスタリング キーとして機能します。各ノード内で、データは、 event_id列に基づいて並べ替えられた順序で編成され、保存されます。

パーティション キー = "Paris" を持つすべての行は、event_id 列の値順に同じノードに保存されます。

すぐに使用できるデータのパーティショニング

Cassandra は、 Consistent Hashingに基づいたデータのパーティショニングを提供し、データベースに保存されるデータの量が大きくなった場合に、読み取り/書き込み操作の待ち時間を短縮し、システムのスループットを向上させます。

Cassandra のパーティショナーは、Consistent Hash リング全体にデータを分散する方法を決定する責任があります。データが Cassandra クラスターに挿入されると、パーティショナーはハッシュ アルゴリズムをパーティション キーに適用します。このハッシュ アルゴリズムの結果によって、データが含まれる範囲が決まり、データが保存されるノードが決まります。

コーディネーターノード

Cassandra では、各ノードはゴシップ プロトコルを通じて他のノードのトークン割り当てを認識し、どのノードでも他のノードの範囲に対するリクエストを処理できるようになります。したがって、クライアントは任意のノードに接続して、読み取りまたは書き込みクエリを開始できます。

リクエストを受信するノードはコーディネーターと呼ばれ、クラスター内の任意のノードにすることができます。キーがコーディネーターの範囲に属さない場合、リクエストはその範囲を担当するレプリカに転送されます。

レプリケーション

Cassandra は、複数のノード間でデータをレプリケートし、高可用性を確保します。 Cassandra の各ノードは、特定のデータ範囲のレプリカとして機能します。 Cassandra は、データの複数のコピーを異なるレプリカに分散することで、1 つのノードが使用不可になった場合に他のレプリカがそのデータ範囲のクエリを処理できるようにします。次の 2 つの設定がレプリケーション プロセスに影響します。

レプリケーション係数によって、同じデータのコピーを保存するノードの数が決まります。レプリケーション係数が 3 のクラスターでは、各行は 3 つの異なるノードに保存されます。

Cassandra では、最初のレプリカは、パーティション キーのハッシュに基づいて範囲を所有するノードに割り当てられます。残りのレプリカは、時計回りに連続するノードに配置されます。 Cassandra は 2 つのレプリケーション戦略を使用して、どのノードがレプリカを担当するかを決定します。

シンプルなレプリケーション戦略

この戦略では、最初のレプリカはパーティショナーによって決定されたノードに配置され、後続のレプリカは時計回りに後続のノードに配置されます。

ネットワークトポロジ戦略

データの完全な損失に対する復元力を確保するために、同じデータ センター内の追加のレプリカは、別のデータ センターの最初のノードに到達するまでリングに沿って時計回りに移動して配置されます。この配置は、電源、冷却、またはネットワークの問題により通常同じデータ センター内で発生する同時障害の影響を軽減するのに役立ちます。

カサンドラをいつ使用するか

Cassandra は、大量のデータを処理する必要があり、一貫性よりもデータの可用性を優先するアプリケーションに優れています。以下のような用途に適しています。

1.モノのインターネット (IoT) アプリケーション: Cassandra は、デバイスやセンサーによって生成された大量のデータを処理できるため、IoT 環境にとって理想的な選択肢です。分散アーキテクチャにより、地理的に分散した大規模データの管理が可能になります。

2.時系列データ: メトリクス、監視システム、テレメトリ データなどの時系列データを扱うアプリケーションは、Cassandra の効率的な書き込み操作と水平方向のスケーラビリティの恩恵を受けます。これらの機能は、大量のタイムスタンプ付きデータを保存および管理するために重要です。

3. Web およびモバイル アプリケーション: Cassandra は、高スループットおよび低遅延のデータ アクセスを提供するため、大量のデータを生成する大規模なユーザー ベースを持つ Web およびモバイル プラットフォームに適しています。これには、ソーシャル メディア プラットフォーム、ゲーム アプリ、電子商取引サイトが含まれます。

4.リアルタイムのビッグ データ分析: Cassandra はビッグ データのリアルタイム処理をサポートしており、大規模なデータセットから即時の洞察を必要とするアプリケーションにとって貴重な選択肢となります。例には、推奨エンジンや不正検出システムが含まれます。

5.分散データ ウェアハウス: 大規模な分散データセットを持つ企業は、Cassandra をデータ ウェアハウス ソリューションとして活用できます。複数のデータセンター間でデータを複製する機能により、高可用性と災害復旧が保証されます。

6.メッセージング システム: Cassandra は書き込みおよび読み取りスループットが高いため、イベント ログ、監査証跡、メッセージ キューなど、大量のデータを処理するメッセージング システムに最適です。

7.パーソナライゼーションおよびコンテンツ管理システム: コンテンツ管理システムなど、大規模なパーソナライズされたコンテンツ配信を必要とするアプリケーションは、カスタマイズされたコンテンツを多数のユーザーに同時に配信する際の Cassandra の速度と拡張性の恩恵を受けます。

8.地理的に分散されたアプリケーション: Cassandra は複数のデータセンターをサポートしているため、地理的に分散されたデータを必要とするアプリケーションにとって優れた選択肢となります。これにより、異なるリージョン間で低遅延のデータ アクセスが保証され、高い復元力が提供されます。

カサンドラを使用してはいけない場合

Apache Cassandra は強力でスケーラブルですが、すべてのアプリケーションやユースケースに適しているわけではありません。これは、トランザクションの多いアプリケーション、複雑なクエリ、および強い整合性や迅速なスキーマ変更を必要とするシナリオにはあまり適していません。このような場合には、従来のリレーショナル データベース管理システム (RDBMS) またはその他の NoSQL ソリューションの方が適している可能性があります。 Cassandra が最適な選択ではない可能性があるいくつかのシナリオを次に示します。

1. 小規模プロジェクト: Cassandra の複雑さとリソース要件は、データセットが限られた小規模プロジェクトやアプリケーションでは過度になる可能性があります。よりシンプルなデータベース ソリューションは、よりコスト効率が高く、管理しやすい代替手段となる可能性があります。

   
   

2. ACID プロパティを必要とするトランザクション システム: Cassandra は、ACID (原子性、一貫性、分離性、耐久性) プロパティを完全にはサポートしていません。アプリケーションで銀行や金融システムによく見られる複雑なトランザクションが必要な場合は、従来の RDBMS の方が適している可能性があります。

   
   

3. 大量のクエリと集計を結合する: アプリケーションが結合、サブクエリ、または複雑な集計に大きく依存している場合、Cassandra は最適な選択肢ではない可能性があります。高速な書き込みと読み取りを目的として設計されていますが、複雑なクエリ処理を目的として設計されていません。

   
   

4. 強い整合性要件を持つデータ: Cassandra は結果整合性を提供しますが、すべての読み取りおよび書き込み操作に強い一貫性が必要なユースケースには適さない可能性があります。

   
   

5. 単一クラスターでの低遅延の読み取りおよび書き込み: Cassandra はマルチノードの分散環境では良好にパフォーマンスしますが、低遅延の読み取りおよび書き込みが必要な単一ノードまたは小規模クラスターの展開には最適な選択肢ではない可能性があります。

   
   

6. Blob Storage : Cassandra は、画像やビデオなどの大きなバイナリ オブジェクト (BLOB) を保存するように最適化されていません。他のストレージ ソリューションは、大きな BLOB を効率的に処理するのに適しています。

   
   

7. アドホック クエリを必要とするアプリケーション: Cassandra のクエリ機能は、本格的な SQL データベースと比較して制限されています。アドホックなクエリとレポートに大きく依存するアプリケーションにはあまり適していません。

   Cassandra では、テーブルの設計はデータへのアクセス方法と密接に関係しており、データ エンティティ間の関係のみに焦点を当てるのではなく、クエリ パターンに重点を置いています。これは、スキーマ設計が正規化原則に基づいている RDBMS のアプローチとは異なります。

   
   

8. 急速なスキーマの進化: アプリケーションでデータベース スキーマを頻繁に変更する必要がある場合、Cassandra のスキーマ管理は従来の RDBMS システムや他の NoSQL ソリューションに比べて柔軟性が劣る可能性があります。

   
   

9. 複雑なクエリ、結合、および履歴データ分析を含むデータ ウェアハウス アプリケーション: Cassandra は書き込み負荷の高いワークロードやリアルタイム データ アクセスには適していますが、複雑なクエリを必要とするデータ ウェアハウス シナリオには最適な選択肢ではない可能性があります。結合、および履歴データ分析。

まとめ

この記事では、拡張性の高い分散型ワイドカラム データベースである Cassandra の概要を説明します。 Cassandra は、可用性とパーティション耐性を優先するように設計されており、一貫性が重要な要件ではないアプリケーションに適しています。高スループットと高速な書き込み操作をサポートします。

Cassandra の構成要素には、列、行、キースペース、クラスター、ノードが含まれます。列はキーと値のペアを表し、行は主キーによって参照される列のコンテナとして機能し、キースペースは複数のノードにまたがるテーブルのコンテナとして機能し、クラスタにはキースペースが含まれ、ノードは Cassandra インスタンスを実行しているコンピュータ システムを指します。

Cassandra は、主キーによって参照される列のコンテナーである列ファミリーにデータを格納します。データのパーティショニングは一貫したハッシュによって実現され、レイテンシの削減とスループットの向上が可能になります。パーティショナーは Consistent Hash リング全体にデータを分散し、コーディネーター ノードが読み取りおよび書き込みクエリを処理します。

Cassandra は高可用性のためのレプリケーションを提供します。データのレプリカは複数のノードに保存され、ノードが使用できなくなった場合でもクエリをレプリカで処理できるようにします。レプリケーションの要素と戦略によって、レプリカの数とそれらを担当するノードが決まります。

Cassandra にはスケーラビリティや高可用性などの利点がありますが、制限もあります。テーブル結合、外部キー、またはクエリ中に WHERE 句に主キー以外の列を追加する機能はサポートされていません。

全体として、Cassandra は、拡張性の高いアプリケーション、特に強整合性よりも可用性とパーティション耐性を優先するアプリケーション向けの強力なデータベース ソリューションです。

乾杯！