ポイント: Cassandraはトークンを使用して、プライマリキーのハッシュ値を基にデータをノード間で均等に配布します。適切なトークン管理は、システムがスケールする際の作業負荷の不均衡を防ぐために重要です。
- トークンはCassandraクラスター内のデータ配置を決定します。
- 不適切なトークン配布はサーバーの不均衡を引き起こす可能性があります。
Cassandraはトークンに基づいてデータを配布します。トークンはプライマリキーのハッシュ値です。ノードをCassandraに追加すると、各ノードにトークン範囲を割り当てるか、Cassandraにそれを行わせます。その後、Cassandraにデータを追加すると、トークンを計算し、それを使用して新しいデータをどのサーバー（ノード）に保存するかを判断します。これは開始時には問題ありません。しかし、システムが成長し、ノードをリング（ノードのコレクション）に追加すると、一つのサーバーに他のサーバーよりも多くのデータが集中することがあるため、作業負荷の不均衡が生じます。したがって、これをどう構成するかを考えることが必要です。
Cassandraのトークンの配布方法
トークンを計算するアルゴリズムは、データが均等に配布されるように設計されています。トークン/ノードの割り当てをcassandra.yamlで自分で構成するか、Cassandraに最良の推定を行わせることができます。例として、次のテーブルを考えてみましょう：
CREATE TABLE customers.customers (
name text PRIMARY KEY,
credit int
)
そしてこれらの三つのレコード：
select token(name), name from customers.customers;
system.token(name) | name
----------------------+----------------
-1595003126634288162 | Book Store
2201572791825907709 | Bok Store
6005990370378710037 | Hardware Store
nodetoolコマンドを使用して、system.token() CQLコマンドでトークンを表示することにより、これらのレコードがどこに保存されているかを確認できます。nodetoolのフォーマットはnodetool getendpoints keyspace table tokenです。以下のIPアドレスからわかるように、2台のサーバーのクラスターではレコードが両方に分配されています。
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
不均等なデータ配布の問題
さて、これについて考えてみると、これはクラスターを最初に設定したときには問題ありません。しかし、システムが成長すると、Cassandraは一つのノードにデータを蓄積し、他のノードを過小利用することがあります。さらに、既存のデータを新しいノードに移動する方法にも問題があります。それではどうすればいいのか？ノードにトークンを割り当てるために使用できる3つの異なるアルゴリズムがあります。cassandra.yamlのMurmur3Partitionerでは、allocate_tokens_for_keyspace. を設定できます。これを使用すると、num_tokensを使ってトークンのランダムな配分をオーバーライドできます（他のパーティショナーアルゴリズムを意味します）。これにより、新しいノードが既存のノードからより多くのデータを取得し、過剰/過少利用の問題を軽減します。これは、他のノードのデータ負荷に基づいてノードへの範囲の割り当てが動的にシフトすることを可能にします。しかし、既存のデータを新しいノードに移動しないため、データが均等に分散されるまでには時間がかかります。num_tokens はノードを仮想ノードに分割することを意味します。デフォルトは256です。次の投稿では、このアルゴリズムについてより詳細に説明し、環境に合わせて調整する方法を説明します。
Cassandraガイド
これらの投稿は私自身の意見であり、BMCの立場、戦略、または意見を必ずしも表すものではありません。