Cassandra 中使用复合主键的慢插入时间

Posted 2023-03-25

【中文标题】Cassandra 中使用复合主键的慢插入时间

【英文标题】：Slow Insert Time With Composite Primary Key in Cassandra

【发布时间】：2013-07-24 19:02:59

【问题描述】：

我一直在与 Cassandra 合作，但遇到了一些绊脚石。对于我需要如何搜索数据，我发现复合主键非常适合我需要的东西，但是此列族中记录的插入时间会随它而去，我不完全确定为什么。

表定义：

CREATE TABLE exampletable (
clientid int,
filledday int,
filledtime bigint,
id uuid,
...etc...
PRIMARY KEY (clientid, filledday, filledtime, id)
);

clientid = 客户端的内部 ID。 fillday = 自 1900 年 1 月 1 日以来的天数。填充时间 = 接收记录的当天的刻度数。 id = 一个向导。

存在日期和时间结构是因为我需要能够轻松快速地按天过滤。

我知道 Cassandra 以完全不同的方式存储具有复合主键的列族。据我了解，它将所有内容作为新列存储在主键主要组件的基本行之外。这是插入速度慢的原因吗？当我说慢时，我的意思是，如果我在 id 上只有一个主键，则插入将花费约 200 毫秒，并且使用复合主键（或它的任何子集，我只尝试了 clientid 和 id 以达到相同的效果）它将需要1000 条记录超过 32 秒。复合键表中的选择时间更快，因为我必须应用二级索引并使用“ALLOW FILTERING”才能使用标准键表取回正确的记录（我知道我可以在代码中执行此操作，但问题是我正在处理一些海量数据集，这并不总是可行或可能的）。

我是否声明列族或主键对于我正在尝试做的事情是错误的？对于所有未列出的非主键列，该表的宽度为 37 列，这会是问题吗？在这一点上，我很困惑。我无法真正找到其他人遇到类似问题的任何信息。

【参考方案1】：

好吧，您的分区键是客户端 ID，因此每个客户端的所有写入都转到一个节点。如果您为每个客户端写入大量数据，最终可能会出现热点，从而降低整体吞吐量。

另外，您能否举例说明您运行的查询？在 Cassandra 中，数据模型始终需要类似于您要运行的查询。如果您需要“允许过滤”，那么您的数据模型似乎不太对劲。例如，我真的没有在你的 PK 中看到“填充时间”的意义。如果您想按时间段查询，只需将您的三列键替换为 TimeUUID 列“ts”。这将创建一个宽行，每个条目有一列，具有唯一的时间戳，每个客户端 ID 进行集群/分区。 这允许以下查询：

select * from exampletable where clientid = 123 and ts > minTimeuuid('2013-06-18 16:23:00') and ts < minTimeuuid('2013-06-18 16:24:00');

同样，这取决于您实际需要运行的查询。

最后，有关数据建模的总体指导，请查看this ebay tech blog。阅读它帮助我理清了一些事情。

希望有帮助！

【讨论】：

对于查询示例，我需要能够执行以下操作：1) 获取客户一天的记录 2) 获取客户某个日期和时间的记录。我使用了填充日和填充时间，主要是因为我的代码库是 .Net，并且没有内置的 timeuuid 功能。我现在有一些东西，所以我要试一试。我现在看到这个问题的方式是，我需要找到一个关键结构，让我在不了解客户端和时间的情况下执行这些查询，但仍将数据划分得足够多，以免插入速度变慢。注意：数据集非常大。

我建议使用我上面提出的结构并使用.NET clients like fluentcassandra 来使用 TimeUUID。为了避免热点，您可以轻松地添加一个随机整数（从预定义的范围，如 0-9）并形成一个复合分区键，如下所示：CREATE TABLE exampletable ( clientid int, bucket, int id timeuuid, ... PRIMARY KEY ((clientid, bucket), id) );select * from exampletable where clientid = 123 and bucket IN (0,1,2,3,4,5,6,7,8,9) and ts > minTimeuuid('2013-06-18 00:00:01') and ts < minTimeuuid('2013-06-18 16:24:00');