Apache Doris 4.1: 벡터 검색·전문 검색·SQL 분석을 단일 엔진으로 통합한 AI 데이터 플랫폼

무엇이 달라졌는가

AI 워크로드는 데이터베이스에 이전에 없던 세 가지 쿼리를 동시에 요구한다.

1. 시맨틱 검색: 벡터 임베딩을 기반으로 의미적으로 유사한 문서를 찾는다.
2. 키워드 검색: 정확한 단어나 구절로 로그, 대화, 문서를 필터링한다.
3. 집계 분석: 검색 결과 위에서 시간별 집계, 이상 탐지, 사용량 통계를 실행한다.

기존 아키텍처는 이 세 가지를 각각 다른 시스템에서 처리한다. 벡터 DB(Milvus, Qdrant), 검색 엔진(Elasticsearch), 분석 DB(ClickHouse, BigQuery)를 파이프라인으로 엮는다. 데이터 복제, 일관성 관리, 인프라 비용이 세 배로 늘어난다.

Apache Doris 4.1.0(2026년 4월 21일, 최신 패치 4.1.3은 2026년 7월 13일)은 이 세 가지를 단일 SQL 엔진에서 처리하는 것을 목표로 했다.

Apache Doris 아키텍처 기본

Doris는 FE(Frontend)와 BE(Backend) 두 계층으로 구성된다.

FE는 쿼리 파싱, 비용 기반 최적화, 메타데이터 관리를 담당한다. BE는 실제 데이터 처리와 인덱스 검색을 수행한다. 저장-컴퓨팅 분리 모드에서는 BE가 공유 오브젝트 스토리지(S3, HDFS)에서 데이터를 읽고 로컬 캐시를 활용한다. 2,000개 이상의 기업이 이 분리 모드를 프로덕션에 배포하고 있다.

IVF: 억 단위 벡터 검색

Doris 4.0에서 도입된 HNSW(Hierarchical Navigable Small World) 인덱스는 수백만 벡터 규모에 적합하다. HNSW는 정밀도가 높지만 모든 벡터를 메모리에 올려야 하므로 억 단위 이상에서 비용이 급증한다.

4.1에서 도입된 IVF(Inverted File Index)는 "먼저 클러스터링하고, 국소 탐색"하는 원리로 이 한계를 극복한다.

IVF 작동 원리

1. 빌드 단계:
   - 전체 벡터를 K개 클러스터로 나눈다 (보통 K = √N)
   - 각 클러스터의 중심(centroid)을 계산한다

2. 검색 단계:
   - 쿼리 벡터에서 가장 가까운 클러스터 중심 nprobe개를 선택
   - 선택된 클러스터 내부에서만 브루트포스 비교 수행
   - 전체 탐색 대신 nprobe/K 비율만큼의 벡터만 비교

예시: 10억 벡터, K=31623(√10^9), nprobe=100
→ 전체 대비 탐색 비율: 100/31623 ≈ 0.3%
→ 정밀도 손실: recall@97% 수준 유지 가능

IVF_ON_DISK: 조 단위 확장

IVF의 클러스터 데이터가 너무 크면 메모리를 초과할 수 있다. IVF_ON_DISK는 Microsoft의 SPANN 논문 방식을 참조해 메모리 캐시 + 로컬 파일시스템 캐시 두 계층으로 클러스터 포스팅 리스트를 관리한다.

저장-컴퓨팅 분리 모드와 결합하면 원격 오브젝트 스토리지에 인덱스를 두고 BE 로컬 디스크를 캐시 레이어로 활용할 수 있어, 메모리를 거의 쓰지 않고 조 단위 규모 벡터 검색이 가능해진다.

벤치마크 (VectorDBBench 기준)

SEARCH(): SQL 안으로 들어온 전문 검색

Doris 4.0에서 SEARCH() 함수가 처음 도입됐고, 4.1에서 BM25 스코어링과 Elasticsearch 호환 쿼리 문법이 추가됐다.

기본 사용법

-- 단순 키워드 검색
SELECT id, title, score()
FROM articles
WHERE SEARCH(content, 'LLM inference optimization');

-- BM25 스코어 기반 랭킹
SELECT id, title, SCORE() AS relevance
FROM articles
WHERE SEARCH(content, 'kernel memory GPU')
ORDER BY relevance DESC
LIMIT 20;

-- 구문(phrase) 검색
SELECT *
FROM logs
WHERE SEARCH(message, '"connection reset by peer"');

지원 연산자

전문 검색 + 집계를 단일 쿼리로

기존 방식에서 Elasticsearch는 집계를 처리할 수 있지만, 검색 결과를 다시 분석 DB로 내보내 복잡한 집계를 처리하는 경우가 많았다. Doris 4.1에서는 필터와 집계가 동일한 실행 엔진에서 처리된다.

-- 에러 로그 검색 + 시간별 집계를 한 쿼리에서
SELECT
    DATE_TRUNC('hour', ts) AS hour,
    COUNT(*) AS error_count,
    COUNT(DISTINCT host) AS affected_hosts
FROM system_logs
WHERE SEARCH(message, 'TERM(level, "error") AND NOT TERM(message, "expected")')
  AND ts >= NOW() - INTERVAL 24 HOUR
GROUP BY 1
ORDER BY 1;

하이브리드 검색: 벡터 + 키워드 + 필터

RAG 파이프라인에서 가장 효과적인 검색은 벡터 시맨틱 검색과 키워드 매칭을 결합한 하이브리드 검색이다.

