Auf einen Blick: Cassandra verwendet Tokens, das sind gehashte Werte von Primärschlüsseln, um Daten gleichmäßig über die Knoten zu verteilen. Eine ordnungsgemäße Tokenverwaltung ist entscheidend, um Arbeitslastungleichgewichte beim Systemskalieren zu vermeiden.
- Token bestimmen die Datenplatzierung in einem Cassandra-Cluster.
- Eine unsachgemäße Tokenverteilung kann zu Serverungleichgewichten führen.
Cassandra verteilt Daten basierend auf Tokens. Ein Token ist der gehashte Wert des Primärschlüssels. Wenn du Knoten zu Cassandra hinzufügst, weist du jedem Knoten einen Tokenbereich zu oder lässt Cassandra das für dich übernehmen. Wenn du dann Daten zu Cassandra hinzufügst, berechnet es das Token und verwendet das, um herauszufinden, auf welchem Server (Knoten) die neuen Daten gespeichert werden. Das funktioniert am Anfang einwandfrei. Aber wie wir sehen werden, kann es dazu führen, dass ein Server viel mehr Daten hat als die anderen, wenn dein System wächst und du Knoten zum Ring (also zur Sammlung der Knoten) hinzufügst, was zu einem Ungleichgewicht der Arbeitsbelastung führt. Deshalb ist es notwendig, darüber nachzudenken, wie das konfiguriert werden sollte
Wie Cassandra Token verteilt
Die Algorithmen, die das Token berechnen, sind so konzipiert, dass sie hin und her wechseln, sodass die Daten gleichmäßig verteilt sind. Sie können die Token-/Knotenzuweisung selbst in cassandra.yaml konfigurieren oder Cassandra eine Best-Guess-Schätzung machen lassen. Zur Veranschaulichung: Angenommen, wir haben diese Tabelle:
CREATE TABLE customers.customers (
name text PRIMARY KEY,
credit int
)
und diese drei Platten:
select token(name), name from customers.customers;
system.token(name) | name
----------------------+----------------
-1595003126634288162 | Book Store
2201572791825907709 | Bok Store
6005990370378710037 | Hardware Store
Wir können sehen, wo jeder dieser Datensätze gespeichert ist, indem wir den Nodetool-Befehl verwenden und das Token mit dem System.token() CQL-Befehl anzeigen. Das Format für nodetool ist nodetool getendpoints keyspace-Tabellen-Token. Wie wir an den untenstehenden IP-Adressen sehen können, sind in unserem Cluster von zwei Servern die Datensätze auf beide verteilt.
nodetool getendpoints customers customers -1595003126634288162
172.31.47.43
nodetool getendpoints customers customers 2201572791825907709
172.31.46.15
nodetool getendpoints customers customers 6005990370378710037
172.31.47.43
Das Problem der ungleichmäßigen Datenverteilung
Wenn man darüber nachdenkt, funktioniert das beim ersten Aufbau des Clusters gut. Aber wenn Ihr System wächst, kann Cassandra Daten auf einem Knoten anhäufen und andere ungenutzt lassen. Außerdem gibt es das Problem, wie man bestehende Daten auf neue Knoten verlagert. Was macht man also? Es gibt drei verschiedene Algorithmen, mit denen man Token an Knoten zuweisen kann. Murmur3Partitioner in cassandra.yaml ermöglicht es, allocate_tokens_for_keyspace zu setzen . Das kann man mit num_tokens nutzen, um die Zufallsverteilung der Token (also die anderen Partitionier-Algorithmen) zu überschreiben. So können neue Knoten mehr Daten von bestehenden Knoten übernehmen und so das Über-/Unterauslastungsproblem verringern. Dies geschieht, indem die Zuweisung von Bereichen an Knoten dynamisch basierend auf der Datenlast in den anderen Knoten verschiebt wird. Da bestehende Daten jedoch nicht auf die neuen Knoten übertragen werden, dauert es eine Weile, bis die Daten gleichmäßig verteilt sind. num_tokens bedeutet die Aufteilung eines Knotens in einen virtuellen Knoten. Der Standard ist 256. Im nächsten Beitrag erklären wir diesen Algorithmus ausführlicher, damit Sie herausfinden können, wie Sie ihn für Ihre Umgebung abstimmen können.
Cassandra-Führer
- Was ist Cassandra? Schlüsselmerkmale und Vorteile
- Wie man einen Cassandra-Cluster einrichtet
- Cassandra SQL Batches and Maps
- Stresstests und Leistungsabstimmung Apache Cassandra
- JSON mit Cassandra verwenden
- Konfiguration von Apache Cassandra Data Consistency
- Verwendung von Tokens zur Verteilung von Cassandra-Daten
- Partitionsschlüssel vs. zusammengesetzter Schlüssel vs. Clustering von Spalten in Cassandra
Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.