Cassandraの基本

CassandraはNoSQL分散データベースです。NoSQLデータベースは、設計上、軽量で、オープンソース、非リレーショナル、そして大規模に分散されています。その強みとして、水平スケーラビリティ、分散アーキテクチャ、スキーマ定義の柔軟なアプローチが挙げられます。

NoSQLデータベースは、非常に大量で異種なデータタイプを迅速かつアドホックに組織化および分析することを可能にします。ビッグデータの出現とクラウドにおけるデータベースの迅速なスケーリングの必要性が高まっている近年、これはますます重要になっています。Cassandraは、SQLデータベースなどの従来のデータ管理技術の制約に対処してきたNoSQLデータベースの一つです。

Cassandraの重要な属性の一つは、そのデータベースが分散されていることです。これにより、技術的な利点とビジネス上の利点の両方がもたらされます。Cassandraデータベースは、アプリケーションが高負荷状態にある場合でも容易にスケールし、分散化によって特定のデータセンターのハードウェア障害によるデータ損失を防ぎます。分散アーキテクチャは技術的なパワーも提供します。例えば、開発者は読み取りクエリまたは書き込みクエリのスループットを個別に調整できます。

「分散」とは、Cassandraが複数のマシン上で動作しながら、ユーザーには統合された全体として表示されることを意味します。Cassandraを単一ノードで実行することにはほとんど意味がありませんが、動作方法を理解するために単一ノードで実行することは非常に役立ちます。しかし、Cassandraを最大限に活用するには、複数のマシンで実行する必要があります。

分散データベースであるため、Cassandraは（通常は）複数のノードを持つことができます。ノードは、Cassandraの単一インスタンスを表します。これらのノードは、ゴシップと呼ばれるピアツーピア通信のプロセスを通じて互いに通信します。Cassandraはマスターレスアーキテクチャも採用しています。データベース内のどのノードも、他のノードと同じ機能を提供できます。これにより、Cassandraの堅牢性とレジリエンスが向上します。複数のノードは、論理的にクラスタまたは「リング」に編成できます。複数のデータセンターを持つことも可能です。

Cassandraの人気の理由の一つは、開発者がダウンタイムなしで、市販のハードウェアを使用してデータベースを動的にスケールできることです。必要に応じて拡張でき、アプリケーションの要件が示唆する場合は縮小することもできます。

OracleやMySQLデータベースに慣れているかもしれません。その場合、ユーザー数やストレージ容量を増やすには、CPUパワー、RAM、または高速ディスクを追加する必要があることをご存知でしょう。これらはそれぞれ多額の費用がかかります。しかし、最終的には、依然としていくつかの上限と制約に遭遇します。

これとは対照的に、Cassandraでは、管理できるデータ量を簡単に増やすことができます。ノードに基づいているため、Cassandraはコモディティハードウェアを使用して水平方向にスケールします（スケールアウト）。容量を倍増するかスループットを倍増するには、ノードの数を倍増します。それだけのことです。より強力な処理能力が必要ですか？ダウンタイムなしで、8個でも8,000個でも、ノードを追加できます。必要に応じてスケールバックすることもできます。

この線形スケーラビリティは、本質的に無期限に適用されます。この機能は、Cassandraの主要な強みの1つとなっています。

Cassandraでは、データ自体が自動的に分散され、（正の）パフォーマンス効果が生じます。これはパーティションを使用して実現されます。各ノードは特定のトークンセットを所有し、Cassandraはこれらのトークンの範囲に基づいてクラスタ全体にデータを分散します。パーティションキーは、ノード間でデータを分散する役割を果たし、データの場所を決定するために重要です。データがクラスタに挿入されると、最初にパーティションキーにハッシュ関数を適用します。その出力を使用して、どのノード（トークン範囲に基づく）がデータを取得するかを決定します。

