load_balancing_* セッション設定

これらの設定は system.settings で確認でき、ソースコード から自動生成されています。

分散クエリ処理で使用されるレプリカ選択アルゴリズムを指定します。

ClickHouse では、次のレプリカ選択アルゴリズムをサポートしています。

• ランダム (デフォルト)
• Nearest ホスト名
• ホスト名のレーベンシュタイン距離
• ホスト名の最長共通プレフィックス
• ホスト名の最長共通接尾辞
• In order
• First or random
• ラウンドロビン

関連項目:

• distributed_replica_max_ignored_errors

load_balancing = random

各レプリカごとにエラー数がカウントされます。クエリは、エラー数が最も少ないレプリカに送信され、該当するレプリカが複数ある場合は、そのうちのいずれか 1 つに送信されます。 欠点: サーバーとの近さは考慮されません。また、レプリカごとにデータが異なる場合は、取得されるデータも異なります。

load_balancing = nearest_hostname

各レプリカについてエラー数がカウントされます。5 分ごとに、エラー数は整数除算で 2 で割られます。したがって、エラー数は指数平滑化により直近の時点をより重視して計算されます。エラー数が最小のレプリカが 1 つだけある場合 (つまり、他のレプリカでは最近エラーが発生していた場合) 、クエリはそのレプリカに送られます。最小のエラー数を持つレプリカが複数ある場合は、設定ファイル内のサーバーのホスト名に最も近いホスト名を持つレプリカにクエリが送られます (両方のホスト名のうち短い方の長さまでについて、同じ位置にある異なる文字数に基づきます) 。

たとえば、example01-01-1 と example01-01-2 は 1 文字分だけ異なりますが、example01-01-1 と example01-02-2 は 2 か所異なります。 この方法は単純に見えるかもしれませんが、ネットワークトポロジーに関する外部データを必要とせず、IP アドレスも比較しません。IPv6 アドレスではその比較が複雑になるためです。

したがって、同等のレプリカがある場合は、名前が最も近いものが優先されます。 また、同じサーバーにクエリを送る場合、障害がなければ、分散クエリも同じサーバー群に送られると想定できます。したがって、異なるデータがレプリカに配置されていたとしても、クエリはおおむね同じ結果を返します。

load_balancing = hostname_levenshtein_distance

nearest_hostname と同様ですが、レーベンシュタイン距離に基づいてホスト名を比較します。たとえば:

example-clickhouse-0-0 ample-clickhouse-0-0
1

example-clickhouse-0-0 example-clickhouse-1-10
2

example-clickhouse-0-0 example-clickhouse-12-0
3

load_balancing = hostname_longest_common_prefix

nearest_hostname と同様ですが、ローカルの ホスト名 と最長の共通プレフィックスを持つ ホスト名 のレプリカが優先されます (共通プレフィックスが長いほど優先度が高くなります) 。文字ごとの差分を位置ごとに数える nearest_hostname とは異なり、この戦略では、数値セグメントの長さが異なる ホスト名 があっても誤判定しません。たとえば、ローカルの ホスト名 が sfe301 の場合:

sfe301 sde301
1

sfe301 sfe10101
3

sfe301 sde505
1

ここでは、sfe301 と最長の共通プレフィックス (sfe、長さ 3) を持つため、sfe10101 が優先されます。

共通プレフィックスの長さが同じレプリカは、ランダムに選択されます。特に、どのレプリカもローカルの hostname と共通のプレフィックスを持たない場合 (共通プレフィックス長がすべて 0 の場合) 、この戦略は random とまったく同じように動作します。

load_balancing = hostname_longest_common_suffix

hostname_longest_common_prefix と同様ですが、プレフィックスではなく、最長の共通 接尾辞 を比較します。これは、データセンターの識別子が ホスト名 の接尾辞としてエンコードされている場合に有用です。たとえば、ローカル ホスト名 が et46gtghn.qc.localdomain の場合:

et46gtghn.qc.localdomain tr676ddgh.td.localdomain
12

et46gtghn.qc.localdomain ab999.qc.localdomain
15

ここでは、ab999.qc.localdomain は et46gtghn.qc.localdomain と最長の共通接尾辞 (.qc.localdomain、長さ 15) を持つため、優先されます。

共通接尾辞の長さが同じレプリカは、ランダムに選択されます。特に、ローカルのホスト名と接尾辞を共有するレプリカが 1 つもない場合 (共通接尾辞の長さがすべて 0 の場合) 、この戦略は random とまったく同じように動作します。

load_balancing = in_order

同じ数のエラーがあるレプリカには、設定で指定された順にアクセスされます。 どのレプリカを優先すべきかを正確に把握している場合は、この方法が適しています。

load_balancing = first_or_random

このアルゴリズムは、セット内の最初のレプリカを選択し、そのレプリカが利用できない場合はランダムなレプリカを選択します。クロスレプリケーショントポロジーのセットアップでは有効ですが、それ以外の構成では役に立ちません。

first_or_random アルゴリズムは、in_order アルゴリズムの問題を解決します。in_order では、1 つのレプリカがダウンすると、次のレプリカに負荷が集中して 2 倍になり、残りのレプリカは通常どおりのトラフィック量を処理します。first_or_random アルゴリズムを使用すると、負荷は引き続き利用可能なレプリカ間で均等に分散されます。

設定 load_balancing_first_offset を使用すると、どのレプリカを最初のレプリカとするかを明示的に指定できます。これにより、レプリカ間でクエリ workload を再配分する際の制御性が高まります。

load_balancing = round_robin

このアルゴリズムでは、エラー数が同じレプリカ間でラウンドロビンポリシーを使用します (対象となるのは round_robin ポリシーのクエリのみです) 。

FIRST_OR_RANDOM 負荷分散戦略を使用する場合に、優先的にクエリを送信するレプリカを指定します。