Cassandro - obciążenie po stronie klienta równoważenia

Question

Rozważmy Cassandra konfiguracji:

• z pierścienia 6 węzłów A, B, D, E, F, G,
• replikacji czynnik: 3
• partycjonowania: RandomPartitioner
strategia
• zawodowe: SimpleStrategy

Moja test-kolumna jest przechowywana w węźle B i replikowane do węzłów D i E.

Teraz mam wiele procesów java przeczytanie mojego koryta Test-Kolumna Hector API (Thrift) z odczytu CL.ONE

Istnieją dwie możliwości:

1. Hector będzie przekazywać wszystkie połączenia do węzła B, ponieważ B to dane Hectora, które ładuje połączenia odczytu odczytanego przez węzeł B, D i E (master i replikuje). W takim przypadku moja kolumna testowa zostanie załadowana do pamięci podręcznej na każdej instancji Cassandra.

Który to jest 1) lub 2)?

Dzięki i pozdrawiam, Maciej

Answer 1

wierzę, to jest: 3) Cassandra przekazuje wszystkie rozmowy do najbliższego węzła, który żyje, gdzie „bliskość” jest określana przez Snitch obecnie wykorzystywane (zestaw w Cassandry. yaml).

• SimpleSnitch wybiera najbliższy węzeł w token ring.
• AbstractNetworkTopologySnitch i pochodne snitches najpierw próbują wybrać węzły w tym samym stojaku, a następnie węzły w tym samym centrum danych.

Jeśli włączony jest DynamicSnitch, dynamicznie dostosowuje on bliskość węzła zwróconą przez bazowy snitch, zgodnie z ostatnią wydajnością węzłów.

Aby uzyskać więcej informacji, zobacz temat Cassandra ArchitectureInternals w części "Czytaj ścieżkę".

Answer 2

(Wzniosła odpowiedź Theodore'a, ponieważ jest to poprawka). Niektóre dodatkowe szczegóły:

Nic nie robimy po stronie hektora, aby skierować ruch do danego węzła na podstawie klucza (jeszcze). Zostało to określone jako "wybory mediowane przez klienta" w sekcji 6.2 artykułu Amazon Dynamo. Badania wydają się wskazywać, że naprawdę jest to przydatne tylko w przypadku bardzo dużych klastrów poprzez wycinanie przeskoku sieciowego.

Wadą jest powielanie obliczeń haszowania i przeszukiwania partycji na kliencie.