选择Cassandra中的所有性能

Question

我目前正在使用DB2，并计划使用cassandra，因为据我所知，cassandra的读取性能优于关系数据库管理系统。

也许这是一个愚蠢的问题，但我有一个实验，比较DB2和卡桑德拉的阅读性能。

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

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

为什么卡桑德拉比DB2快，条件在哪里？所以我无法证明哪个数据库使用SELECT * FROM customer更大，对吧？

仅供参考。

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

DB2:在windows上运行

表模式：

cusId int PRIMARY KEY, cusName varchar

Answer 1

如果您查看Cassandra擅长解决的问题类型，那么非绑定("Select“)查询失败的原因就很明显了。

Cassandra被设计成一个分布式数据库。在许多Cassandra存储模式中，节点数大于复制因子(也就是说，并非所有节点都包含所有数据)。因此，限制网络跳数成为建模高性能查询的关键.Cassandra能够很好地处理特定的查询(使用分区/集群密钥结构)，因为它可以快速定位主要负责数据的节点。

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

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

tl;dr;

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

Answer 2

即使是像无条件范围查询那样麻烦的查询，40-50对于C*来说还是相当极端的。协调者是否以协调方式打击GCs？可以包含用于测试的代码吗？

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

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