web-dev-qa-db-ja.com

Cassandra整合性ONEでの読み取りクエリ中のタイムアウト（1つの応答が必要でしたが、0のレプリカのみが応答しました）

500000行のテーブルで読み取りおよび更新クエリを実行していますが、ノードがダウンしていない場合でも、約300000行を処理した後にエラーを下回ることがあります。

整合性ONEでの読み取りクエリ中のCassandraタイムアウト（1つの応答が必要でしたが、0のレプリカのみが応答しました）

インフラストラクチャの詳細：
5つのCassandraノード、5 spark、3つのHadoopノードがそれぞれ8コアと28GBのメモリとCassandra 複製係数はです。

カサンドラ2.1.8.621 | DSE 4.7.1 | Spark 1.2.1 | Hadoop2.7.1。

Cassandra構成：

read_request_timeout_in_ms (ms): 10000
range_request_timeout_in_ms (ms): 10000
write_request_timeout_in_ms (ms): 5000
cas_contention_timeout_in_ms (ms): 1000 
truncate_request_timeout_in_ms (ms): 60000
request_timeout_in_ms (ms): 10000.

read_request_timeout_in_ms（ms）も20,000に増やして同じジョブを試しましたが、役に立ちませんでした。

2つのテーブルでクエリを実行しています。以下は、テーブルの1つのcreateステートメントです。

テーブルの作成：

CREATE TABLE section_ks.testproblem_section (
    problem_uuid text PRIMARY KEY,
    documentation_date timestamp,
    mapped_code_system text,
    mapped_problem_code text,
    mapped_problem_text text,
    mapped_problem_type_code text,
    mapped_problem_type_text text,
    negation_ind text,
    patient_id text,
    practice_uid text,
    problem_category text,
    problem_code text,
    problem_comment text,
    problem_health_status_code text,
    problem_health_status_text text,
    problem_onset_date timestamp,
    problem_resolution_date timestamp,
    problem_status_code text,
    problem_status_text text,
    problem_text text,
    problem_type_code text,
    problem_type_text text,
    target_site_code text,
    target_site_text text
    ) WITH 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'}
    AND compression = {'sstable_compression': 
    'org.Apache.cassandra.io.compress.LZ4Compressor'}
    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 = '99.0PERCENTILE';

クエリ：

1）SELECT encounter_uuid, encounter_start_date FROM section_ks.encounters WHERE patient_id = '1234' AND encounter_start_date >= '" + formatted_documentation_date + "' ALLOW FILTERING;

2）UPDATE section_ks.encounters SET testproblem_uuid_set = testproblem_uuid_set + {'1256'} WHERE encounter_uuid = 'abcd345';

hadoopcassandraapache-sparkdatastaxdatastax-java-driver
8
Abhinandan Satpute

通常、タイムアウトエラーが発生した場合は、Cassandraで適切にスケーリングされていないことを実行しようとしていることを意味します。多くの場合、修正はスキーマを変更することです。

クエリの実行中にノードを監視して、問題のある領域を特定できるかどうかを確認することをお勧めします。たとえば、「watch -n 1 nodetool tpstats」を実行して、アイテムをバックアップまたはドロップしているキューがあるかどうかを確認できます。他の監視の提案を参照してください ここ 。

構成でオフになっている可能性があることの1つは、5つのCassandraノードがあるが、3つのsparkワーカーがある（または3つあると言っている） spark各ノードのワーカーCassandraノード？）少なくとも1つのspark各ノードのワーカーCassandraノードで、データのsparkへのロードは、ネットワーク経由ではなく、各ノードでローカルに実行されます。

スキーマと実行中のクエリを確認せずに、それ以上のことを伝えるのは困難です。単一のパーティションから読み取っていますか？単一のパーティションから読み取るときに、300,000行付近でタイムアウトエラーが発生し始めました。質問 ここ を参照してください。これまでに見つけた唯一の回避策は、パーティションキーでクライアント側のハッシュを使用して、パーティションを約10万行の小さなチャンクに分割することです。これまでのところ、長い時間がかかると予想されるクエリに対してタイムアウトしないようにCassandraに指示する方法は見つかりませんでした。

10
Jim Meyer