ポイント: Apache Cassandraの構成は、レプリケーション設定を通じてデータ整合性を管理し、応答時間と正確性のバランスを取ることに重点を置いています。高い整合性のアプリケーションにとって重要です。
- 最終的な整合性の構成は、書き込みと読み取り操作を強化します。
- レプリケーション戦略には、効果的なデータ管理のためのSimpleStrategyとNetworkTopologyStrategyが含まれます。
Apache Cassandraがデータ整合性をどのように処理するか見てみましょう。
クラスター内のn - 1ノードにデータを書き込み、その後、アプリケーションがノードnからそれを読み取ると、レプリケーションが即時でないため、Cassandraはデータが存在しないと報告する可能性があります。それは大きな問題か、まったく問題でないかもしれません。それはアプリケーションによります。もしそれが収益を生み出すアプリケーションであれば、それは問題です。
したがって、Cassandraは管理者にアプリケーションレベルでのデータレプリケーションと整合性の構成を許可します。トレードオフは応答時間とデータの正確性です。
このアプリケーションレベルで構成する機能は最終的な整合性と呼ばれています。名前が示すように、Cassandraに操作後にすべてのデータをすべてのデータセンターとラックに書き込むまで待つように指示することができます。または、最初の書き込みが完了したら次の操作に移ることができ、Cassandraが最終的に追いつくことを理解しています。
この考え方は、アプリケーションを設計する際にレンタルまたは購入するストレージの種類を決定することと同じです。重要度が低いと見なされるアプリケーションは、低コストのストレージを使用し、さらに少ないドライブで、レプリカを少なくするか、まったく作成しない場合があります。
整合性は次のレベルで設定できます：
- データセンター
- クラスター
- I/O操作タイプ（すなわち、読み取りまたは書き込み）
書き込みと読み取りの整合性
書き込み整合性にはさまざまなオプションがあります。ここにいくつか示します。
| ALL |
データは各ノードのメモリテーブルとコミットログに書き込む必要があります。Cassandraがデータを書き込む際に行う手順は次のとおりです：
|
| QUORUM | データセンターレベルのクォーラム。 クォーラムは((レプリカの数)) / 2 + 1を切り上げたものです。 1を追加することで、その除算が小数になる場合に次の整数になります。 データセンターの一部に書き込むことはできないため、さらに1を追加します。 |
| ONE, TWO, THREE | 1、2、または3のレプリカ、つまりノードレベルでの意味です。 |
読み取り整合性
設定された書き込み整合性に応じて、ノードによっては他のノードよりも古いデータのコピーを持つことになります。したがって、読み取り整合性も構成できるのは理にかなっています。
| ALL | すべてのレプリカが応答するまで待ちます。 |
| ... | etc. |
レプリケーション戦略
レプリケーションはデータ整合性の要因です。レプリカとはデータのコピーを意味します。
書き込みが成功したかどうか、レプリケーションが機能しているかどうかを判断するために、Cassandraにはスニッチと呼ばれるオブジェクトがあります。これは、ノードがどのデータセンターとラックに属しているか、またネットワークトポロジーを決定します。
レプリケーションステーションは2つあります：
- SimpleStrategy—1つのデータセンターと1つのラック。
- NetworkTopologyStrategy—複数のラックと複数のデータセンター。これは、たとえ1つのデータセンターしかない場合でも推奨されます。
ここで、例を用いて説明します。
最初に、これらの手順に従ってクラスターをセットアップします。
nodetoolを使用して、スニッチによって報告されたデータセンターの名前を確認します。ここでの名前はdatacenter1です。これにより、このクラスターには2つのノードがあることが示されます。もちろん、各ノードでこれを実行して、各ノードがどのデータセンターに属しているかを確認します。
nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 172.31.46.15 532.22 MiB 256 ? 58999e76-cf3e-4791-8072-9257d334d945 rack1
UN 172.31.47.43 532.59 MiB 256 ? 472fd4f0-9bb3-48a3-a933-9c9b07f7a9f6 rack1
NetworkTopologyStrategyで1つのレプリカをdatacenter1に持つキー空間を作成します。つまり、データを2つのラックに書き込む必要があります。データセンターは1つしかないためです。
CREATE KEYSPACE Customers
WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'datacenter1' : 1};
次に、テーブルを作成します：
CREATE TABLE Customers.Customers (
Name text PRIMARY KEY,
credit int
);
その中にいくつかのデータを入れます：
insert into Customers.Customers (name, credit) values ('Hardware Store', 1000);
トレーシングをオンにします。
cqlsh> TRACING on;
Now Tracing is enabled
そして、別のレコードを書き込みます：
insert into Customers.Customers (name, credit) values ('Book Store', 1000);
Cassandraはレイテンシに関する情報を返します。ラックレベルの操作は表示されません。
Tracing session: bf8e0a90-0c43-11e9-9628-9d6a90b241c5
Parsing insert into Customers.Customers (name, credit) values ('Book Store', 1000);
activity| timestamp | source | source_elapsed | client
[Native-Transport-Requests-1] | 2018-12-30 15:01:12.761000 | 172.31.46.15 | 203 | 127.0.0.1
Preparing statement [Native-Transport-Requests-1] | 2018-12-30 15:01:12.762000 | 172.31.46.15 | 359 | 127.0.0.1
Determining replicas for mutation [Native-Transport-Requests-1] | 2018-12-30 15:01:12.762000 | 172.31.46.15 | 662 | 127.0.0.1
Appending to commitlog [Native-Transport-Requests-1] | 2018-12-30 15:01:12.762000 | 172.31.46.15 | 753 | 127.0.0.1
Adding to customers memtable [Native-Transport-Requests-1] | 2018-12-30 15:01:12.762000 | 172.31.46.15 | 827 | 127.0.0.1
Request complete | 2018-12-30 15:01:12.762121 | 172.31.46.15 | 1121 | 127.0.0.1
Cassandraガイド
これらの投稿は私自身のものであり、必ずしもBMCの立場、戦略、または意見を表すものではありません。