Cassandra CQL 准备好的语句比非准备好的语句慢？

Posted 2023-04-18

【中文标题】Cassandra CQL 准备好的语句比非准备好的语句慢？

【英文标题】：Cassandra CQL prepared statements slower than non prepared ones?

【发布时间】：2015-03-27 14:08:40

【问题描述】：

最近我们一直在对我们的一些 Cassandra 集群进行压力测试，比较一致性级别、准备/非准备语句和同步/异步执行模式的所有组合的性能，并且在每个配置中，最高性能始终是以下组合（任何/一个）异步运行的非准备语句！

那里有一些有意义的位，任何/一个一致性级别的限制较少，因此应该是最快的。同样异步运行查询，因此利用并行计算应该比顺序运行更快，但是准备好的和非准备好的语句呢？

我们一直阅读和听到（博客、峰会、布道者……）我们应该尽可能支持准备好的声明而不是未准备好的声明，但是这个结果令人困惑……

为了让您了解一些背景知识，我们使用了两种不同的工具（一种是内部构建的，一种是 cassandra-stress），它们都产生了相同的结果。

以前有人遇到过这种情况吗？哪个是解释？我们缺少什么？

问候

编辑：

Results using cassandra-stress tool Results using our own Ruby script

【问题讨论】：

您是在每次查询时都做准备，还是只做一次？如果只做一次，你应该节省一些时间，但我在 Cassandra 的跟踪中看到它可以节省几微秒的时间（因为需要在 cassandra 端准备未准备好的查询）。它应该节省通过线路传输的数据量，因为一旦您准备好查询，双方都知道列定义。

嘿@AndyTolbert 感谢您的评论。是的，我只准备一次声明。此外，准备好的语句应该将语句解析保存在 Cassandra 端，以便后续执行同一语句。据我了解，准备好的语句保存在网络中（语句执行仅提交绑定值）和解析（语句仅由引擎解析一次）。这就是它让这种情况如此奇怪的原因！

一些细节会很有帮助。即：什么语言驱动。示例查询？集群的大小和密钥空间的 RF。如果可以的话，数据模型。

嗨@PatrickMcFadin 感谢您的回复！我刚刚编辑了这篇文章，其中包含我使用 cassandra-stress 工具分享结果的要点。我现在将添加另一个包含我们自己的基准测试 (Ruby) 的结果。

这里的集群是EC2上一个VPC中的3节点集群，每个AZ中1个节点。 DSE 4.6，C* 2.0.12

【参考方案1】：

查看您的数据后，我认为您在此处看到的限制不是您的集群，而是运行测试的服务器。如果您正在测试 3 节点 Cassandra 集群，您可能需要 2-3 倍的客户端服务器产生负载。您可以尝试通过增加线程数来最大化每个客户端的使用量，但您会遇到限制。

一般来说，如果您在 cassandra 压力测试中得到平线结果，请查看被测节点。如果他们大部分时间都很无聊，请增加客户端（或线程）的数量，直到节点受到压力。 :)

【讨论】：

嘿@PatrickMcFadin，非常感谢您的回复，并对延迟回来感到抱歉，我们一直在同时对具有 3 个客户端的集群施加压力，现在结果更有意义。我们看到每个客户的操作较少，但整体较高，而且准备好的语句比未准备好的语句表现稍好（我期待更多的差异）。结论：prepared statements就像关系数据库索引，负载不够没用？结果要点：gist.github.com/calonso/e23dfadda3e9a5cca016 和 gist.github.com/calonso/ea8323e953648fed0541

完全正确。它们旨在减少宝贵的毫秒数。正如 Netflix 所做的一项研究所示，在高负载下，它确实可以发挥作用。 techblog.netflix.com/2013/12/astyanax-update.html