max_bytes_before_external_distinct
DISTINCT データをディスクにスピルするための、クエリメモリのバイト単位のしきい値です。実際のメモリ使用量は
このしきい値を超える場合があります。
0 を指定すると、このしきい値は無効になります。max_bytes_ratio_before_external_distinct でも
しきい値が指定されている場合は、小さい方が使用されます。スピルを無効にするには、両方の設定を 0 に設定してください。
外部メモリでの DISTINCT を参照してください。
max_bytes_before_external_group_by
Cloud でのデフォルト値: レプリカあたりのメモリ量の半分。GROUP BY 句を外部メモリで実行するかどうかを制御します。
(外部メモリでの GROUP BY を参照)
設定可能な値:
- 1 回の GROUP BY 操作で使用できる RAM の最大量 (バイト単位) 。
0— 外部メモリでのGROUP BYは無効。
GROUP BY 操作中のメモリ使用量がこのしきい値 (バイト単位) を超えると、
「外部集約」モードが有効になり、中間データがディスクに書き出されます。推奨値は、利用可能なシステムメモリの半分です。
max_bytes_before_external_join
0 以外の値に設定すると、右側のデータがこのバイト数を超えると、ディスクへのスピルを有効にするためにハッシュ結合は自動的に Grace Hash Join に変換されます。max_bytes_ratio_before_external_join と合わせて、これはハッシュベースのすべての join_algorithm に対するしきい値ベースのスピルのトリガーであり、grace_hash も含まれます。grace_hash では、この 2 つのいずれかが 0 以外である必要があります。0 以外のしきい値によって結合がスピル可能になると、enable_adaptive_memory_spill_scheduler により、しきい値に達する前でもメモリ逼迫時に強制的にスピルさせることができます。両方の設定が 0 の場合、結合はスピルしないため、スケジューラーがトリガーする対象がありません。例外は legacy_join_size_limits_trigger_spilling です。これを有効にすると、単独の grace_hash は両方を無視し、代わりに max_rows_in_join / max_bytes_in_join に基づいてスピルします。0 (デフォルト) に設定すると、この絶対バイトしきい値は無効になりますが、max_bytes_ratio_before_external_join (デフォルトは 0.5) によって自動スピルが引き続き発生する可能性があります。自動スピルを完全に無効にするには、両方を 0 に設定してください。これにより、JOIN 最適化による順序どおりの読み取りは行えなくなります。
max_bytes_before_external_sort
Cloud でのデフォルト値: レプリカあたりのメモリ量の半分。ORDER BY 句を外部メモリで実行するかどうかを設定します。ORDER BY の実装の詳細を参照してください。
ORDER BY 操作中のメモリ使用量がこのしきい値をバイト単位で超えると、「外部ソート」モード (中間データをディスクに書き出す) が有効になります。
設定可能な値:
- 1 回の ORDER BY 操作で使用できる RAM の最大量 (バイト単位) 。 推奨値は、使用可能なシステムメモリの半分です
0— 外部メモリでのORDER BYは無効です。
max_bytes_before_remerge_sort
ORDER BY と LIMIT を使用する場合、メモリ使用量が指定したしきい値を超えると、最終マージの前にブロックの追加マージを行い、上位 LIMIT 行のみを保持します。max_bytes_for_lazy_final
遅延 FINAL 最適化で使用される Set の最大バイト数です。これを超えると、通常の FINAL にフォールバックします。max_bytes_in_distinct
DISTINCT の使用時にハッシュテーブルが使用する、メモリ内の状態の最大バイト数 (非圧縮バイト数) 。max_bytes_in_join
テーブルの join 時に使用される右側のデータ構造 (通常はハッシュ テーブル) の最大サイズ (バイト単位) です。 この設定は、SELECT … JOIN 操作と Join テーブルエンジン に適用されます。 1 つのクエリに複数の join が含まれる場合、ClickHouse は各 中間結果に対してこの設定をチェックします。これはハッシュベースのすべてのjoin_algorithm に対するハードな上限であり、上限に
達するとクエリは
join_overflow_mode に従って例外をスローするか処理を中断します。
この設定によって join がディスクへスピルすることはありません。その判断は
max_bytes_before_external_join
および
max_bytes_ratio_before_external_join
に委ねられています。
これはトリガーではなく上限であるため、スピルのしきい値以下に設定すると、
通常は join がスピルする前にクエリが失敗します。ただし、join がスピル可能であり
enable_adaptive_memory_spill_scheduler が先にスピルを強制する場合や、
legacy_join_size_limits_trigger_spilling によって、すでにディスク上で実行されている join のパーツに対して
この上限が再びスピルのトリガーとして機能する場合を除きます。
この上限はハッシュテーブルが保持している内容をカウントするため、スピルした join では
右側を読み取っている最中ではなく各バケットがロードされる時点で上限に達します。つまり、
インメモリのハッシュ結合よりも多くの右側のデータを読み取ってから停止する可能性があります。
設定可能な値:
- 正の整数。
- 0 — メモリ制御は無効です。
max_bytes_in_set
サブクエリから作成された IN 句内のSetで使用される、非圧縮データの最大バイト数。max_bytes_ratio_before_external_distinct
実行開始時に外部DISTINCT のしきい値を計算するために使用する、利用可能なサーバーまたはユーザーのメモリの割合です。
たとえば、0.5 は利用可能なメモリの半分を使用します。
値は 0 以上かつ 1 未満である必要があります。0 を指定すると、このしきい値は無効になります。適用可能な
サーバーまたはユーザーのメモリ制限がない場合、この比率は効果を持ちません。
max_memory_usage はこの計算に影響しません。その制限に対するスピルを設定するには、
追加のメモリ使用量の余地を残して max_bytes_before_external_distinct を使用します。
max_bytes_ratio_before_external_group_by
GROUP BY に使用できる利用可能メモリの割合です。しきい値に達すると、
集約には外部メモリが使用されます。
たとえば 0.6 に設定すると、GROUP BY は実行開始時点で利用可能メモリ
(server/user/merges に割り当てられたメモリ) の 60% まで使用でき、
それ以降は外部集約を使用し始めます。
max_bytes_ratio_before_external_join
JOIN に使用できる利用可能メモリの比率です。この値に達すると、ハッシュ結合は Grace Hash Join に変換され、右側のデータがディスクにスピルされます。
たとえば 0.6 に設定すると、JOIN は実行開始時に、右側のハッシュテーブルに対して利用可能メモリ (server/user/merges 用) の 60% まで使用できます。その後はディスクへのスピルが開始されます。
max_bytes_before_external_join と max_bytes_ratio_before_external_join の両方が設定されている場合は、結果として小さい方のしきい値が使用されます。比率が 0 の場合は、絶対値の設定のみが適用されます。
一時データパスが設定されていれば、grace_hash を含むすべてのハッシュベースの join_algorithm に対して効果があります。
max_bytes_ratio_before_external_sort
ORDER BY に使用できる利用可能メモリの比率です。この値に達すると、外部ソートが使用されます。
たとえば 0.6 に設定すると、ORDER BY は実行開始時に利用可能メモリ (server/user/merges) の 60% まで使用できます。それを超えると、外部ソートの使用が開始されます。
なお、max_bytes_before_external_sort は引き続き適用されるため、ディスクへのスピルが行われるのは、ソート対象のブロックが max_bytes_before_external_sort より大きい場合だけです。
max_bytes_to_read
クエリの実行時に、テーブルから読み取れる最大バイト数 (非圧縮データ) です。 この制限は、処理されるデータの各 chunk ごとにチェックされ、最も深いテーブル式にのみ適用されます。リモートサーバーから読み取る場合は、リモートサーバー上でのみチェックされます。max_bytes_to_read_leaf
分散クエリの実行時に、リーフノード上のローカル テーブルから読み取れるバイト数 (非圧縮データ) の最大値です。分散クエリ では各分片 (leaf) に対して複数のサブクエリを発行できますが、この制限が チェックされるのはリーフノードでの読み取り段階のみであり、ルートノードでの結果の マージ段階では無視されます。 たとえば、あるクラスターが 2 つの分片で構成され、各分片に 100 バイトのデータを持つテーブルが含まれているとします。両方のテーブルから すべてのデータを読み取る分散クエリは、max_bytes_to_read=150 が設定されていると、
合計で 200 バイトになるため失敗します。一方、max_bytes_to_read_leaf=150 を
設定したクエリは成功します。これは、リーフノードでは最大 100 バイトしか
読み取られないためです。
この制限は、処理されるデータの各 chunk ごとにチェックされます。
この設定は、
prefer_localhost_replica=1 と併用すると不安定です。max_bytes_to_sort
ソート前に処理できる最大バイト数です。ORDER BY 操作で、指定した量を超える 非圧縮バイト数を処理する必要がある場合の動作は、sort_overflow_mode によって
決まります。既定では throw に設定されています。