cassandra - 在 Cassandra 中有大量写入和一些读取的表。主键搜索需要 30 秒。 (队列)

Question

在 Cassandra 中设置一个表，设置如下:

主键列

shard - 1 到 1000 之间的整数

last_used - 时间戳

值列:

value - 一个 22 个字符的字符串

使用此表的示例:

shard     last_used          | value
------------------------------------
457       5/16/2012 4:56pm     NBJO3poisdjdsa4djmka8k    >--     Remove from front...
600       6/17/2013 5:58pm     dndiapas09eidjs9dkakah       | 
...(1 million more rows)                                    |
457       NOW                  NBJO3poisdjdsa4djmka8k    <--     ..and put in back

该表用作一个巨大的队列。很多线程都试图“弹出”最低 last_used 的行值，然后更新 last_used值到当前时刻。这意味着一旦读取一行，因为 last_used是主键的一部分，该行被删除，然后是具有相同 shard 的新行, value ，并更新 last_used时间被添加到表中，在“队列的末尾”。 shard是不是因为很多进程都在尝试 pop将最老的一行从队列的前面移开并将其放在后面，如果只有一个人可以同时访问队列，它们将严重相互瓶颈。这些行被随机分成 1000 个不同的“碎片”。每次线程从队列的开头“弹出”一行时，它都会选择一个当前没有其他线程使用的分片(使用 redis)。
天哪，我们一定是哑巴了!
我们遇到的问题是这个操作变得非常缓慢，大约 30 秒，这是一个虚拟的永恒。
我们只使用 Cassandra 不到一个月，所以我们不确定我们在这里做错了什么。我们已经得到一些迹象，也许我们不应该在同一张 table 上写和读这么多。我们不应该在 Cassandra 中这样做吗？或者我们的工作方式或我们配置它的方式是否存在一些细微差别，我们需要更改和/或调整？如何解决这个问题？
更多信息

我们正在使用 MurMur3Partitioner(新的随机分区器)

该集群目前在 9 台服务器上运行，每台服务器具有 2GB RAM。

复制因子为 3

非常感谢!

Answer 1

这是你不应该使用 Cassandra 的事情。您遇到性能问题的原因是因为 Cassandra 必须扫描成堆的墓碑才能找到剩余的事件列。每次删除某些内容时，Cassandra 都会写入一个墓碑，这是该列已被删除的标记。在进行压缩之前，实际上不会从磁盘中删除任何内容。在压缩 Cassandra 时查看墓碑并确定哪些列已死，哪些列仍然活着，将死的扔掉(但也有 GC 恩典，这意味着为了避免列的虚假复活，Cassandra 将墓碑保留在周围再过一段时间)。

由于您不断添加和删除列，因此将会有大量的墓碑，并且它们将分布在许多 SSTable 中。这意味着 Cassandra 需要做大量的开销工作才能将一行拼凑起来。

阅读 blog post "Cassandra anti-patterns: queues and queue-like datasets"了解更多详情。它还向您展示了如何跟踪查询以自己验证问题。

从您的描述中并不完全清楚什么是更好的解决方案，但听起来很像 RabbitMQ 这样的消息队列，或者 Kafka 可能是更好的解决方案。它们具有恒定的流失和 FIFO 语义，而 Cassandra 则不然。

有一种方法可以让 Cassandra 的查询不那么繁重，您可以尝试一下(尽管我仍然会说 Cassandra 是这项工作的错误工具):如果您可以在查询中包含时间戳，您应该主要点击实时列.例如。添加 last_used > ? (其中 ? 是时间戳)到查询。这要求您对第一个时间戳有一个粗略的了解(并且不要通过查询来找到它，这将同样昂贵)，因此它可能对您不起作用，但它会减轻一些负担 Cassandra 。