带有少量数据的 Cassandra 查询超时答案

【问题标题】：Cassandra Query Timeout with small set of data带有少量数据的 Cassandra 查询超时
【发布时间】：2017-04-04 18:00:33
【问题描述】：

我在使用 Cassandra 2.1.17 时遇到问题。我有一张桌子，里面有大约 40k “行”。我遇到问题的一个分区中可能有大约 5k 个条目。

表格是：

create table billing (
    accountid uuid,
    date timeuuid,
    credit double,
    debit double,
    type text,
    primary key (accountid,date)
) with clustering order by (date desc)

所以这个表有很多插入和删除。

我的问题是，我认为它似乎以某种方式损坏了，因为我不再能够从分区中选择超过某个点的数据。

从 cqlsh 我可以像这样运行一些东西。

SELECT accoutid,date,credit,debit,type FROM billing WHERE accountid=XXXXX-xxxx-xxxx-xxxxxx... AND date

首先我做了一个 10000 的选择限制，它最多可以对大约 5000 行进行分页，然后到最后它会给出超时错误。

然后我使用最后一个 timeuuid 中的第二个并选择限制 2 它将失败限制 1 将起作用。

如果我使用最后一个 timeuuid 作为

所以我只是在寻找我能在这里做什么，我不确定出了什么问题，也不确定如何修复/诊断发生的事情。

我已经厌倦了修复并强制压实。但它似乎仍然有问题。

感谢您的帮助。

【问题讨论】：

感谢您的所有回复。我发现这个链接我们更详细地介绍了我如何在 cassandra 中使用这个表和一些选项。一般来说，我认为你们所有人都是正确的，墓碑是问题所在。如果不是这样，将尝试发表评论。这是我找到的链接。 lostechies.com/ryansvihla/2014/10/20/…
是的，感谢所有回答肯定是因为太多墓碑的结果的人。

标签： cassandra

【解决方案1】：

尝试从对表运行手动压缩开始。
您可以在 cassandra 配置中增加 read_request_timeout_in_ms 参数。
如果您有大量删除和更新，请考虑改用分级压缩策略。

【讨论】：

感谢您的建议，将尝试看看是否有帮助。是的，桌子上会有很多删除。我想知道是否有一种方法可以将此表设置为具有不同的压缩时间表或其他类似的表。目前该表被用作队列。
STCS 和 LCS 都有您可以使用的参数。从降低 STCS 中的压缩触发器或 LCS 中的小表大小的阈值开始。
LeveldCompactionStrategy 更适合这个用例，但如果你的墓碑太多（超过 100 000 个）也无济于事
另外，在增加 read_request_timeout_in_ms 时必须小心，您有达到集群饱和点的风险。
@DineMartine “如果你有太多的墓碑（超过 100 000 个）” - 为什么，如果他将它调整为具有小表大小和低 gc_grace？

【解决方案2】：

我认为你在这个分区中的墓碑太多了。

什么是墓碑？

为了记住一条记录已被删除，Cassandra 创建了一个称为“墓碑”的特殊值。墓碑具有与任何其他值一样的 TTL，但它不像任何其他值那样容易压缩。 Cassandra 会保留更长的时间，以避免数据重新出现等不一致。

如何看墓碑？

nodetool cfstats 让您了解每个切片平均有多少个墓碑

如何解决问题？

墓碑保留的持续时间是gc_grace_seconds。你必须减少它，然后运行 major compaction 来解决这个问题。

【讨论】：

【解决方案3】：

在我看来，当您进行选择时，您会碰到很多墓碑。问题是，当他们在那里时，cassandra 仍然需要检查他们。可能有多种因素，例如带有插入语句的 ttl、大量删除、插入空值等。

我敢打赌，您需要在桌子上调整 gc_grace_seconds 并更频繁地进行维修。但要小心，不要将其设置为低（必须在此之前完成一轮修复）。

这一切都在这里得到了很好的解释： https://opencredo.com/cassandra-tombstones-common-issues/

【讨论】：