Cassandraの読み取りパフォーマンス

Question

Cassandraクラスターは、読み取り操作では、が20％遅くなります。は単一ノードクラスターよりも遅いですか？

私はという3ノードのカサンドラクラスターをセットアップし、読み取りパフォーマンスをテストしました。私はCassandraの統合ストレステストツールを使用しました。比較のため、同じサーバー上に1つの別個のノード（単一ノードクラスタ）があります。

構成は次のとおりです。Cassandraクラスタ（3ノード、v。ドライブ（4ドライブ）。

すべての仮想マシンには16GBのRAMがあり、サーバーCPUの16個の論理コアすべてにアクセスできます。ノード間のネットワーク速度は約500MB/sです。 READテストを1M行で数回実行し、ウォームアップを有効にしました。すべてのデフォルト設定が使用されます（整合性= 1を含む）。

シングルノードCassandraは、クラスタ（2000 op/s）よりも常に高い読み取りパフォーマンスを実現します。（約2400 op/s）です。 マルチノードクラスタでパフォーマンスが低下するのはなぜですか？クラスタ構成で何が間違っていますか？

CREATE KEYSPACE keyspace1 WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'} AND durable_writes = true; 

CREATE TABLE keyspace1.standard1 (
key blob PRIMARY KEY, 
"C0" blob, 
"C1" blob, 
"C2" blob, 
"C3" blob, 
"C4" blob 
) WITH COMPACT STORAGE 
AND bloom_filter_fp_chance = 0.01 
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} 
AND comment = '' 
AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'} 
AND compression = {'enabled': 'false'} 
AND crc_check_chance = 1.0 
AND dclocal_read_repair_chance = 0.1 
AND default_time_to_live = 0 
AND gc_grace_seconds = 864000 
AND max_index_interval = 2048 
AND memtable_flush_period_in_ms = 0 
AND min_index_interval = 128 
AND read_repair_chance = 0.0 
AND speculative_retry = '99PERCENTILE'; 

テストCassandraのクラスタは単一ノードクラスタより読み出し動作中の20％遅くさせる何

cassandra-stress read n=1000000 cl=local_one -node IPADDRESS -rate threads=1 

Single-node stress test results

Multi-node stress test results

Answer 1

結果？

物理学。

単一ノードクラスタでは、いくつかのことが常にうまくいくでしょう。特にこのようなデータセットは非常に小さいです。単一のノードが処理できる負荷よりも負荷が小さい場合、理論的にはノードから得られる最適なパフォーマンスが得られます。ノード数を増やすと、作業量が増え、ノード数が増えるまで現実的ではないため、単一ノードのベンチマークはあまり意味がありません。カッサンドラを分散データベースにするすべてのことを行うことはありません。単一ノードクラスタを実行することは危険です。

シングルノードクラスタでは、接続の速さに関係なく他のノードと通信する必要はなく、ローカル作業よりもはるかに遅いです。この作業の多くは非同期で行われますが、レプリカの順序付け、ダイジェストノードの選択、ヒントの保存と追跡、非同期的なデータの比較と修復（btw setting dclocal_read_repair_chance = 0）少し）。

トークン対応のロードバランシングポリシーを使用していない場合、コーディネータは最初に別のノードからクエリを送信できるようになるまで、応答の送信をブロックする必要があります。

また、オーバーヘッドが分散された時点からノードを追加するまでの間にノードを追加すると、スループットが線形に改善されることは期待しないでください（〜5）。

本当に欲しいのなら、read repairチャンスを0に設定し、RF = Nを増やすと、期待通りのものが増えます。