我通过Python（DataStax）驱动程序和CQL BatchStatements [1]插入Cassandra 3.12。使用导致少量分区（10-20）的主键一切正常，但数据不是均匀分布在节点上。
如果我包含高基数列，例如时间或客户端IP以及日期，则批量插入会导致分区太大错误，即使行数和行长度相同。
更高的基数密钥应该会产生更多但更小的分区。生成更多分区的密钥如何导致此错误？
[1]虽然我读过的所有内容都表明批量插入可以是反模式，批量只覆盖一个分区，但与此情况下的异步或当前插入相比，我仍然看到最高的吞吐量。
CREATE TABLE test
(
date date,
time time,
cid text,
loc text,
src text,
dst text,
size bigint,
s_bytes bigint,
d_bytes bigint,
time_ms bigint,
log text,
PRIMARY KEY ((date, loc, cid), src, time, log)
)
WITH compression = { 'class' : 'LZ4Compressor' }
AND compaction = {'compaction_window_size': '1',
'compaction_window_unit': 'DAYS',
'class': 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy'};
答案 0 :(得分：2)
我猜你的意思是Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: Batch too large错误？
这是因为参数batch_size_fail_threshold_in_kb在一个批次中默认为50kB的数据 - 并且在cassandra.yml中通过batch_size_warn_threshold_in_kb的5Kb阈值之前也有警告（参见{ {3}}）。
您可以分享您的数据模型吗？只添加一列并不意味着要更改的分区键 - 也许您只是通过添加一个聚类列来更改主键。提示：PRIMARY KEY (a,b,c,d)仅使用a作为分区键，而PRIMARY KEY ((a,b),c,d)使用a,b作为分区键 - 这是一个容易被忽视的错误。
除此之外，额外的列需要一些空间 - 因此您现在可以轻松达到阈值，只需减小批量大小，使其再次符合限制。一般情况下，如上所述，批处理仅影响单个分区的影响是一种好方法。还可以使用异步查询并向不同的协调器发出并行请求以获得更快的速度。