5

それぞれクアッドコア 3GHz プロセッサーと 8GB RAM を搭載した 6 ノードクラスターで DataStax Cassandra 1.2.3 を使用しています。最近、num_tokens を最初に 256 に設定し、次に 128 に設定して、VNodes機能の使用を開始しました。使用しているスキーマのパフォーマンス [書き込み要求数/秒] の低下が見られます。私は主に、幅の広いテーブルとカウンター列ファミリーが混在する正規化されたスキーマを持っています。

  1. VNode を使用してパフォーマンスの低下を観察した人はいますか? VNode をより有効に活用するための既知の最適化手法はありますか?

  2. 特定のハードウェア構成/ノードに対して導出できる num_tokens の最適値はありますか?

  3. また、同種のクラスターを使用しているにもかかわらず、1 つのノードがより多くの負荷を自動的に分担しており、クラスターはほぼバランスが取れていることがわかります。VNode を使用する前に、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 に答える