在cassandra中慢選擇查詢

我有一個包含3個節點的cassandra集羣。有一張桌子可以存放大約400M行。我點擊下面的選擇查詢：在cassandra中慢選擇查詢

SELECT * FROM table_1 WHERE vuid in ('abc','def','ghi');

上面是一個示例查詢。在我們的生產環境中的子句中有1000個鍵。以下是表格結構

CREATE TABLE dmp.user_profiles_9 (
    vuid text PRIMARY KEY, 
    apnid text, 
    brand_model text, 
    first_seen timestamp, 
    ifa text, 
    last_seen timestamp, 
    msisdn text, 
    total_day_count int, 
    total_usage_count int, 
    user_type 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', 'max_threshold': '32', 'min_threshold': '4'} 
    AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'} 
    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';

「in」子句中的1000個鍵需要5秒以上的時間。我們需要每日更新以上數據集。這項工作涉及全表掃描。爲了儘快完成每個閱讀應該更快。在上述情況下可以做些什麼？

來源

2016-08-04 Shades88

上面的查詢協調器節點將不得不對1000個密鑰進行散列並將其重新路由到相關副本節點，然後等待來自副本的結果。你可以減少IN子句中的值或者全部刪除in子句並使用異步查詢 –

我有基本的問題，應該對Cassandra進行更新嗎？我們需要每天掃描大約100M密鑰並更新其值。插入物快速燃燒。但是對於更新工作，我們需要選擇他們以前的值作出一些決定，然後進行更新。而且這個速度非常緩慢。插入速度爲8000插入/秒。但在更新中，我們每秒只能獲得200-500次更新，因爲它涉及使用我在問題 – Shades88

中提供的查詢來選擇數據。更新與插入具有相同的寫入路徑，在寫入之前讀取會損害性能。嘗試讀取較低的一致性級別並減少IN子句中的鍵 –

您可以嘗試的一個嘗試是將IN子句拆分爲多個查詢，您可以異步執行此操作並將單個結果返回到完整的結果集中。

一個例子，以及一些更多的討論，這可以找到here。

這將防止只有一個節點進行協調，從而允許將負載正確分散到其他節點。如果您進行此更改，它也會受益於TokenAware負載平衡策略，因此每次都會查找包含您查找的數據的節點。

來源

2016-08-04 12:53:17 Samyel

在cassandra中慢選擇查詢

回答

相關問題