5

我在一个 6 节点集群上使用 DataStax Cassandra 1.2.3，每个集群都有四核 3GHz 处理器和 8GB RAM。最近，我开始使用VNodes功能，首先将 num_tokens 设置为 256，然后设置为 128。我观察到我正在使用的架构的性能 [No.of write requests/sec] 下降。我主要有一个规范化的模式，其中混合了宽表和计数器列系列。

  1. 有没有人观察到使用 VNode 的性能下降？是否有任何已知的优化技术可以更好地利用 VNode？

  2. 对于给定的硬件配置/节点，是否可以得出 num_tokens 的最佳值？

  3. 此外，我看到集群几乎平衡，一个节点自动承担更高的负载份额，尽管我有一个同构集群。在使用 VNodes 之前，我会手动平衡 Murmer3Partitioner 的集群，并且性能很好。

谢谢，VS

4

1 回答 1

8

（这是我帖子的修改版本：http: //cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Why-so-many-vnodes-td7588267.html）

选择每个节点的令牌数（我们称之为 T 和节点数 N）为 256，以便为大多数集群大小的随机令牌分配提供良好的负载平衡。对于小的 T，在大多数情况下随机选择初始标记会导致数据分布不佳。T 越大，分布越接近均匀，概率越大。

此外，对于小 T，当添加一个新节点时，它不会有很多范围可以拆分，因此无法获取均匀的数据切片。

因此，T 应该很大。但是如果它太大，有太多的片来跟踪，所以性能会受到影响。查找哪些密钥位于何处的功能变得更加昂贵，并且处理单个 vnode 的操作（例如修复）变得缓慢。（一个极端的例子是 SELECT * LIMIT 1，当没有数据时必须依次扫描每个 vnode 以搜索单行。这是 O(NT)，即使是非常小的 T 也需要几秒钟才能完成。）

所以选择 256 是一个合理的平衡。我认为大多数用户不会觉得它太慢。拥有超大集群的用户可能需要增加它。

于 2013-06-17T11:13:26.730 回答