Ken
Note: 본 문서는 ClickHouse 25.8 버전을 기준으로 작성되었습니다. Vector Search 기능은 지속적으로 개선되고 있으며, 최신 버전(25.9, 25.10)에서는 Streaming Secondary Indices, QBit 데이터 타입 등 추가 기능이 도입되었습니다.
- 1. Vector Search 개요
- 1.1 왜 ClickHouse에서 Vector Search인가?
- 1.2 지원하는 거리 함수
- 2. Vector Search 기능 발전 과정과 로드맵
- 2.1 버전별 주요 마일스톤
- 2.2 향후 로드맵 예상
- 3. Lookalike Audience 유스케이스 이해
- 3.1 비즈니스 배경
- 3.2 주요 쿼리 패턴
- 3.3 HNSW vs Brute Force: 언제 무엇을 선택해야 하는가?
- 4. 실제 검증 사례
- 4.1 테스트 환경
- 4.2 벤치마크 결과
- 4.3 캐시 효과 분석
- 5. ClickHouse Vector Search의 강점 분석
- 5.1 아키텍처적 강점
- 5.2 운영적 강점
- 5.3 비용 효율성
- 6. 향후 발전 기대 가능성
- 6.1 QBit: 쿼리 시점 정밀도 선택
- 6.2 Streaming Secondary Indices
- 6.3 양자화 옵션의 확대
- 6.4 발전 방향 예측
- 7. 결론 및 권장 사항
- 7.1 ClickHouse Vector Search 적합 시나리오
- 7.2 권장 설정
- 7.3 마무리
1. Vector Search 개요
1.1 왜 ClickHouse에서 Vector Search인가?
ClickHouse는 실시간 분석 데이터베이스(OLAP)로 알려져 있지만, AI/ML 시대에 맞춰 벡터 검색 기능을 빠르게 발전시키고 있습니다. 기존에 분석 워크로드와 벡터 검색을 위해 별도의 시스템을 운영해야 했던 아키텍처를 단일 플랫폼으로 통합할 수 있는 가능성이 열린 것입니다.
ClickHouse Vector Search의 핵심 가치는 다음과 같습니다.
첫째, 통합 플랫폼입니다. 분석 쿼리와 벡터 검색을 하나의 SQL 인터페이스로 처리할 수 있어, 복잡한 하이브리드 쿼리(벡터 유사도 + 필터링 + 집계)를 단일 쿼리로 표현할 수 있습니다.
둘째, 대용량 처리 능력입니다. ClickHouse의 컬럼 기반 스토리지와 병렬 처리 아키텍처는 수십억 개의 벡터를 효율적으로 저장하고 검색할 수 있는 기반을 제공합니다.
셋째, 비용 효율성입니다. 전용 벡터 데이터베이스를 별도로 운영할 필요 없이, 기존 ClickHouse 인프라를 활용하여 TCO를 절감할 수 있습니다.
1.2 지원하는 거리 함수
ClickHouse는 벡터 간 유사도를 측정하기 위한 다양한 거리 함수를 내장 지원합니다.
-- Cosine Distance (가장 널리 사용)
SELECT cosineDistance(embedding, target_vec) AS score
-- L2 (Euclidean) Distance
SELECT L2Distance(embedding, target_vec) AS score
-- Dot Product (내적)
SELECT dotProduct(embedding, target_vec) AS score
-- L1 (Manhattan) Distance
SELECT L1Distance(embedding, target_vec) AS score
Cosine Distance는 텍스트 임베딩에서 가장 널리 사용되며, 벡터의 방향만을 비교합니다. L2 Distance는 벡터 간의 절대적 거리를 측정하며, 이미지 임베딩에서 자주 사용됩니다.
2. Vector Search 기능 발전 과정과 로드맵
2.1 버전별 주요 마일스톤
ClickHouse의 벡터 검색 기능은 2023년부터 본격적으로 발전해왔습니다.
24.8 (2024년 8월): vector_similarity 인덱스가 실험적(Experimental) 기능으로 도입되었습니다. 기존의 Annoy 인덱스와 USearch 인덱스를 대체하는 통합 인덱스로, HNSW(Hierarchical Navigable Small World) 알고리즘을 기반으로 합니다.
25.5 (2025년 6월): Vector Similarity Index가 베타(Beta)로 승격되었습니다. Hybrid Search를 위한 Pre/Post 필터링 전략이 도입되어, vector_search_filter_strategy 설정을 통해 필터링 방식을 제어할 수 있게 되었습니다.
25.8 (2025년 9월): 본 문서의 기준 버전입니다. 새로운 Parquet 리더의 성능이 1.81배 향상되었으며, Azure Blob Storage 지연 문제가 해결되었습니다. Data Lake 통합(Iceberg, Delta Lake, Hudi)이 강화되어 외부 데이터 소스의 벡터 데이터도 효율적으로 처리할 수 있습니다.
25.9 (2025년 10월): Streaming Secondary Indices가 도입되었습니다. 기존에는 인덱스를 먼저 전체 스캔한 후 쿼리를 실행했으나, 이제 인덱스 스캔과 데이터 읽기가 동시에 진행되어 LIMIT 쿼리에서 4배 이상의 성능 향상을 얻을 수 있습니다.
25.10 (2025년 11월): QBit 데이터 타입이 도입되었습니다. 쿼리 시점에 정밀도를 선택할 수 있는 혁신적인 기능으로, 원본 데이터를 유지하면서도 낮은 정밀도로 빠른 검색을 수행할 수 있습니다.
2.2 향후 로드맵 예상
ClickHouse의 벡터 검색 기능은 계속 발전하고 있으며, 다음과 같은 방향이 예상됩니다.
첫째, Vector Similarity Index의 GA(General Availability) 전환이 예상됩니다. 현재 베타 상태인 인덱스가 프로덕션 레벨로 안정화될 것입니다.
둘째, 양자화(Quantization) 옵션의 확대입니다. 현재 BFloat16, Int8 등이 지원되며, 더 다양한 양자화 옵션이 추가될 것으로 보입니다.
셋째, 분산 환경에서의 벡터 검색 최적화입니다. 샤딩된 환경에서의 효율적인 벡터 검색을 위한 기능이 강화될 것입니다.
3. Lookalike Audience 유스케이스 이해
3.1 비즈니스 배경
Lookalike Audience(유사 타겟 오디언스)는 디지털 마케팅에서 핵심적인 개념입니다. 특정 시드(Seed) 유저 그룹과 유사한 특성을 가진 잠재 고객을 대량으로 발굴하여 광고 타겟팅이나 CRM 캠페인에 활용합니다.
전통적으로 이 작업은 전용 벡터 데이터베이스(Pinecone, Milvus, Qdrant 등)를 사용하거나, Spark/Hadoop 기반의 배치 처리로 수행되었습니다. 그러나 ClickHouse의 벡터 검색 기능을 활용하면, 기존 분석 플랫폼 내에서 실시간에 가깝게 유사 유저를 추출할 수 있습니다.
3.2 주요 쿼리 패턴
Lookalike Audience 추출에는 크게 두 가지 쿼리 패턴이 존재합니다.
패턴 A: 단일 시드 → 대량 추출
하나의 시드 벡터로부터 수백만 명의 유사 유저를 추출하는 패턴입니다.
-- 시드 1개 → 500만 유사 유저 추출
SELECT
user_id,
cosineDistance(embedding, seed_vec) AS score
FROM user_embeddings
ORDER BY score ASC
LIMIT 5000000
SETTINGS max_threads = 32;
이 패턴은 전체 데이터의 33%까지 추출하는 경우에도 ClickHouse의 Partial Sort 최적화 덕분에 효율적으로 처리됩니다.
패턴 B: 다중 시드 Loop
여러 시드에 대해 각각 Top-K 유사 유저를 추출하는 패턴입니다.
-- 시드 5000개 × top 100 = 5000번 쿼리
SELECT
user_id,
cosineDistance(embedding, seed_vec) AS score
FROM user_embeddings
ORDER BY score ASC
LIMIT 100;
이 패턴은 병렬 실행하거나, 배치 처리 쿼리로 최적화할 수 있습니다.
패턴 B 최적화: 배치 처리
3.3 HNSW vs Brute Force: 언제 무엇을 선택해야 하는가?
Lookalike Audience 시나리오에서는 HNSW 인덱스와 Brute Force 스캔 중 적절한 방식을 선택해야 합니다.
HNSW 인덱스 사용이 적합한 경우: Top-K가 작은 경우(1~1,000), 데이터셋이 매우 큰 경우(1억 건 이상), 쿼리 응답 시간이 중요한 경우, 약간의 정확도 손실이 허용되는 경우입니다.
Brute Force 스캔이 적합한 경우: Top-K가 큰 경우(10만~500만), 100% 정확도(Recall = 1)가 필요한 경우, 데이터가 핫 캐시에 상주할 수 있는 규모인 경우입니다.
Lookalike Audience의 경우, Top-K가 500만에 달하는 대량 추출이 필요하므로 Brute Force 스캔이 더 적합합니다.
4. 실제 검증 사례
4.1 테스트 환경
실제 Lookalike Audience 시나리오를 검증하기 위해 다음과 같은 환경에서 벤치마크를 수행했습니다.
항목 | 사양 |
총 유저 수 | 15,000,000 (15M) |
벡터 차원 | 512 dim |
데이터 타입 | Array(Float32) |
데이터 크기 | 약 28.6 GiB |
플랫폼 | ClickHouse Cloud (ap-northeast-2) |
컴퓨트 | 32 vCPU |
테이블 스키마는 다음과 같이 설계했습니다.
CREATE TABLE user_embeddings (
user_id UInt64,
embedding Array(Float32) CODEC(NONE),
user_segment String DEFAULT 'general',
updated_at DateTime DEFAULT now()
) ENGINE = MergeTree()
ORDER BY user_id
SETTINGS index_granularity = 8192;
CODEC(NONE)은 압축을 비활성화하여 I/O 성능을 최적화합니다. 벡터 데이터는 이미 랜덤한 부동소수점으로 압축 효율이 낮기 때문입니다.
4.2 벤치마크 결과
패턴 A: 대량 추출 (LIMIT 5M)
Distance Function | 응답 시간 | Data Read | Peak Memory |
cosineDistance | 2.2~2.3초 | 28.72 GiB | 2.02 GiB |
dotProduct | 2.2~2.3초 | 28.72 GiB | 1.97 GiB |
L2Distance | 2.2~2.3초 | 28.72 GiB | 2.09 GiB |
15M 유저 중 5M(33%)을 추출하는 데 약 2.2초가 소요되었습니다. 거리 함수 종류와 무관하게 일관된 성능을 보여주며, 이는 ClickHouse의 병렬 처리와 Partial Sort 최적화가 효과적으로 작동함을 의미합니다.
패턴 B: Top-100 추출
데이터셋 | 응답 시간 | Data Read |
Brute Force (15M) | ~1.1초 | 28.72 GiB |
BFloat16 양자화 (15M) | ~0.7초 | 14.36 GiB |
5000 시드 쿼리 예상 소요 시간
실행 방식 | 예상 시간 |
순차 실행 | ~91분 |
병렬 실행 (32 concurrent) | ~3분 |
배치 쿼리 최적화 | ~10분 |
4.3 캐시 효과 분석
ClickHouse의 성능은 캐시 상태에 따라 크게 달라집니다.
상태 | Top-100 응답 시간 | 처리량 |
콜드 캐시 | 3.77초 | 1.53 GiB/sec |
핫 캐시 | 0.45초 | 12.84 GiB/sec |
핫 캐시 상태에서는 콜드 상태 대비 약 8배의 성능 향상을 확인할 수 있습니다. 따라서 프로덕션 환경에서는 캐시 워밍업 전략이 중요합니다.
5. ClickHouse Vector Search의 강점 분석
5.1 아키텍처적 강점
컬럼 기반 스토리지의 이점: 벡터 컬럼만 선택적으로 읽을 수 있어, 불필요한 I/O를 최소화합니다. embedding 컬럼만 28GB를 읽으면 되며, 다른 메타데이터 컬럼은 필요 시에만 읽습니다.
병렬 처리 아키텍처: ClickHouse는 쿼리의 모든 단계(필터링, 정렬, 집계)를 병렬화합니다. 32 vCPU 환경에서 max_threads = 32 설정 시, 벡터 거리 계산이 32개 스레드에서 동시에 처리됩니다.
하이브리드 쿼리 지원: 벡터 유사도 검색과 SQL 필터링을 하나의 쿼리로 결합할 수 있습니다.
-- 특정 세그먼트에서만 유사 유저 검색
SELECT user_id, cosineDistance(embedding, seed_vec) AS score
FROM user_embeddings
WHERE user_segment IN ('premium', 'active')
AND updated_at > now() - INTERVAL 30 DAY
ORDER BY score ASC
LIMIT 10000;
5.2 운영적 강점
통합 플랫폼: 분석, ETL, 벡터 검색을 하나의 시스템에서 처리하여 운영 복잡성을 줄입니다. 별도의 벡터 DB를 운영할 필요가 없습니다.
SQL 인터페이스: 새로운 쿼리 언어를 배울 필요 없이, 기존 SQL 지식으로 벡터 검색을 수행할 수 있습니다.
ClickHouse Cloud의 이점: 자동 스케일링, Multi-AZ 복제, 관리형 인프라를 통해 운영 부담을 최소화합니다. Warehouse 기능을 활용하면 벡터 검색 전용 Compute Pool을 분리하여 워크로드 격리가 가능합니다.
5.3 비용 효율성
전용 벡터 데이터베이스와 비교했을 때, ClickHouse는 다음과 같은 비용 이점이 있습니다.
스토리지 비용: ClickHouse Cloud의 Shared Storage는 S3 기반으로, 대용량 벡터 데이터를 비용 효율적으로 저장합니다.
인프라 통합: 분석과 벡터 검색을 위한 별도 인프라 불필요합니다.
탄력적 스케일링: 사용량에 따라 자동으로 스케일 업/다운되어, 유휴 리소스 비용을 절감합니다.
6. 향후 발전 기대 가능성
6.1 QBit: 쿼리 시점 정밀도 선택
ClickHouse 25.10에서 도입된 QBit은 벡터 검색의 패러다임을 바꿀 수 있는 기능입니다.
-- QBit 컬럼 생성
CREATE TABLE vectors (
id UInt64,
name String,
vec QBit(Float32, 1536)
) ORDER BY ();
-- 쿼리 시점에 정밀도 선택 (16bit만 사용)
SELECT id, name
FROM vectors
ORDER BY L2DistanceTransposed(vec, target, 16)
LIMIT 10;
QBit은 데이터를 비트 단위로 분리 저장하여, 쿼리 시점에 필요한 정밀도만 읽습니다. 이를 통해 원본 데이터를 유지하면서도 속도와 정확도 사이의 트레이드오프를 동적으로 조절할 수 있습니다.
6.2 Streaming Secondary Indices
25.9에서 도입된 Streaming Secondary Indices는 LIMIT 쿼리의 성능을 획기적으로 개선합니다.
기존 방식에서는 인덱스 전체를 먼저 스캔한 후 데이터를 읽었습니다. 새로운 방식에서는 인덱스 스캔과 데이터 읽기가 동시에 진행되어, LIMIT에 도달하면 즉시 중단됩니다.
벤치마크 결과, 기존 방식에서 10.17초 걸리던 쿼리가 새로운 방식에서 2.4초로, 4배 이상의 성능 향상을 보여주었습니다.
6.3 양자화 옵션의 확대
현재 지원되는 양자화 옵션과 메모리 절감 효과는 다음과 같습니다.
양자화 타입 | 메모리 사용량 | 정확도 영향 |
Float32 (기본) | 100% | 없음 |
BFloat16 | 50% | 미미함 |
Int8 | 25% | 약간 있음 |
Binary (b1) | 3% | 상당함 |
BFloat16 양자화는 정확도 손실이 거의 없으면서 메모리를 50% 절감할 수 있어, 대부분의 프로덕션 환경에서 권장됩니다.
6.4 발전 방향 예측
분산 벡터 검색 최적화: 샤딩된 환경에서의 효율적인 Top-K 병합 알고리즘이 개선될 것으로 예상됩니다.
GPU 가속: 벡터 거리 계산의 GPU 오프로딩이 지원될 가능성이 있습니다.
자동 인덱스 선택: 쿼리 패턴과 데이터 특성에 따라 HNSW 인덱스 사용 여부를 자동으로 결정하는 기능이 추가될 수 있습니다.
7. 결론 및 권장 사항
7.1 ClickHouse Vector Search 적합 시나리오
다음과 같은 경우 ClickHouse Vector Search가 적합합니다.
- 이미 ClickHouse를 분석 플랫폼으로 사용 중인 경우
- 벡터 검색과 SQL 분석을 결합해야 하는 경우
- 대용량 데이터(수천만~수억 건)의 배치성 벡터 검색이 필요한 경우
- Lookalike Audience처럼 Top-K가 큰 검색이 필요한 경우
- 인프라 통합을 통해 운영 복잡성을 줄이고 싶은 경우
7.2 권장 설정
테이블 설계
CREATE TABLE user_embeddings (
user_id UInt64,
embedding Array(Float32) CODEC(NONE),
-- 또는 BFloat16 양자화 사용 시
-- embedding_bf16 Array(Float32) CODEC(NONE),
INDEX vec_idx embedding TYPE vector_similarity('hnsw', 'cosineDistance')
) ENGINE = MergeTree()
ORDER BY user_id
SETTINGS index_granularity = 8192;
쿼리 최적화
-- 병렬 처리 최대화
SET max_threads = 32;
-- HNSW 인덱스 사용 시 탐색 범위 조정
SET hnsw_candidate_list_size_for_search = 512;
-- 필터링 전략 선택
SET vector_search_filter_strategy = 'auto';
7.3 마무리
ClickHouse의 Vector Search는 이제 더 이상 실험적 기능이 아닙니다. 25.5에서 베타로 승격된 이후, 매 릴리스마다 성능과 기능이 개선되고 있습니다. 특히 Lookalike Audience와 같은 대용량 유사도 검색 시나리오에서는 전용 벡터 DB 못지않은 성능을 보여주고 있습니다.
물론 실시간 저지연(< 10ms) 검색이 필요하거나, 매우 높은 QPS가 요구되는 경우에는 전용 벡터 데이터베이스가 여전히 유리할 수 있습니다. 그러나 분석 워크로드와 벡터 검색을 통합하고자 하는 팀에게 ClickHouse는 매력적인 선택지입니다.
앞으로 QBit, Streaming Indices 등의 기능이 안정화되면, ClickHouse는 진정한 의미의 "Unified Analytics + Vector Search" 플랫폼으로 자리잡을 것으로 기대됩니다.
본 문서는 ClickHouse 25.8 기준으로 작성되었으며, 최신 기능 및 성능 개선 사항은 공식 릴리스 노트를 참조해 주세요.