cassandra中的慢速选择查询答案

【问题标题】：Slow select query in cassandracassandra中的慢速选择查询
【发布时间】：2016-08-04 09:38:59
【问题描述】：

我有一个 3 个节点的 cassandra 集群。一张表存储了大约 400M 行。我在下面选择查询：

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

以上是一个示例查询。我们的生产环境中的 In 子句有 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 秒以上。我们需要每天更新上述数据集。这项工作涉及全表扫描。为了尽快完成，每次阅读都应该更快。在上述情况下可以做什么？

【问题讨论】：

上述查询协调节点必须对 1000 个键进行哈希处理并将其重新路由到相关的副本节点，然后等待副本的结果。您可以减少 IN 子句中的值或完全取消 in 子句并使用异步查询
我有一个基本问题，是否应该在 Cassandra 上执行更新？我们需要每天扫描大约 100M 个密钥并更新它们的值。插入速度非常快。但是对于更新工作，我们需要选择他们以前的值做出一些决定然后更新。这运行得非常慢。插入速率为 8000 次插入/秒。但在更新中，我们每秒只能获得 200-500 次更新，因为它涉及使用我在问题中提供的查询来选择数据
更新与插入具有相同的写入路径，在写入之前读取会损害性能。尝试以较低的一致性级别阅读并减少 IN 子句中的键

标签： java cassandra

【解决方案1】：

您可以尝试的一种尝试是将 IN 子句拆分为多个查询，您可以异步执行此操作并将各个结果返回到完整的结果集中。

可以在here 找到一个示例和更多讨论。

这将阻止只有一个节点进行协调，从而使负载能够适当地分散到其他节点。如果您进行此更改，它还将受益于 TokenAware 负载平衡策略，因此每次都会命中具有您正在查找的数据的节点。

【讨论】：