왜 지금 봐야 하나
Apache Doris 4.1.0은 2026년 4월 21일에 공개됐고, 버그픽스 릴리스 4.1.1이 2026년 5월 24일에 뒤따랐다. 이번 릴리스가 주목받는 이유는 세 가지다.
첫째, IVF와 IVF_ON_DISK 벡터 인덱스가 추가됐다. 4.0에서 HNSW로 시작한 벡터 검색이 4.1에서 수십억 건~조 건 규모까지 확장됐다. IVF_ON_DISK는 Microsoft SPANN 논문의 아이디어를 구현해 디스크와 메모리를 조합함으로써 비용 부담 없이 극대 규모 벡터를 다룬다.
둘째, Segment V3 스토리지 포맷이 초광폭 테이블의 병목을 해소했다. 메타데이터를 footer에서 분리해 on-demand 로드를 지원하면서, V2 대비 파일 열기 속도 16배·메모리 사용 60배 절감을 달성한다. 수만 컬럼의 JSON 로그·이벤트 테이블을 운영하는 팀에게 직접적인 의미가 있다.
셋째, Iceberg V2/V3 완전 쓰기 지원(MERGE INTO 포함)과 Paimon DDL 지원이 Lakehouse 운영 경계를 실질적으로 넓혔다. 이전에는 Doris가 외부 테이블을 읽기만 했다면, 4.1부터는 Iceberg에 대한 UPDATE·DELETE·MERGE INTO가 가능하다.
Doris를 이미 운영 중이거나, AI/Search 워크로드와 OLAP을 한 엔진에서 처리하는 방안을 검토 중인 팀이라면 이 세 가지가 설계 결정에 직접 영향을 준다.
Apache Doris 4.1 핵심 변화 요약
| 영역 | 4.0까지 | 4.1에서 달라진 점 | 운영자가 받는 영향 |
|---|---|---|---|
| 벡터 인덱스 | HNSW만 지원 | IVF + IVF_ON_DISK 추가 | 억/조 규모 벡터를 저비용으로 운영 가능 |
| 스토리지 포맷 | Segment V2 | Segment V3 (메타 분리) | 초광폭 테이블 열기 속도·메모리 대폭 개선 |
| JSON 처리 | 즉시 shredding | DOC 모드 (deferred shredding) | 쓰기 부하 분산, V3과 함께 사용 |
| Lakehouse 쓰기 | Iceberg 읽기 중심 | Iceberg V2/V3 MERGE INTO 지원 | Doris에서 직접 Iceberg 레코드 병합 |
| Paimon 지원 | 읽기 전용 커넥터 | DDL(CREATE TABLE 등) 직접 실행 | Paimon 테이블을 Doris SQL로 관리 |
| SQL 기능 | 기본 DML | ASOF JOIN, Recursive CTE, UNNEST, MERGE INTO, TIMESTAMPTZ | 시계열 조인·트리 쿼리·Upsert 패턴 |
| JSON 크기 | 수 MB 수준 | 100MB+ 초대형 JSON 지원 | RAG 파이프라인의 대형 문서 처리 |
HSAP 아키텍처: 하나의 엔진 안에서 벡터·전문·분석이 동시에
1. 벡터 인덱스 삼총사: HNSW · IVF · IVF_ON_DISK
Doris 4.0에서 HNSW로 벡터 검색이 시작됐고, 4.1에서 IVF와 IVF_ON_DISK가 추가되면서 선택지가 세 가지가 됐다.
HNSW — 고품질 근사 검색의 기본
HNSW(Hierarchical Navigable Small World)는 다층 그래프 구조다. 상위 레이어에서 빠르게 후보를 좁히고, 하위 레이어에서 세밀하게 탐색한다. 주요 특성:
- 핵심 파라미터:
max_degree(그래프 노드 출차수, HNSW 알고리즘의 M),ef_construction(인덱스 구성 시 후보 큐 길이), 쿼리 시ef_search - 장점: recall이 높다 — 의미 검색에서 정확 검색에 근접한 품질. 쿼리 복잡도 O(log n)에 가까움.
- 적합한 규모: 수백만~수천만 건. 메모리 상주형.
- 운영 주의: 인덱스 전체가 메모리에 올라간다. 벡터 수가 많아지면 메모리 비용이 선형으로 증가한다.
IVF — 클러스터링으로 탐색 공간을 줄이는 대규모 인덱스
IVF(Inverted File Index)의 핵심 원리는 "먼저 군집화하고, 그다음 국소 탐색"이다. k-means로 벡터를 클러스터로 나눈 뒤, 쿼리 시 가장 가까운 클러스터만 탐색한다.
-- IVF 인덱스 생성 예시
CREATE TABLE t_search (
id BIGINT,
content TEXT,
emb ARRAY<FLOAT>
INDEX idx_emb(emb) USING VECTOR PROPERTIES (
"type" = "IVF",
"metric" = "cosine",
"nlist" = "1024" -- 클러스터 수
)
) ...;
-- 쿼리 시 recall·latency 조정
SET enable_vector_index = true;
SET nprobe = 64; -- 탐색할 클러스터 수 (높을수록 recall↑, latency↑)- 장점: HNSW보다 메모리 사용이 적다. 인덱스 구성이 빠르다.
- 적합한 규모: 수천만~수억 건.
- 운영 주의: recall은 HNSW보다 낮을 수 있다.
nprobe를 높이면 recall이 오르지만 latency도 오른다. 벤치마킹 후 운영nprobe를 결정해야 한다.
IVF_ON_DISK — 조 단위 규모의 저비용 벡터 검색
IVF_ON_DISK는 Microsoft의 SPANN 논문을 참고한 구현이다. 인덱스 일부를 메모리에, 나머지를 로컬 파일시스템에 두고 조합한다.
- 핵심 아이디어: SPANN처럼 "in-memory caching + local filesystem caching"으로 pruning을 저비용에 수행
- 적합한 규모: 수억~수조 건. GPU 없이 운영 가능한 최대 규모.
- 장점: IVF 대비 메모리 요구량이 대폭 낮다. 극대 규모 벡터 데이터셋에서 비용 효율적.
- 운영 주의: 디스크 I/O 패턴이 쿼리 latency에 영향을 준다. NVMe SSD 권장. 캐시 히트율을 모니터링해야 한다.
세 인덱스 선택 기준
| 기준 | HNSW | IVF | IVF_ON_DISK |
|---|---|---|---|
| 적합 규모 | ~수천만 | ~수억 | 수억~조 |
| 메모리 요구 | 높음 (전체 인덱스) | 중간 | 낮음 (파일 캐시) |
| recall 품질 | 높음 | 중간 (nprobe로 조정) | 중간~낮음 (디스크 캐시 의존) |
| 인덱스 구성 속도 | 느림 | 빠름 | 빠름 |
| 쿼리 latency | 낮음 | 중간 | 디스크 I/O 의존 |
2. 하이브리드 검색: 역 인덱스를 먼저 태운 다음 ANN으로 좁힌다
Doris 4.1의 하이브리드 검색 전략은 업계에서 흔히 쓰는 순서와 반대다.
일반적인 순서: ANN으로 top-K 후보를 뽑고 → 필터 적용
Doris의 순서: 역 인덱스로 조건을 먼저 걸러내고 → 생존한 행셋에만 ANN top-N 적용
이 순서의 장점은 필터가 선택적일수록 recall이 높아진다는 것이다. 필터가 데이터의 1%만 남기면 ANN이 탐색해야 하는 공간이 1%로 줄어든다. 반대로 ANN 먼저 하면 필터링 전 전체 데이터에서 approximate를 수행하므로 후속 필터에서 진짜 관련 결과가 잘려 나갈 수 있다.
-- 하이브리드 검색 예시: 최근 7일 데이터 중 "결제 오류"와 의미적으로 가까운 로그
SELECT
id,
content,
score() AS bm25_score,
cosine_distance(emb, [0.1, 0.2, ...]) AS vec_dist
FROM log_table
WHERE
created_at >= NOW() - INTERVAL 7 DAY -- 역 인덱스로 먼저 필터
AND MATCH(content, "결제 오류") -- BM25 전문 검색
ORDER BY vec_dist ASC -- ANN 정렬
LIMIT 20;score() 함수는 BM25 relevance score를 반환하고, cosine_distance() / l2_distance() / dot_product()는 벡터 거리를 계산한다. 두 점수를 결합한 재순위화(re-ranking)는 애플리케이션 레이어에서 처리한다.
전문 검색 기능 확장 (4.1)
- BM25 스코어링: 스토리지 레이어 TopN 최적화 — 전체 결과셋을 전송하지 않고 각 세그먼트에서 미리 top-N을 계산
- ES 호환 구문:
MATCH_PHRASE,MATCH_ALL,MATCH_ANY등 - NESTED 연산자: JSON 배열 내부를 직접 검색 — 중첩 이벤트 로그, 태그 배열에 유용
- multi-field 검색:
best_fields(같은 필드 내 정확 매치),cross_fields(여러 필드에 분산 매치)
3. Segment V3와 DOC 모드: 초광폭 테이블의 병목 해소
수만 개 컬럼을 가진 JSON 로그 테이블을 Doris에서 운영하면 Segment V2에서 두 가지 문제가 나타난다.
- 파일 열기 지연: 메타데이터가 footer에 전부 들어 있어, 파일을 열 때마다 전체 메타를 읽어야 한다.
- 메모리 bloat: 활성 쿼리가 필요한 컬럼만 읽어도 메타데이터 메모리는 모든 컬럼에 대해 할당된다.
Segment V3는 메타데이터를 footer에서 분리해 on-demand 로드로 전환한다. 수치는 명확하다: V2 대비 파일 열기 속도 16배, 메모리 사용 60배 개선(초광폭 테이블 기준).
DOC 모드: 쓰기 부하를 compaction으로 미루는 전략
기존 방식은 JSON이 들어오면 즉시 컬럼별로 분해(shredding)했다. 컬럼 수가 많을수록 쓰기 CPU 비용이 높아진다.
DOC 모드는 이 순서를 바꾼다.
- 쓰기 경로: JSON을 원본 문서 형태로 효율적으로 저장
- shredding 시점: compaction 시, 자주 조회되는 경로(hot path)에 한해서만 수행
이 전략의 핵심 trade-off:
| 항목 | 즉시 Shredding | DOC 모드 |
|---|---|---|
| 쓰기 CPU | 높음 (모든 필드 즉시 처리) | 낮음 (문서로만 저장) |
| 쿼리 성능 | hot path 최적화 이미 완료 | compaction 전까지 cold path 쿼리 느림 |
| compaction 부하 | 낮음 | 높음 (shredding 포함) |
| 사용 조건 | 범용 | V3와 함께만 사용 가능 / sparse 모드와 배타적 |
운영 원칙: 쓰기 처리량이 읽기 응답 시간보다 중요한 파이프라인, 또는 대부분의 컬럼이 거의 조회되지 않는 초광폭 테이블에 DOC 모드가 맞다.
4. Lakehouse 쓰기: Iceberg V3와 Paimon DDL 지원
Iceberg V2/V3 완전 쓰기 (MERGE INTO 포함)
4.1 이전에는 Doris가 Iceberg 테이블을 주로 읽기 위한 외부 테이블로 취급했다. 4.1부터 쓰기가 본격 지원된다.
-- Iceberg 테이블에 Upsert
MERGE INTO iceberg.my_catalog.orders AS target
USING staging_orders AS source
ON target.order_id = source.order_id
WHEN MATCHED THEN
UPDATE SET total_amount = source.total_amount, updated_at = source.updated_at
WHEN NOT MATCHED THEN
INSERT (order_id, customer_id, total_amount, created_at)
VALUES (source.order_id, source.customer_id, source.total_amount, source.created_at);Iceberg V3 신기능 지원:
- Deletion Vector: 행 삭제를 별도 벡터로 관리 — copy-on-write 없이 빠른 DELETE
- Row Lineage: 행의 출처 추적 지원
Paimon DDL 직접 실행
기존에는 Paimon 테이블을 Doris에서 읽으려면 Paimon 쪽에서 테이블을 먼저 만들어야 했다. 4.1부터는 Doris SQL로 직접 생성할 수 있다.
-- Doris에서 Paimon 테이블 생성
CREATE DATABASE paimon_catalog.my_db;
CREATE TABLE paimon_catalog.my_db.events (
event_id BIGINT,
user_id BIGINT,
event_type STRING,
ts TIMESTAMPTZ,
payload VARIANT
) USING paimon;이 변화의 의미: Doris를 데이터 플랫폼의 단일 SQL 관리 포인트로 쓸 수 있게 됐다. 외부 시스템에서 테이블을 만들고 Doris에서 읽는 2단계 과정이 사라진다.
5. SQL 기능 확장: 시계열 조인과 Upsert 패턴
ASOF JOIN — 시계열 데이터의 "가장 가까운 시점" 조인
금융·이벤트 분석에서 자주 필요한 패턴: "이 주문이 들어온 시점의 가장 최근 환율"을 구하고 싶을 때.
-- 주문 시점 기준으로 가장 가까운 환율 적용
SELECT o.order_id, o.amount_usd, r.rate
FROM orders o
ASOF JOIN exchange_rates r
ON o.currency = r.currency
AND o.created_at >= r.rate_time
ORDER BY r.rate_time DESC;ASOF JOIN은 >= 또는 <= 조건으로 "그 이전(이후) 시점 중 가장 가까운 행"을 찾는다. 기존에는 correlated subquery나 window function으로 구현해야 했다.
MERGE INTO — Lakehouse 내 Upsert
Iceberg 외에도 Doris 자체 테이블에서도 MERGE INTO를 쓸 수 있다. Doris가 데이터 싱크 역할을 하는 CDC 파이프라인에서 중복 처리·Upsert를 SQL로 깔끔하게 표현할 수 있다.
Recursive CTE — 트리/그래프 쿼리
카테고리 계층, 조직도, 댓글 스레드 같은 재귀적 구조를 표준 SQL로 쿼리할 수 있다.
WITH RECURSIVE category_tree AS (
SELECT id, name, parent_id, 1 AS depth FROM categories WHERE parent_id IS NULL
UNION ALL
SELECT c.id, c.name, c.parent_id, t.depth + 1
FROM categories c JOIN category_tree t ON c.parent_id = t.id
)
SELECT * FROM category_tree ORDER BY depth, name;6. 도입 전에 해볼 검증 체크리스트
벡터 인덱스 선택 검증
- 데이터 규모: 수천만 이하 → HNSW 먼저 시도
- 수억 이상이고 메모리 예산이 타이트 → IVF로 recall 벤치마킹 후
nprobe결정 - 수억 이상이고 NVMe SSD 환경 → IVF_ON_DISK 고려, 캐시 히트율 모니터링 계획 수립
- 하이브리드 검색의 실제 recall: 필터 선택도(selectivity)를 먼저 측정
Segment V3 / DOC 모드 검증
- V3 활성화:
storage_format = "V3"테이블 프로퍼티로 신규 테이블에 먼저 적용 - DOC 모드 쓰기 속도 측정: 기존 shredding 방식 대비 쓰기 처리량 비교
- compaction 지연 측정: DOC 모드는 compaction 부하가 크다 — compaction 주기와 I/O에 여유 있는지 확인
- V3와 DOC 모드는 기존 V2 테이블과 혼용할 수 없다 — 마이그레이션은 새 테이블에 INSERT SELECT로 진행
Iceberg 쓰기 / MERGE INTO 검증
- Iceberg 카탈로그 연결 설정 재확인 (catalog 타입, REST vs HMS)
- MERGE INTO로 업서트 전,
DELETE지원 여부 확인 (Iceberg V2/V3 필요) - Deletion Vector 활성화 여부 검증: V3 Iceberg 테이블에서만 동작
- Row Lineage 기능이 필요한 downstream 시스템이 있으면 Iceberg V3로 마이그레이션 전 호환성 테스트
이 릴리스에서 특히 조심할 한계
- IVF_ON_DISK는 NVMe SSD가 아닌 환경에서 latency가 크게 나빠질 수 있다. 네트워크 스토리지(NFS, 클라우드 블록 스토리지)로는 성능 보장이 어렵다.
- DOC 모드는 V3와 배타적이다. 기존 V2 테이블에 적용하려면 전체 데이터를 새 테이블로 복사해야 한다. 운영 중인 대형 테이블은 마이그레이션 계획부터 세워야 한다.
- ASOF JOIN은 조인 키와 시간 컬럼에 적절한 정렬·인덱스가 없으면 느리다. 운영 전 실행 계획(EXPLAIN VERBOSE)으로 full scan 여부를 확인한다.
- Paimon DDL 지원은 아직 일부 DDL 연산에 제한이 있을 수 있다. 4.1.1 패치 릴리스 노트에서 지원되는 DDL 목록을 먼저 확인한다.
- 하이브리드 검색의 BM25·벡터 점수를 결합한 최종 순위화는 Doris가 해 주지 않는다. 스코어 결합 로직은 애플리케이션 레이어에서 직접 구현해야 한다.
Apache Doris 4.1의 핵심은 "새 기능을 많이 추가했다"보다, AI·Search 워크로드와 OLAP 분석을 동일한 데이터 레이어에서 다루면서 이중 적재와 동기화 비용을 없앤다는 방향이다. 벡터 인덱스 선택, 스토리지 포맷 전환, Lakehouse 쓰기 활성화 — 세 축 각각에 운영 판단이 따른다.
References
- Apache Doris 4.1.0 공식 릴리스 노트
- Apache Doris 4.1: Unified Storage and Retrieval for AI & Search (VeloDB)
- Beyond 10,000 Fields: Balancing Performance and Cost in Wide JSON with Apache Doris 4.1 (Medium)
- Hybrid Search — Apache Doris Docs
- Vector Search Overview — Apache Doris Docs
- Apache Doris 4.0: One Engine for Analytics, Full-Text Search, and Vector Search (DEV Community)
- How We Built Production Vector Search in Apache Doris (VeloDB)
- [[ANNOUNCE] Apache Doris 4.1.1 Released (Apache mailing list)](http://www.mail-archive.com/[email protected]/msg11439.html)
- Apache Doris Roadmap 2026 (GitHub issue #60036)