> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# min_* 세션 설정

> 자동 생성된 min_* 그룹의 ClickHouse 세션 설정입니다.

export const SettingsInfoBlock = ({type, default_value, changeable_without_restart}) => {
  return <div className="not-prose" style={{
    display: "flex",
    flexWrap: "wrap",
    alignItems: "baseline",
    columnGap: "0.5rem",
    rowGap: "0.125rem",
    margin: "0.375rem 0",
    fontSize: "0.8125rem",
    lineHeight: "1.125rem"
  }}>
      <div style={{
    fontWeight: 600,
    opacity: 0.72
  }}>유형</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{type}</div>
      <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>기본값</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          재시작 없이 변경 가능
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

이 설정은 [system.settings](/docs/ko/reference/system-tables/settings)에서 확인할 수 있으며 [소스 코드](https://github.com/ClickHouse/ClickHouse/blob/master/src/Core/Settings.cpp)에서 자동 생성됩니다.

<div id="min_chunk_bytes_for_parallel_parsing">
  ## min\_chunk\_bytes\_for\_parallel\_parsing
</div>

<SettingsInfoBlock type="NonZeroUInt64" default_value="10485760" />

* 유형: 부호 없는 정수
* 기본값: 1 MiB

각 스레드가 병렬로 파싱할 바이트 단위의 최소 청크 크기입니다.

<div id="min_compress_block_size">
  ## min\_compress\_block\_size
</div>

<SettingsInfoBlock type="UInt64" default_value="65536" />

[MergeTree](/docs/ko/reference/engines/table-engines/mergetree-family/mergetree) 테이블에 적용됩니다. 쿼리 처리 시 지연 시간을 줄이기 위해, 크기가 `min_compress_block_size` 이상이면 다음 마크를 기록할 때 블록을 압축합니다. 기본값은 65,536입니다.

압축되지 않은 데이터가 `max_compress_block_size`보다 작은 경우, 실제 블록 크기는 이 값보다 작아지지 않으며 한 마크에 해당하는 데이터 양보다도 작아지지 않습니다.

예시를 살펴보겠습니다. 테이블 생성 시 `index_granularity`를 8192로 설정했다고 가정합니다.

UInt32 유형의 컬럼(값당 4바이트)을 기록한다고 가정해 보겠습니다. 8192개 행을 기록하면 총 데이터 크기는 32KB가 됩니다. min\_compress\_block\_size = 65,536이므로 압축 블록은 마크 2개마다 하나씩 생성됩니다.

String 유형의 URL 컬럼(값당 평균 크기 60바이트)을 기록한다고 가정해 보겠습니다. 8192개 행을 기록하면 평균적으로 500KB에 약간 못 미치는 데이터가 됩니다. 이는 65,536보다 크므로 압축 블록은 각 마크마다 하나씩 생성됩니다. 이 경우 디스크에서 단일 마크 범위의 데이터를 읽을 때는 추가 데이터가 압축 해제되지 않습니다.

<Note>
  이 설정은 전문가 수준의 설정이므로 ClickHouse를 막 사용하기 시작한 경우에는 변경하지 않는 것이 좋습니다.
</Note>

<div id="min_filtered_ratio_for_lazy_final">
  ## min\_filtered\_ratio\_for\_lazy\_final
</div>

<SettingsInfoBlock type="Float" default_value="0.5" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "26.4"},{"label": "0.5"},{"label": "지연 실행 FINAL 최적화를 계속 진행하기 위해 필터링되어야 하는 마크의 최소 비율에 대한 새로운 설정"}]}]} />

지연 실행 FINAL 최적화에서 인덱스 분석을 통해 필터링되는 마크의 최소 비율입니다. 필터링된 마크의 비율이 이 값보다 낮으면 일반 FINAL로 대체됩니다. 값이 0이면 이 검사는 비활성화됩니다.

<div id="min_hit_rate_to_use_consecutive_keys_optimization">
  ## min\_hit\_rate\_to\_use\_consecutive\_keys\_optimization
</div>

<SettingsInfoBlock type="Float" default_value="0.5" />

집계에서 연속 키 최적화에 사용하는 캐시를 활성화된 상태로 유지하기 위한 최소 적중률

<div id="min_os_cpu_wait_time_ratio_to_throw">
  ## min\_os\_cpu\_wait\_time\_ratio\_to\_throw
</div>

<SettingsInfoBlock type="Float" default_value="0" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.5"},{"label": "0"},{"label": "설정 값이 변경되었으며 25.4에 백포트되었습니다"}]}, {"id": "row-2","items": [{"label": "25.4"},{"label": "0"},{"label": "새로운 설정"}]}]} />

쿼리 거부를 판단할 때 고려하는 OS CPU 대기 시간(OSCPUWaitMicroseconds 메트릭)과 CPU 사용 시간(OSCPUVirtualTimeMicroseconds 메트릭) 사이의 최소 비율입니다. 확률 계산에는 최소 비율과 최대 비율 사이의 선형 보간을 사용하며, 이 지점에서 확률은 0입니다.

