Cassandra 主键基数导致分区错误过大？

我将通过Python（DataStax）驱动程序和CQL BatchStatements[1]插入Cassandra 3.12。使用主键可以生成少量分区（10-20个），所有这些都可以正常工作，但数据在节点之间的分布并不均匀

如果我包括一个高基数列，例如除了日期之外的时间或客户机IP，则批插入会导致分区错误过大，即使行数和行长度相同

更高的基数键会导致更多但更小的分区。生成更多分区的密钥如何导致此错误

---

[1] 尽管我读到的所有内容都表明批插入可以是一种反模式，因为批只覆盖一个分区，但与异步插入或当前插入相比，我仍然看到这种情况下的最高吞吐量

---

创建表测试
(
日期，
时间,，
cid文本，
loc文本，
src文本，
dst文本，
大小比基特，
s_bytes bigint，
d_bytes bigint，
时间比金特女士，
日志文本，
主键（（日期、loc、cid）、src、时间、日志）
)
使用压缩={'class'：'LZ4Compressor'}
和压缩={'compression\u window\u size'：'1'，
“压缩窗口单位”：“天”，
'class'：'org.apache.cassandra.db.compression.TimeWindowCompactionStrategy'}；

我猜您的意思是

由以下原因引起：com.datastax.driver.core.exceptions.InvalidQueryException:批处理过大

错误

这是因为参数

batch\u size\u fail\u threshold\u in_kb

在默认情况下是单个批处理中50kB的数据，并且之前在cassandra.yml中通过

batch\u size\u warn\u threshold\u in_kb

在5Kb阈值处也有警告（请参阅）

你能分享你的数据模型吗？仅仅添加一列并不意味着要更改分区键——也许您只是通过添加一个集群列来更改主键。提示：

主键（a，b，c，d）

仅将

a

用作分区键，而

主键（（a，b，c，d）

将

a，b

用作分区键-这是一个容易被忽略的错误

---

除此之外，额外的列会占用一些空间，因此您现在可以轻松地达到阈值，只需减少批处理大小，使其再次符合限制。一般来说，这是一种只对单个分区产生影响的批处理的好方法。还可以使用异步查询，并向不同的协调器发出并行请求，以获得更快的速度

我将发布数据模型，但在本例中，我并没有添加列，而是将一个列移动到具有更高基数的PK中。行宽保持不变。上面添加了表。问题确实是插入的批的大小，而不是结果分区的大小。您移动到分区键中的列的大小是多少？@AlexOtt在上表中，用时间戳类型列替换了日期（类型日期）。如果同时包含数据列和时间列，则会出现相同的问题。我引用基数是因为时间的增加会导致更多的分区（因为分辨率），但不会改变行大小。我不认为我需要那么多的分区，但我试图理解主键和错误之间的关系。