Cassandra 性能 SELECT by id 或 SELECT by Nothing

Question

我想知道 C*s SELECT 的速度是否取决于我们如何选择整个有限表。

例如我们有这张表

id | value
A  | x
A  | xx
B  | xx
C  | xxx
B  | xx

如果我们这样做的话，得到所有结果会不会更快
从 id='A' 处选择*
从 id='B' 处选择*
从 Y WHERE id='C' 中选择 *

或者如果我们这样做会更快
从 WHERE 1 选择*

或者如果我们这样做的话也许会更快
SELECT * FROM Y WHERE id IN ('A', 'B', 'C')

或者它们会同样快吗(如果我们忽略连接时间)

Answer 1

不确定您的列族(表)定义是什么样的，但您的示例数据永远不会像 Cassandra 中那样存在。主键是唯一的，如果 id 是您的主键，则最后一次写入将获胜。基本上，您的表格看起来像这样:

id | value
A  | xx
C  | xxx
B  | xx

至于您的个人疑问...

SELECT * FROM Y WHERE 1

这对于 3 行可能很有效，但当你有 300 万行且全部分布在多个节点时就不行了。

SELECT * FROM Y WHERE id IN ('A', 'B', 'C')

这绝对不是更快。 See my answer here至于为什么依赖 IN 来实现偶尔的 OLAP 便利以外的其他目的并不是一个好主意。

SELECT * FROM Y WHERE id='A'
SELECT * FROM Y WHERE id='B'
SELECT * FROM Y WHERE id='C'

这绝对是最好的办法。 Cassandra 设计为通过特定的、唯一的分区键进行查询。即使您想要查询列族(表)中的每一行，您仍然需要为其提供特定的分区键。这将帮助您的驱动程序快速确定将查询发送到哪个节点。

现在，假设您确实有 300 万行。对于您的应用程序，查询每个单独的数据更快，还是仅执行 SELECT * 更快？从查询的角度来看，它可能会更快，但您仍然需要迭代每个查询(客户端)。这意味着在可用 JVM 内存的限制内管理它们(这可能意味着在某种程度上对它们进行分页)。但这是一个糟糕(极端)的例子，因为您绝对不应该向客户端应用程序发送 300 万行数据来处理。

最重要的是，您必须在应用程序的规范范围内自行协商这些问题。但就性能而言，我注意到基于适当查询的数据建模往往比查询策略或语法技巧更重要。