Database design 优化子句查询cassandra？

我在锡拉布有一张这样的桌子。为了说明这一点，我已经从下表中删除了很多列，但通常这个表总共有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';

几个问题：

• 在线阅读后，看起来中的

  子句出于明显的性能原因不太好，那么有没有办法针对我的查询模式优化我的表，或者Cassandra/Scyllab不是很好的用例

• 我们使用C#driver执行上述查询，我们发现数据模型和查询模式存在性能问题。执行单个客户端id async更好，还是我应该继续在子句查询中执行所有clientId

---

我们在一个DC中运行6节点群集，RF为3。我们作为本地仲裁进行读/写。

当您在分区键上发出

中的
时，请求被发送到协调器节点（我不记得了，我认为在这种情况下，它可能是任意节点），然后协调器节点将
中的
分解为对单个分区的查询，对特定副本执行查询，将数据收集回来，并发送给调用者。所有这些都会导致协调器节点和副本之间的额外往返，以及协调器的额外负载

通常，更好的解决方案是从
列表中的
为每个分区发出N个异步查询，并在客户端收集数据-当您使用prepared语句时，驱动程序将能够使用令牌感知负载平衡，并将查询直接发送到持有给定分区的副本，因此，您可以避免协调器和副本之间的额外网络往返。
IN查询的问题是双重的。首先是另一个答案中提到的往返问题，即协调器可能不是所有请求的副本。第二个问题是过度读取：当将读取请求分派给复制副本时，协调器无法知道每个分区有多少数据。因此，为了确保页面被填充，它从每个分区请求一页数据。如果每个或大多数分区都有大量数据，这将导致返回的数据太多，而大部分数据将被丢弃，因为这些数据不适合页面。在下一页中，大部分数据将被读取，可能会再次被丢弃。
感谢您的解释。所以唯一的解决方案就是尝试多个异步调用，对吗？数据模型/查询模式对您来说合适吗？我们不能改变它来优化这个领域的任何东西吗？如果您总是查询“相关”键，那么数据模型的改变将有所帮助。在这种情况下，您可以将它们放在单个分区中，等等。但是它需要讨论用例本身。使用这种方法处理分页不会很复杂吗？
select * FROM testks.client WHERE client_id IN ? PER PARTITION LIMIT 1