选择 Cassandra 中的所有性能

Question

我目前正在使用 DB2 并计划使用 cassandra，因为据我所知，cassandra 的读取性能高于 RDBMS。

这可能是一个愚蠢的问题，但我进行了比较 DB2 和 Cassandra 之间的读取性能的实验。

使用 500 万条记录和相同的表架构进行测试。 查询SELECT * FROM customer。 DB2 使用 25-30 秒，Cassandra 使用 40-50 秒。

但是使用 2-3s 查询 where 条件 SELECT * FROM customer WHERE cusId IN (100,200,300,400,500) DB2 和使用 3-5ms 的 Cassandra。

为什么 Cassandra 在 where 条件下比 DB2 快？所以我无法用SELECT * FROM customer 证明哪个数据库更大，对吧？

仅供参考。

Cassandra：RF=3 和 CL=1，3 个节点，每个节点在 3 台计算机上运行 (VM-Ubuntu)

DB2：在 Windows 上运行

表架构：

cusId int PRIMARY KEY, cusName varchar

Answer 1

如果您查看 Cassandra 擅长解决的问题类型，那么 为什么 未绑定（“全选”）查询很糟糕的原因就很明显了。

Cassandra 被设计成一个分布式数据库。在许多 Cassandra 存储模式中，节点的数量大于复制因子（即，并非所有节点都包含所有数据）。因此，限制网络跳数对于建模高性能查询变得至关重要。 Cassandra 在特定查询（利用分区/集群键结构）方面表现出色，因为它可以快速定位主要负责数据的节点。

未绑定查询（A.K.A. 多键查询）会产生额外的网络时间，因为需要协调器节点。所以一个节点充当协调者，查询所有其他节点，整理数据，并返回结果集。指定 WHERE 子句（至少带有一个分区键）并在使用“令牌感知”负载平衡策略时表现良好，原因有两个：

1. 不需要协调节点。
2. 查询主要负责范围的节点，在单个网络跃点中返回结果集。

tl;dr;

使用未绑定的查询查询 Cassandra 会导致它产生大量额外的处理和网络时间，而如果查询被指定了 WHERE 子句，则通常不需要这样做。

Answer 2

即使是像无条件范围查询这样麻烦的查询，40-50 秒对于 C* 来说也是相当极端的。协调员是否通过协调击中 GC？能否包含用于测试的代码？

当您创建 select * 与数百万条记录时，它不会一次获取所有记录，它会一次获取 fetchSize。如果您只是迭代它，即使您最初使用了 executeAsync，迭代器实际上也会阻塞。这意味着每 10k（默认）记录，它将发出一个您将阻止的新查询。仅从网络的角度来看，这种序列化的性质需要时间。 http://docs.datastax.com/en/developer/java-driver/3.1/manual/async/#async-paging 解释了如何以非阻塞方式进行操作。您可以使用它在处理当前页面时开始获取下一页，这会有所帮助。

减少限制或获取大小也可能有所帮助，因为协调器可能会一次遍历一个令牌范围（并行性在这里是可能的，但它的启发式并不完美），直到它读取足够多。如果它必须遍历太多节点来响应它会很慢，这就是为什么空表在执行select * 时可能会非常慢，它可能会连续遍历每个副本集。对于 256 个 vnode，这可能非常糟糕。