Czy Cassandra VNodes osiąga wyniki w handlu?

Question

Używam DataStax Cassandra 1.2.3 na klastrze z 6 węzłami, z których każdy ma czterordzeniowy procesor 3GHz i 8 GB pamięci RAM. Ostatnio zacząłem używać funkcji VNodes, ustawiając num_tokens na 256 najpierw, a następnie na 128. Obserwuję spadek wydajności [liczba żądań zapisu/sek] dla schematu, którego używam. W większości mam znormalizowany schemat z mieszanką szerokich tabel & rodzin liczników kolumn.

1. Czy ktoś zaobserwował spadek wydajności przy użyciu VNodes? Czy są jakieś znane techniki optymalizacji, aby lepiej wykorzystać VNodes?

2. Czy istnieje optymalna wartość dla num_tokens, którą można uzyskać dla danej konfiguracji sprzętowej/węzła?

3. Ponadto widzę, że skupienie jest prawie zbalansowane, ponieważ jeden węzeł pobiera większą część obciążenia automatycznie, chociaż mam jednorodną grupę. Przed użyciem VNodes ręcznie wyrównałem klastry dla Murmer3Partitioner, a wydajność była dobra.

Dzięki VS

Answer 1

(Jest to zmodyfikowana wersja mojego postu: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Why-so-many-vnodes-td7588267.html)

liczba żetonów na węzeł (nazwijmy go T i liczby węzłów N), 256, wybrano tak, aby zapewnić dobre równoważenie obciążenia dla losowych zadań tokena dla większości rozmiarów klastra. W przypadku małego T losowy wybór początkowych tokenów w większości przypadków spowoduje słabą dystrybucję danych. Im większe T, tym bliższe jednorodności będzie rozkład z rosnącym prawdopodobieństwem.

Ponadto, dla małego T, po dodaniu nowego węzła, nie będzie wielu zakresów do podziału, więc nie będzie w stanie pobrać równego kawałka danych.

Z tego powodu T powinno być duże. Ale jeśli jest zbyt duży, jest zbyt wiele plasterków, aby śledzić, więc wydajność zostanie osiągnięta. Funkcja sprawdzania, które klucze są aktywne, gdzie jest droższa, oraz operacje dotyczące poszczególnych vnodes, np. naprawa staje się powolna. (Skrajnym przykładem jest SELECT * LIMIT 1, który, gdy nie ma danych ma skanować każdy vnode z kolei w poszukiwaniu jednym rzędzie. Jest to O (NT) i nawet niewielka T zajmuje kilka sekund, aby zakończyć.)

Więc 256 zostało wybrane jako rozsądna równowaga. Nie sądzę, że większość użytkowników uzna to za zbyt powolne; użytkownicy z bardzo dużymi klastrami mogą potrzebować go zwiększyć.