<div id="min_outstreams_per_resize_after_split">
  ## min\_outstreams\_per\_resize\_after\_split
</div>

<SettingsInfoBlock type="UInt64" default_value="24" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.6"},{"label": "24"},{"label": "새 설정입니다."}]}]} />

파이프라인 생성 중 분할 작업이 수행된 후 `Resize` 또는 `StrictResize` 프로세서의 최소 출력 스트림 수를 지정합니다. 결과 스트림 수가 이 값보다 적으면 분할 작업은 수행되지 않습니다.

<div id="what-is-a-resize-node">
  ### Resize Node란 무엇입니까
</div>

`Resize` 노드는 쿼리 파이프라인에서 파이프라인을 통해 흐르는 데이터 스트림 수를 조정하는 프로세서입니다. 여러 스레드나 프로세서에 작업 부하를 고르게 분산하기 위해 스트림 수를 늘리거나 줄일 수 있습니다. 예를 들어, 쿼리에 더 높은 병렬성이 필요하면 `Resize` 노드는 단일 스트림을 여러 스트림으로 분할할 수 있습니다. 반대로 여러 스트림을 더 적은 수의 스트림으로 머지하여 데이터 처리를 통합할 수도 있습니다.

`Resize` 노드는 데이터 블록의 구조를 유지하면서 데이터가 각 스트림에 고르게 분산되도록 합니다. 이는 리소스 활용도를 최적화하고 쿼리 성능을 향상하는 데 도움이 됩니다.

<div id="why-the-resize-node-needs-to-be-split">
  ### Resize 노드를 분할해야 하는 이유
</div>

파이프라인 실행 중에는 중앙 허브 역할을 하는 `Resize` 노드의 ExecutingGraph::Node::status\_mutex에서 경합이 심하게 발생하며, 특히 코어 수가 많은 환경에서 더욱 두드러집니다. 이러한 경합은 다음과 같은 문제를 초래합니다.

1. ExecutingGraph::updateNode의 지연 시간이 증가하여 쿼리 성능에 직접적인 영향을 줍니다.
2. 스핀 잠금 경합(native\_queued\_spin\_lock\_slowpath)으로 인해 과도한 CPU 사이클이 낭비되어 효율이 저하됩니다.
3. CPU 활용률이 낮아져 병렬성과 처리량이 제한됩니다.

<div id="how-the-resize-node-gets-split">
  ### Resize 노드가 분할되는 방식
</div>

1. 분할이 가능한지 확인하기 위해 출력 스트림 수를 검사합니다. 즉, 각 분할 프로세서의 출력 스트림 수가 `min_outstreams_per_resize_after_split` 임계값 이상이어야 합니다.
2. `Resize` 노드는 더 작은 `Resize` 노드들로 나뉘며, 각 노드는 동일한 수의 포트를 갖고 입력 및 출력 스트림의 부분 집합을 처리합니다.
3. 각 그룹이 독립적으로 처리되므로 잠금 경합이 줄어듭니다.

<div id="splitting-resize-node-with-arbitrary-inputsoutputs">
  ### 임의의 입력/출력을 갖는 Resize 노드 분할
</div>

경우에 따라 입력/출력 수가 분할된 `Resize` 노드 수로 나누어떨어지지 않으면, 일부 입력은 `NullSource`에 연결되고 일부 출력은 `NullSink`에 연결됩니다. 이렇게 하면 전체 데이터 흐름에 영향을 주지 않고 분할할 수 있습니다.

<div id="purpose-of-the-setting">
  ### 설정의 목적
</div>

`min_outstreams_per_resize_after_split` 설정은 `Resize` 노드 분할이 실질적인 의미를 갖도록 하고, 너무 적은 수의 스트림이 생성되어 병렬 처리가 비효율적으로 이루어지는 상황을 방지합니다. 출력 스트림의 최소 개수를 강제함으로써 이 설정은 병렬성과 오버헤드 간의 균형을 유지하는 데 도움이 되며, 스트림 분할 및 병합이 포함된 시나리오에서 쿼리 실행을 최적화합니다.

<div id="disabling-the-setting">
  ### 설정 비활성화
</div>

`Resize` 노드의 split을 비활성화하려면 이 설정을 0으로 설정합니다. 그러면 파이프라인 생성 중 `Resize` 노드가 분할되지 않아 더 작은 노드로 나뉘지 않고 원래 구조를 유지합니다.

<div id="min_table_rows_to_use_projection_index">
  ## min\_table\_rows\_to\_use\_projection\_index
</div>

<SettingsInfoBlock type="UInt64" default_value="1000000" />

<VersionHistory rows={[{"id": "row-1","items": [{"label": "25.11"},{"label": "1000000"},{"label": "새로운 설정"}]}]} />

테이블에서 읽을 것으로 예상되는 행 수가 이 임계값 이상이면, ClickHouse는 쿼리 실행 중 프로젝션 인덱스를 사용하려고 시도합니다.