-- 하이브리드 검색 예시 (벡터 + 전문 검색 + 메타 필터)
SELECT
    doc_id,
    chunk_text,
    ANN_DISTANCE(embedding, [0.12, -0.34, ...]) AS vector_dist,
    SCORE() AS bm25_score
FROM knowledge_base
WHERE
    SEARCH(chunk_text, 'database connection pool tuning')   -- 키워드
    AND ANN_DISTANCE(embedding, [0.12, -0.34, ...]) < 0.8  -- 벡터
    AND doc_type = 'runbook'                                 -- 메타 필터
    AND updated_at >= '2026-01-01'
ORDER BY (0.6 * bm25_score + 0.4 * (1 - vector_dist)) DESC
LIMIT 10;

세 가지 필터(키워드, 벡터, 구조적 메타)가 한 번의 테이블 스캔에서 처리된다. 중간 결과를 다른 시스템으로 보낼 필요가 없다.

대용량 JSON: 에이전트 메모리를 위한 100MB 문서

AI 에이전트 시스템에서는 긴 대화 이력, 도구 실행 로그, 멀티-모달 컨텍스트가 단일 JSON 문서로 저장된다. 문서 크기가 수십 MB에 달하는 경우가 생긴다.

Doris 4.1은 단일 JSON 문서 크기를 최대 100MB로 지원하며, VARIANT 타입의 동적 필드를 희소 컬럼(sparse column)으로 효율적으로 저장한다. 희소 필드는 데이터가 있는 행에만 저장 공간을 사용한다.

-- 에이전트 메모리 스토어 예시
CREATE TABLE agent_sessions (
    session_id  VARCHAR(64),
    agent_id    VARCHAR(32),
    ts          DATETIME,
    context     VARIANT,              -- JSON 문서, 최대 100MB
    embedding   ARRAY<FLOAT>(1536),   -- 컨텍스트 임베딩
    INDEX idx_context_text (context)  USING INVERTED,  -- 전문 검색
    INDEX idx_embedding (embedding)   USING HNSW        -- 벡터 검색
) ENGINE=OLAP
DISTRIBUTED BY HASH(session_id) BUCKETS 32;

저장-컴퓨팅 분리와 비용 최적화

AI 데이터 플랫폼에서 비용 구조는 두 가지로 나뉜다.

저장-컴퓨팅 분리에서 BE 노드는 데이터를 영구 저장하지 않는다. 쿼리 시 필요한 파일만 오브젝트 스토리지에서 읽어 로컬 캐시에 올린다. 컴퓨팅 노드는 쿼리 부하에 따라 독립적으로 스케일 인/아웃할 수 있고, 여러 컴퓨팅 클러스터가 같은 데이터를 공유해 워크로드를 격리할 수 있다.

운영 체크리스트

인덱스 선택

SEARCH() 성능 팁

• 역 인덱스(INVERTED INDEX)가 해당 컬럼에 설정되어 있어야 SEARCH()가 인덱스를 탄다. 없으면 전체 스캔이 발생한다.
• BM25 사용 시 테이블 생성 시점에 PROPERTIES("inverted_index_storage_format"="V3")를 지정한다. V3는 저장 크기를 V2 대비 최대 20% 줄였다.
• nprobe 파라미터(IVF 탐색 클러스터 수)는 recall과 지연의 트레이드오프다. 97% recall을 목표로 사전 벤치마킹 후 결정한다.

Doris 4.0 → 4.1 마이그레이션 주의

• SEARCH() 함수 시그니처는 호환되지만 내부 BM25 스코어 계산 방식이 변경됐다. 점수 기반 랭킹 임계값이 있으면 재조정이 필요하다.
• IVF 인덱스는 HNSW 인덱스와 별도 DDL로 생성한다. 기존 HNSW 인덱스는 영향을 받지 않는다.

요점 정리

Apache Doris 4.1은 AI 애플리케이션이 필요로 하는 세 가지 쿼리 유형 — 벡터 시맨틱 검색, 전문 키워드 검색, SQL 집계 분석 — 을 단일 실행 엔진에서 처리하는 것에 집중한 릴리스다.

IVF_ON_DISK로 조 단위 벡터 검색이 현실화됐고, BM25와 ES 호환 문법으로 SEARCH() 함수의 실용성이 높아졌다. 저장-컴퓨팅 분리 모드와 결합하면 컴퓨트 비용과 스토리지 비용을 독립적으로 제어하면서 대규모 AI 데이터를 운영할 수 있다.

Elasticsearch + Milvus + ClickHouse를 각각 운영하는 구조를 단일 Doris 클러스터로 통합할 수 있는지를 평가하는 팀에게, 4.1은 현실적인 첫 번째 선택지가 됐다.

References

• Apache Doris 4.1.0 릴리스 노트: https://doris.apache.org/releases/v4.1/release-4.1.0/
• VeloDB — Apache Doris 4.1: Unified Storage and Retrieval for AI & Search: https://www.velodb.io/blog/apache-doris-4-1-unified-storage-and-retrieval-for-ai-and-search
• VeloDB — Search in Apache Doris 4.1 (Full-Text + SQL Analytics): https://www.velodb.io/blog/search-in-apache-doris-4-1-unifying-full-text-log-search-and-real-time-sql-analytics
• Apache Doris IVF 문서: https://doris.apache.org/docs/4.x/ai/vector-search/ivf/
• GitHub Release Notes 4.1.0 (Issue #62406): https://github.com/apache/doris/issues/62406
• How We Built Production Vector Search in Apache Doris: https://doris.apache.org/blog/how-we-built-production-vector-search-in-apache-doris/
• Apache Doris 2026 Roadmap: https://cdn.selectdb.com/static/doris_roadmap_2026_final_b3f6426007.pdf