优化子句查询cassandra?

jjhzyzn0  于 2021-06-13  发布在  Cassandra
关注(0)|答案(2)|浏览(346)

我在锡拉有一张这样的table。为了清楚起见,我已经从下表中删除了很多列,但通常这个表总共有25列。

CREATE TABLE testks.client (
    client_id int,
    lmd timestamp,
    cola list<text>,
    colb list<text>,
    colc boolean,
    cold int,
    cole int,
    colf text,
    colg set<frozen<colg>>,
    colh text,
    PRIMARY KEY (client_id, lmd)
) WITH CLUSTERING ORDER BY (lmd DESC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
    AND comment = ''
    AND compaction = {'class': 'TimeWindowCompactionStrategy', 'compaction_window_size': '1', 'compaction_window_unit': 'DAYS'}
    AND compression = {'sstable_compression': '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 = 172800
    AND max_index_interval = 1024
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99.0PERCENTILE';

现在我们的查询模式是这样的。我可以拥有更多 50 clientIds 在我的 IN 条款。

select * FROM testks.client WHERE client_id IN ? PER PARTITION LIMIT 1

几个问题:
在网上看了之后 IN 由于明显的性能原因,子句是不好的,那么有没有办法优化我的查询模式的表,或者cassandra/scylladb不是这个的好用例?
我们使用c#驱动程序执行上述查询,我们发现数据模型和查询模式存在性能问题。执行单个客户机id async是更好还是我应该继续这样做 IN 包含所有clientid的子句查询?
我们在一个dc中运行6节点群集,rf为3。我们以本地法定人数进行读写。

fslejnso

fslejnso1#

当你发布 IN 在分区键上,请求被发送到协调器节点(我不记得了,我想在这种情况下,它可能是一个任意节点),然后协调器节点将其分解 IN 进入到对单个分区的查询中,执行对特定副本的查询,收集数据并发送给调用者。所有这些都会导致协调器节点和副本之间的额外往返,以及协调器的额外负载。
通常情况下,更好的解决方案是为来自 IN 在客户端列出并收集数据—当您使用prepared语句时,驱动程序将能够使用令牌感知负载平衡,并将查询直接发送到包含给定分区的副本,这样您就可以避免协调器和副本之间的额外网络往返。

8dtrkrch

8dtrkrch2#

in查询的问题有两个方面。首先是另一个答案中提到的往返问题,即协调器可能不是所有请求的副本。第二个问题是过度读取:当将读取请求分派给副本时,协调器无法知道每个分区有多少数据。因此,为了确保页面被填满,它从每个分区请求一个值一页的数据。如果每个或大多数分区都有大量的数据,这将导致返回太多的数据,而大部分数据将被丢弃,因为这些数据不适合页面。在下一页中,大部分数据将被读取,可能会再次被丢弃。

相关问题