Tauschen Cassandra VNodes die Leistung?

Question

Ich benutze DataStax Cassandra 1.2.3 auf einem 6 Knoten Cluster mit jeweils Quad-Core-3GHz-Prozessor und 8 GB RAM. Vor kurzem habe ich begonnen, die Funktion VNodes zu verwenden, indem ich zuerst num_tokens auf 256 und dann auf 128 setze. Ich beobachte eine Leistungsabnahme [Anzahl der Schreibanforderungen/Sek.] Für das Schema, das ich verwende. Ich habe meistens ein normalisiertes Schema mit einer Mischung aus breiten Tabellen & Gegensäulenfamilien.

1. Hat jemand eine Abnahme der Leistung mit den VNodes beobachtet? Gibt es bekannte Optimierungstechniken, um VNodes besser zu nutzen?

2. Gibt es einen optimalen Wert für num_tokens, die für eine bestimmte Hardwarekonfiguration/einen Knoten abgeleitet werden können?

3. Auch ich sehe, dass der Cluster fast ausgeglichen ist mit einem Knoten, der einen höheren Anteil der Last automatisch nimmt, obwohl ich einen homogenen Cluster habe. Vor der Verwendung von VNodes würde ich den Cluster für Murmer3Partitioner manuell ausbalancieren und die Leistung war gut.

Danke, VS

Answer 1

(Dies ist eine modifizierte Version von meinem Beitrag: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Why-so-many-vnodes-td7588267.html)

Die Anzahl von Token pro Knoten (wir es T anrufen und die Anzahl der Knoten N), 256, wurde ausgewählt, um einen guten Lastausgleich für zufällige Tokenzuweisungen für die meisten Clustergrößen zu bieten. Für kleine T ergibt eine zufällige Auswahl von anfänglichen Token in den meisten Fällen eine schlechte Verteilung von Daten. Je größer T ist, desto gleichmäßiger wird die Verteilung mit zunehmender Wahrscheinlichkeit.

Auch für kleine T, wenn ein neuer Knoten hinzugefügt wird, wird es nicht viele Bereiche zu teilen haben, so dass nicht in der Lage sein wird, ein gerades Stück der Daten zu nehmen.

Aus diesem Grund sollte T groß sein. Aber wenn es zu groß ist, gibt es zu viele Slices, um die Performance zu verfolgen. Die Funktion, um zu finden, welche Schlüssel wo wohnen, wird teurer und Operationen, die sich mit einzelnen V-Knoten befassen, z. Reparatur wird langsam. (Ein extremes Beispiel ist SELECT * LIMIT 1, das, wenn keine Daten vorhanden sind, jeden Vnode der Reihe nach nach einer einzelnen Zeile scannen muss. Dies ist O (NT) und für sogar ziemlich kleine T dauert Sekunden.)

Also 256 wurde gewählt, um ein vernünftiges Gleichgewicht zu sein. Ich glaube nicht, dass die meisten Benutzer es zu langsam finden werden; Benutzer mit extrem großen Clustern müssen sie möglicherweise erhöhen.