Skip to main content
이러한 설정은 system.settings에서 확인할 수 있으며, 소스 코드로부터 자동으로 생성됩니다.

load_balancing

분산 쿼리 처리에서 레플리카를 선택할 때 사용할 알고리즘을 지정합니다. ClickHouse는 다음과 같은 레플리카 선택 알고리즘을 지원합니다: 관련 항목:

Random (기본 설정)

각 레플리카의 오류 수를 계산합니다. 쿼리는 오류가 가장 적은 레플리카로 전송되며, 이런 레플리카가 여러 개이면 그중 아무 레플리카로 전송됩니다. 단점: 서버와의 근접성은 고려되지 않습니다. 또한 레플리카마다 데이터가 다르면 반환되는 데이터도 달라집니다.

가장 유사한 호스트명

각 레플리카별로 오류 수를 계산합니다. 5분마다 오류 수를 2로 정수 나눗셈합니다. 따라서 최근 시점의 오류 수는 지수 평활화 방식으로 계산됩니다. 오류 수가 가장 적은 레플리카가 하나만 있으면(즉, 다른 레플리카에서는 최근에 오류가 발생한 경우) 해당 레플리카로 쿼리를 보냅니다. 동일한 최소 오류 수를 가진 레플리카가 여러 개이면, 구성 파일(config file)에 있는 server의 호스트명과 가장 유사한 호스트명을 가진 레플리카로 쿼리를 보냅니다(두 호스트명의 최소 length까지 동일한 위치에서 다른 문자의 수를 기준으로 함). 예를 들어 example01-01-1과 example01-01-2는 한 위치만 다르고, example01-01-1과 example01-02-2는 두 위치에서 다릅니다. 이 메서드는 다소 단순해 보일 수 있지만, 네트워크 토폴로지에 대한 external 데이터가 필요하지 않고, IP 주소도 비교하지 않습니다. IPv6 address에서는 이를 비교하는 작업이 복잡하기 때문입니다. 따라서 동등한 레플리카가 있으면 이름이 가장 가까운 레플리카를 우선 선택합니다. 또한 동일한 server로 쿼리를 보내는 경우 장애가 없다면, 분산 쿼리(distributed query)도 동일한 server들로 전달된다고 가정할 수 있습니다. 따라서 레플리카마다 서로 다른 데이터가 배치되어 있더라도, 쿼리는 대체로 동일한 결과를 반환합니다.

호스트명 Levenshtein 거리

nearest_hostname와 유사하지만, 호스트명을 Levenshtein 거리 기준으로 비교합니다. 예시는 다음과 같습니다:

호스트명의 최장 공통 접두사

nearest_hostname와 비슷하지만, 로컬 호스트명과 가장 긴 공통 접두사를 가진 레플리카를 우선 선택합니다(공통 접두사가 길수록 우선순위가 높아집니다). 문자 위치별로 서로 다른 문자를 세는 nearest_hostname와 달리, 이 전략은 숫자 세그먼트의 길이가 서로 다른 호스트명 때문에 혼동되지 않습니다. 예를 들어, 로컬 호스트명이 sfe301인 경우:
여기서는 sfe10101sfe301과 가장 긴 공통 접두사(sfe, 길이 3)를 가지므로 우선적으로 선택됩니다. 공통 접두사 길이가 같은 레플리카는 무작위로 선택됩니다. 특히 로컬 호스트명과 접두사를 전혀 공유하는 레플리카가 없는 경우(즉, 모든 공통 접두사 길이가 0인 경우) 이 전략은 random과 정확히 동일하게 동작합니다.

호스트명의 최장 공통 접미사

hostname_longest_common_prefix와 비슷하지만, 접두사 대신 가장 긴 공통 suffix를 비교합니다. 이는 데이터 센터 아이덴티티가 호스트명의 suffix에 인코딩되어 있을 때 유용합니다. 예를 들어, 로컬 호스트명이 et46gtghn.qc.localdomain인 경우:
여기서는 ab999.qc.localdomainet46gtghn.qc.localdomain과 가장 긴 공통 접미사(.qc.localdomain, 길이 15)를 가지므로 우선 선택됩니다. 공통 접미사 길이가 같은 레플리카는 무작위로 선택됩니다. 특히 어떤 레플리카도 로컬 호스트명과 공통 접미사를 가지지 않는 경우(모든 공통 접미사 길이가 0인 경우), 이 전략은 random과 정확히 동일하게 동작합니다.

순서대로

오류 수가 동일한 레플리카는 구성에 지정된 순서대로 액세스됩니다. 어느 레플리카를 우선해야 하는지 정확히 알고 있을 때 이 메서드가 적합합니다.

첫 번째 또는 무작위

이 알고리즘은 세트에서 첫 번째 레플리카를 선택하고, 첫 번째 레플리카를 사용할 수 없으면 임의의 레플리카를 선택합니다. 교차 복제 토폴로지 구성에서는 효과적이지만, 다른 구성에서는 효과가 없습니다. first_or_random 알고리즘은 in_order 알고리즘의 문제를 해결합니다. in_order에서는 한 레플리카가 중단되면 다음 레플리카의 부하가 2배로 증가하고, 나머지 레플리카는 평소와 같은 양의 트래픽을 처리합니다. first_or_random 알고리즘을 사용하면 사용 가능한 레플리카 사이에 부하가 고르게 분산됩니다. 설정 load_balancing_first_offset을 사용하면 어떤 레플리카를 첫 번째 레플리카로 할지 명시적으로 정의할 수 있습니다. 이렇게 하면 레플리카 간 쿼리 워크로드를 리밸런싱하는 방식을 더 세밀하게 제어할 수 있습니다.

Round Robin

이 알고리즘은 오류 수가 같은 레플리카들에 대해 라운드 로빈 정책을 사용합니다(round_robin 정책을 사용하는 쿼리만 집계됩니다).

load_balancing_first_offset

FIRST_OR_RANDOM load balancing 전략을 사용할 때 우선적으로 쿼리를 보낼 레플리카를 지정합니다.
마지막 수정일 2026년 7월 23일