Cassandra Archi構造と複製係数
編集チーム
⚡ スマートサマリー
Cassandra このアーキテクチャは、単一障害点のない状態でピアノード全体にデータを分散し、調整にはゴシップ通信、耐久性にはレプリケーションを使用します。このページでは、すべてのコンポーネント、レプリケーション戦略、整合性レベル、内部の書き込みおよび読み取りパスについて説明します。
Cassandra 処理できるように設計されています ビッグデータ. Cassandraの主な機能は、単一障害点を発生させずに複数のノードにデータを保存することです。
このような理由は、 Cassandraのアーキテクチャでは、ハードウェア障害はいつでも発生する可能性があります。どのノードもダウンする可能性があります。障害が発生した場合、別のノードに保存されているデータを使用することができます。したがって、 Cassandra 分散アーキテクチャで設計されています。
Cassandra ピアツーピアの分散型アーキテクチャを使用して、異なるノードにデータを保存します。
すべてのノードは次を使用して相互に情報を交換します。 ゴシッププロトコル。ゴシップはプロトコルです Cassandra どのノードが相互に通信できるか。
の構成要素 Cassandra Archi構造
以下のコンポーネントが含まれています Cassandra Archi構造:
上記の図は、コンポーネントを階層構造で示しています。ノードはデータセンター内に配置され、データセンターはクラスタ内に配置され、コミットログ、メンテーブル、およびSSTableは各ノード内に存在します。
Node
ノードとはデータが保存される場所です。それはの基本的なコンポーネントです Cassandra.
Data Center
ノードの集合体はデータセンターと呼ばれます。 多くのノードはデータセンターとして分類されます。
Cluster
クラスターは、多数のデータセンターの集合です。
コミットログ
すべての書き込み操作はコミット ログに書き込まれます。コミット ログはクラッシュ回復に使用されます。
メモリテーブル
Commit logにデータが書き込まれた後、Mem-tableにデータが書き込まれます。 データはMem-tableに一時的に書き込まれます。
SSTテーブル
Mem-tableが一定のしきい値に達すると、データはSSTableディスクファイルに書き込まれます。SSTableは不変であるため、更新時には古いバージョンを編集するのではなく、新しいバージョンが書き込まれます。その後、コンパクションと呼ばれるバックグラウンドプロセスによってこれらのバージョンがマージされ、置き換えられた行が破棄されます。
データ複製 Cassandra
データ処理中はいつでもハードウェアの問題が発生したり、リンクがダウンしたりする可能性があるため、問題が発生したときにバックアップを提供するソリューションが必要です。 そのため、単一障害点をなくすためにデータが複製されます。
Cassandra これら 2 つの要素に基づいて、データのレプリカを異なるノードに配置します。
- 次のレプリカをどこに配置するかは、 レプリケーション戦略.
- さまざまなノードに配置されるレプリカの総数は、 レプリケーション係数.
XNUMX つのレプリケーション要素は、データのコピーが XNUMX つだけ存在することを意味し、XNUMX つのレプリケーション要素は、XNUMX つの異なるノード上にデータの XNUMX つのコピーが存在することを意味します。
単一障害点がないことを保証するために、 レプリケーション係数は XNUMX である必要があります。
レプリケーション戦略には XNUMX 種類あります。 Cassandra.
シンプルな戦略で Cassandra
Simple頭脳系 データ センターが 1 つしかない場合に使用されます。SimpleStrategy は、パーティショナーによって選択されたノードに最初のレプリカを配置します。その後、残りのレプリカはノード リングに時計回りに配置されます。
SimpleStrategy の図は次のとおりです。
ネットワークトポロジ戦略 Cassandra
ネットワークトポロジー戦略 2 つ以上のデータ センターがある場合に使用されます。NetworkTopologyStrategy では、レプリカは各データ センターごとに個別に設定されます。NetworkTopologyStrategy は、別のラックの最初のノードに到達するまで、リング内で時計回り方向にレプリカを配置します。この戦略では、同じデータ センター内の異なるラックにレプリカを配置しようとします。
これは、ラック内で障害や問題が発生する場合があるためです。 その後、他のノード上のレプリカがデータを提供できるようになります。
以下は、ネットワーク トポロジ戦略を図で表したものです。
複製係数は、存在するコピーの数を決定します。特定の要求に対して、それらのコピーのうちいくつが応答する必要があるかは、別の設定であり、次に説明します。
一貫性レベル Cassandra
一貫性レベルはクラスタごとではなくクエリごとに設定されるため、 Cassandra 調整可能。これは、コーディネーターがクライアントに応答する前に、何個のレプリカが書き込みを承認するか、または読み取りに応答する必要があるかを指定します。レベルが低いほど応答が速くなり、レベルが高いほどデータがより確実に最新になります。
| レベル | 行動 | 典型的な使用 |
|---|---|---|
| ONE | レプリカのうち1つが応答しなければならない。 | まれに古いデータが読み取られても許容される、高スループットのログ記録。 |
| 定足数 | レプリカの過半数が応答する必要があり、その割合は（RF / 2）+ 1で計算されます。 | バランスの取れた安定性と入手しやすさを兼ね備えた、汎用性の高い選択肢です。 |
| ローカルクォーラム | ローカルデータセンター内のレプリカの過半数が応答する必要がある。 | 複数のデータセンターで構成されるクラスタは、地域間の遅延を回避できるため、優れている。 |
| 全て | すべての複製物は応答しなければならない。 | 稀なケースです。ノードが1つダウンすると、リクエストが完全に失敗します。 |
| ANY （書き込みのみ） | レプリカにアクセスできない場合でも、ヒントとなるハンドオフが行われた場合は成功とみなされます。 | 耐久性を多少緩和できる範囲で、書き込み可用性を最大限に高める。 |
読み取りレベルと書き込みレベルの合計がレプリケーション係数を超えると、高い一貫性が保証されます。レプリケーション係数が3の場合、QUORUMレベルでの書き込みと読み取りは、2+2が3より大きいため、このルールを満たします。一方、ONEレベルでの書き込みと読み取りはルールを満たさないため、読み取り結果が古い値になる可能性があります。
レプリカにアクセスできない場合、コーディネーターは ヒント そしてノードが戻るとそれを再生します。これが ANY レベルと多くの Cassandra自己治癒行動の働き。
書きます Operaの Cassandra
コーディネーターは書き込みリクエストをレプリカに送信します。 すべてのレプリカが稼働している場合、整合性レベルに関係なく書き込みリクエストを受け取ります。
一貫性レベル 成功確認を返すノードの数を決定します。
データがコミット ログに正常に書き込まれた場合、ノードは成功通知で応答します。 メモリテーブル。
たとえば、レプリケーション係数が XNUMX の単一のデータ センターでは、XNUMX つのレプリカが書き込みリクエストを受け取ります。 整合性レベルが XNUMX の場合、XNUMX つのレプリカのみが成功確認を返し、残りの XNUMX つは休止状態のままになります。
残りの 2 つのレプリカがノードのダウンまたはその他の問題によりデータを失った場合、 Cassandra 組み込みの修復メカニズムによって行の一貫性が保たれます。 Cassandra.
ここでは、書き込みプロセスがどのように発生するかを説明します。 Cassandra,
- ノードに書き込みリクエストが来ると、まずコミットログに記録されます。
- その後 Cassandra データをmemテーブルに書き込みます。各書き込みリクエストで mem テーブルに書き込まれたデータは、コミット ログにも個別に書き込まれます。 Mem-table はメモリに一時的に保存されるデータであり、Commit ログはバックアップの目的でトランザクション レコードを記録します。
- mem-table がいっぱいになると、データが SSTable データ ファイルにフラッシュされます。
SSTable はインプレース編集されないため、削除しても行はすぐには削除されません。代わりに、マーカーと呼ばれるものが作成されます。 墓石 行は書き込まれ、猶予期間後に圧縮処理が実行されるまで削除されません。そのため、大量の削除処理が発生すると、圧縮処理が完了するまで読み取り速度が低下します。
タリアセン・ウェストにおける修復作業について Operaの Cassandra
コーディネーターがレプリカに送信する読み取りリクエストには XNUMX つのタイプがあります。
- 直接依頼
- ダイジェストリクエスト
- 修理リクエストを読む
コーディネーターは、レプリカの XNUMX つに直接リクエストを送信します。 その後、コーディネータは、整合性レベルで指定された数のレプリカにダイジェスト要求を送信し、返されたデータが更新されたデータであるかどうかを確認します。
その後、コーディネーターは残りのすべてのレプリカにダイジェスト要求を送信します。 いずれかのノードが古い値を返した場合、バックグラウンドの読み取り修復リクエストによってそのデータが更新されます。 このプロセスは読み取り修復メカニズムと呼ばれます。
直接リクエストを受け取るレプリカ内部では、可能な限りディスクへのアクセスを避けるように検索順序が設計されている。
- その memtable 最新の書き込みがまだフラッシュされていないため、最初にチェックされます。
- その 行キャッシュ有効になっている場合、追加の作業なしにリクエスト全体に応答できます。
- A ブルームフィルター 各SSTableに対して参照されます。この参照は「存在しない」または「存在する可能性がある」と回答するため、ほとんどのSSTableは読み込まずにスキップできます。
- その パーティションインデックス そしてその要約は、ブルームフィルタチェックを通過した任意のSSTable内の正確なバイトオフセットを特定します。
- 複数のSSTableから一致する断片がマージされ、各列について最新のタイムスタンプが優先されます。
ブルームフィルタは、ディスクシークが発生する前にほぼすべてのSSTableを考慮対象から除外するため、データ量の増加に伴って読み取り速度を維持するステップです。これらのメカニズムを複数のマシンに適用する方法については、 Cassandra チュートリアル。