データが入力されると、データベースのコーディネータは、特定のパーティション（パーティション59と呼びます）への割り当てを担当します。クラスタ内のどのノードも、コーディネータの役割を果たすことができることを思い出してください。前述のように、ノードは互いにゴシップし、その中でどのノードがどの範囲を担当しているかを伝達します。したがって、この例では、コーディネータはルックアップを実行します。トークン59を持っているノードはどれですか？適切なノードを見つけると、そのデータをそのノードに転送します。その範囲のデータの所有者であるノードは、レプリカノードと呼ばれます。1つのデータは複数の（レプリカ）ノードにレプリケートでき、信頼性とフォールトトレランスが保証されます。これまでのところ、データは1つのレプリカにのみレプリケートされています。これは、レプリケーションファクター1、つまりRF = 1を表します。

コーディネータノードは単一の場所ではありません。コーディネータノードが単一の場所であれば、システムは脆弱になります。それは単に、その特定の瞬間にリクエストを受け取るノードです。どのノードもコーディネータとして機能できます。

1つのデータは複数の（レプリカ）ノードにレプリケートでき、信頼性とフォールトトレランスが保証されます。Cassandraは、データベースに存在するべきデータのコピー数を記述するレプリケーションファクター（RF）の概念をサポートしています。これまでのところ、データは1つのレプリカにのみレプリケートされています（RF = 1）。これをレプリケーションファクター2（RF = 2）に増やすと、データは2番目のレプリカにも格納する必要があります。したがって、各ノードは、プライマリ範囲に加えて、セカンダリ範囲のトークンを担当することになります。レプリケーションファクター3は、その特定のトークン範囲をカバーする3つのノード（レプリカ）があり、データが別のノードに格納されることを保証します。

Cassandraの分散特性により、より高いレジリエンスとパフォーマンスが実現します。これは、同じデータに複数のレプリカがある場合に特に有効です。これにより、ノードのダウン、ハードドライブの故障、AWSによるインスタンスのリセットなど、問題が発生した場合に、システムが自己修復できます。レプリケーションにより、データが失われることはありません。データのリクエストが入力された場合でも、レプリカの1つがダウンしていても、残りの2つはリクエストを処理できます。コーディネータは、そのデータの「ヒント」も格納し、ダウンしたレプリカが復帰すると、何が不足していたかを検出し、他の2つのレプリカに追いつきます。手動操作は不要で、完全に自動的に行われます。

複数のレプリカの使用は、パフォーマンス上の利点も提供します。単一のインスタンスに限定されないため、操作にデータを提供するためにアクセスできる3つのノード（レプリカ）があり、これらの中でロードバランシングを行うことで、最高の性能を達成できます。

Cassandraは、異なるデータセンターにデータを自動的にレプリケートします。アプリケーションは、米国西海岸のCassandraノードにデータを書き込むことができ、そのデータはアジアやヨーロッパのノードのデータセンターで自動的に利用できるようになります。これは、特に世界中のユーザーベースをサポートしている場合に、パフォーマンス上の利点があります。クラウドコンピューティングと高速なデータアクセスに依存する世界では、距離によるレイテンシの影響を受けるユーザーはいません。

分散システムと可用性について多く説明してきました。CAP定理に精通している場合、CassandraはデフォルトでAP（Available Partition-tolerant）データベースであるため、「常にオン」です。しかし、実際には、クエリごとに一貫性を設定できます。このコンテキストでは、一貫性レベルは、操作が成功と見なされる前に、コーディネータへの読み取りまたは書き込み操作を承認する必要があるCassandraノードの最小数を表します。一般的には、レプリケーションファクターに基づいて一貫性レベル（CL）を選択します。 下の例では、データは3つのノードにレプリケートされています。CL=QUORUM（クォーラムは多数派を指し、この場合は2つのレプリカ、またはRF/2 + 1）があるため、コーディネータはクエリが成功と見なされるためには、2つのレプリカから承認を得る必要があります。

他のコンピューティングタスクと同様に、最適なパフォーマンス、可用性、データ整合性のためにこの機能を調整するには、ある程度のスキルが必要です。しかし、このような粒度で制御できるという事実は、展開を非常に詳細に制御できることを意味します。

最終的に、Cassandraはデプロイメントに依存しません。オンプレミス、クラウドプロバイダ、複数のクラウドプロバイダなど、どこに配置しても問題ありません。単一のデータベースにそれらの組み合わせを使用できます。これにより、ソフトウェア開発者は最大の柔軟性を獲得できます。