Cassandra は、分散型、非集中型、スケーラブルで可用性の高いワイドカラム データベースです。 CAP 定理の観点から言えば、Cassandra は AP (可用性とパーティション耐性) を表します。 これは、Cassandra が、すべてのノードが利用できない場合でもすべてのクライアントがデータを見つけられることを優先し、部分的なネットワーク障害が発生した場合でも期待どおりに動作することを意味します。ただし、これは、可用性とパーティション耐性を優先してデータの一貫性が損なわれる可能性があることも意味します。ユーザーにはデータが表示されますが、しばらくの間は古いままになる可能性があります。 Cassandra は、高スループットとより高速な書き込み操作を実現するように設計されています。 そして、Cassandra の高可用性を可能にする一貫性がまさに犠牲になっています。 デフォルトでは、Cassandra は結果整合性を保つように設計されており、強い整合性を提供できない可能性があります。このため、Cassandra は、一貫性が重要な要件ではないアプリケーションに適しています。ただし、パフォーマンスに影響を与える可能性がありますが、強力な一貫性を提供するように Cassandra を構成することは可能です。 Cassandra は NoSQL データベースであるため、テーブル結合、外部キー、またはクエリ中に WHERE 句に主キー以外の列を追加する機能をサポートしていません。 Cassandra の使用を選択する前に、これらの制限を考慮する必要があります。 カサンドラ ビルディングブロック : 列はキーと値のペアを表し、データ構造の基本単位として機能します。 列 : 主キーによって参照される列のコンテナとして機能します。 Row : 1 つ以上の Cassandra ノードにまたがるテーブルのコンテナとして機能します。 Keyspace : Cassandra 内のキースペースのコンテナー。 クラスター : Cassandra のインスタンスを実行するコンピューター システムを指します。ノードは、物理ホスト、クラウド内のマシン インスタンス、さらには Docker コンテナにすることもできます。 ノード Cassandra がデータを保存する方法 Cassandra はデータを列ファミリーとして保存します。これは、主キーによって参照される列のコンテナとして機能します。 列ファミリーの行には、キーと値を持つ複数の列が含まれており、行キーは主キーとして機能します。 列ファミリーには、行キーごとに異なる列のセットを格納できます。 Cassandra は null 値を持つ列を保存しないため、ストレージ領域を大幅に節約できます。 Cassandra の主キーは何ですか? テーブルの各行を一意に識別します。 Cassandra では、主キーには 2 つの部分があります。 主キーは Cassandra では、パーティション キーによってどのノードにデータが保存されるかが決まり、クラスタリング キーによってデータがノード内にどのように保存されるかが決まります。たとえば、次のテーブルがあるとします。 。この主キーは 2 つの部分で構成され、2 つの列で表されます。 PRIMARY KEY (city_id, event_id) 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 では、最初のレプリカは、パーティション キーのハッシュに基づいて範囲を所有するノードに割り当てられます。残りのレプリカは、時計回りに連続するノードに配置されます。 Cassandra は 2 つのレプリケーション戦略を使用して、どのノードがレプリカを担当するかを決定します。 シンプルなレプリケーション戦略 この戦略では、最初のレプリカはパーティショナーによって決定されたノードに配置され、後続のレプリカは時計回りに後続のノードに配置されます。 このレプリケーション戦略は、単一のデータセンター クラスターにのみ適用されます。 ネットワークトポロジ戦略 データの完全な損失に対する復元力を確保するために、同じデータ センター内の追加のレプリカは、別のデータ センターの最初のノードに到達するまでリングに沿って時計回りに移動して配置されます。この配置は、電源、冷却、またはネットワークの問題により通常同じデータ センター内で発生する同時障害の影響を軽減するのに役立ちます。 マルチデータセンター構成の場合は、ネットワーク トポロジ戦略を考慮する必要があります。このアプローチにより、データセンターごとにさまざまなレプリケーション係数を指定できるようになり、特定の場所ごとに配置されるレプリカの数を制御できるようになります。 カサンドラをいつ使用するか Cassandra は、大量のデータを処理する必要があり、一貫性よりもデータの可用性を優先するアプリケーションに優れています。 。 以下のような用途に適しています 1. : Cassandra は、デバイスやセンサーによって生成された大量のデータを処理できるため、IoT 環境にとって理想的な選択肢です。分散アーキテクチャにより、地理的に分散した大規模データの管理が可能になります。 モノのインターネット (IoT) アプリケーション 2. : メトリクス、監視システム、テレメトリ データなどの時系列データを扱うアプリケーションは、Cassandra の効率的な書き込み操作と水平方向のスケーラビリティの恩恵を受けます。これらの機能は、大量のタイムスタンプ付きデータを保存および管理するために重要です。 時系列データ 3. : Cassandra は、高スループットおよび低遅延のデータ アクセスを提供するため、大量のデータを生成する大規模なユーザー ベースを持つ Web およびモバイル プラットフォームに適しています。これには、ソーシャル メディア プラットフォーム、ゲーム アプリ、電子商取引サイトが含まれます。 Web およびモバイル アプリケーション 4. : Cassandra はビッグ データのリアルタイム処理をサポートしており、大規模なデータセットから即時の洞察を必要とするアプリケーションにとって貴重な選択肢となります。例には、推奨エンジンや不正検出システムが含まれます。 リアルタイムのビッグ データ分析 5. : 大規模な分散データセットを持つ企業は、Cassandra をデータ ウェアハウス ソリューションとして活用できます。複数のデータセンター間でデータを複製する機能により、高可用性と災害復旧が保証されます。 分散データ ウェアハウス 6. : Cassandra は書き込みおよび読み取りスループットが高いため、イベント ログ、監査証跡、メッセージ キューなど、大量のデータを処理するメッセージング システムに最適です。 メッセージング システム 7. : コンテンツ管理システムなど、大規模なパーソナライズされたコンテンツ配信を必要とするアプリケーションは、カスタマイズされたコンテンツを多数のユーザーに同時に配信する際の Cassandra の速度と拡張性の恩恵を受けます。 パーソナライゼーションおよびコンテンツ管理システム 8. : Cassandra は複数のデータセンターをサポートしているため、地理的に分散されたデータを必要とするアプリケーションにとって優れた選択肢となります。これにより、異なるリージョン間で低遅延のデータ アクセスが保証され、高い復元力が提供されます。 地理的に分散されたアプリケーション カサンドラを使用してはいけない場合 Apache Cassandra は強力でスケーラブルですが、すべてのアプリケーションやユースケースに適しているわけではありません。これは、トランザクションの多いアプリケーション、複雑なクエリ、および強い整合性や迅速なスキーマ変更を必要とするシナリオにはあまり適していません。このような場合には、従来のリレーショナル データベース管理システム (RDBMS) またはその他の NoSQL ソリューションの方が適している可能性があります。 Cassandra が 可能性があるいくつかのシナリオを次に示します。 最適な選択ではない : Cassandra の複雑さとリソース要件は、データセットが限られた小規模プロジェクトやアプリケーションでは過度になる可能性があります。よりシンプルなデータベース ソリューションは、よりコスト効率が高く、管理しやすい代替手段となる可能性があります。 小規模プロジェクト : Cassandra は、ACID (原子性、一貫性、分離性、耐久性) プロパティを完全にはサポートしていません。アプリケーションで銀行や金融システムによく見られる複雑なトランザクションが必要な場合は、従来の RDBMS の方が適している可能性があります。 ACID プロパティを必要とするトランザクション システム : アプリケーションが結合、サブクエリ、または複雑な集計に大きく依存している場合、Cassandra は最適な選択肢ではない可能性があります。高速な書き込みと読み取りを目的として設計されていますが、複雑なクエリ処理を目的として設計されていません。 大量のクエリと集計を結合する : Cassandra は結果整合性を提供しますが、すべての読み取りおよび書き込み操作に強い一貫性が必要なユースケースには適さない可能性があります。 強い整合性要件を持つデータ : Cassandra はマルチノードの分散環境では良好にパフォーマンスしますが、低遅延の読み取りおよび書き込みが必要な単一ノードまたは小規模クラスターの展開には最適な選択肢ではない可能性があります。 単一クラスターでの低遅延の読み取りおよび書き込み : Cassandra は、画像やビデオなどの大きなバイナリ オブジェクト (BLOB) を保存するように最適化されていません。他のストレージ ソリューションは、大きな BLOB を効率的に処理するのに適しています。 Blob Storage : Cassandra のクエリ機能は、本格的な SQL データベースと比較して制限されています。アドホックなクエリとレポートに大きく依存するアプリケーションにはあまり適していません。 アドホック クエリを必要とするアプリケーション Cassandra では、テーブルの設計はデータへのアクセス方法と密接に関係しており、データ エンティティ間の関係のみに焦点を当てるのではなく、クエリ パターンに重点を置いています。これは、スキーマ設計が正規化原則に基づいている RDBMS のアプローチとは異なります。 : アプリケーションでデータベース スキーマを頻繁に変更する必要がある場合、Cassandra のスキーマ管理は従来の RDBMS システムや他の NoSQL ソリューションに比べて柔軟性が劣る可能性があります。 急速なスキーマの進化 : Cassandra は書き込み負荷の高いワークロードやリアルタイム データ アクセスには適していますが、複雑なクエリを必要とするデータ ウェアハウス シナリオには最適な選択肢ではない可能性があります。結合、および履歴データ分析。 複雑なクエリ、結合、および履歴データ分析を含むデータ ウェアハウス アプリケーション まとめ この記事では、拡張性の高い分散型ワイドカラム データベースである Cassandra の概要を説明します。 Cassandra は、可用性とパーティション耐性を優先するように設計されており、一貫性が重要な要件ではないアプリケーションに適しています。高スループットと高速な書き込み操作をサポートします。 Cassandra の構成要素には、列、行、キースペース、クラスター、ノードが含まれます。列はキーと値のペアを表し、行は主キーによって参照される列のコンテナとして機能し、キースペースは複数のノードにまたがるテーブルのコンテナとして機能し、クラスタにはキースペースが含まれ、ノードは Cassandra インスタンスを実行しているコンピュータ システムを指します。 Cassandra は、主キーによって参照される列のコンテナーである列ファミリーにデータを格納します。データのパーティショニングは一貫したハッシュによって実現され、レイテンシの削減とスループットの向上が可能になります。パーティショナーは Consistent Hash リング全体にデータを分散し、コーディネーター ノードが読み取りおよび書き込みクエリを処理します。 Cassandra は高可用性のためのレプリケーションを提供します。データのレプリカは複数のノードに保存され、ノードが使用できなくなった場合でもクエリをレプリカで処理できるようにします。レプリケーションの要素と戦略によって、レプリカの数とそれらを担当するノードが決まります。 Cassandra にはスケーラビリティや高可用性などの利点がありますが、制限もあります。テーブル結合、外部キー、またはクエリ中に WHERE 句に主キー以外の列を追加する機能はサポートされていません。 全体として、Cassandra は、拡張性の高いアプリケーション、特に強整合性よりも可用性とパーティション耐性を優先するアプリケーション向けの強力なデータベース ソリューションです。 Cassandra には興味深い側面がいくつかありますが、それについては次の記事で説明します。見逃さないよう ！ に購読してください 乾杯！
