49편 · 약 14분

OceanBase 4.6: 하이브리드 검색·벡터 인덱스·HTAP를 한 엔진에 몰아넣은 분산 SQL 업그레이드

왜 지금 봐야 하나

OceanBase V4.6.0_CE는 2026-07-17에 공개된 메이저 업그레이드다. 이번 릴리스가 중요한 이유는 단순히 벡터 검색 기능을 몇 개 더 붙였기 때문이 아니다. 분산 SQL 엔진이 하나의 제어면 안에서 OLTP, RAG 검색, HTAP 읽기, CDC 복구 경계를 동시에 넓히려 한다는 점이 더 중요하다.

기존 운영에서 이런 요구는 보통 서로 다른 시스템으로 흩어진다.

애플리케이션 트랜잭션은 MySQL 호환 OLTP 엔진
RAG 검색은 별도 벡터 DB + 전문 검색 엔진
분석 읽기는 컬럼 지향 엔진 또는 복제 계층
하류 동기화는 별도 CDC 파이프라인

OceanBase 4.6은 이 경계를 한 번에 좁히려 한다. 공식 릴리스 노트 기준으로 이번 버전은 다음 네 축을 동시에 밀었다.

HYBRID_SEARCH(TABLE ..., dsl_string) 기반의 네이티브 SQL 하이브리드 검색
HNSW 세그먼트화, heap table IVF, recall 리포트까지 포함한 벡터 인덱스 운영성
강일관성 컬럼 리드와 PX 개선을 포함한 HTAP 혼합 부하 처리
table-level restore 이후 증분 동기화와 generated column 계산을 포함한 OBCDC 복구 경계

즉, 이번 릴리스는 “OceanBase가 벡터 DB 기능도 있다” 수준이 아니라, 하나의 분산 SQL 엔진이 검색·분석·동기화를 어디까지 흡수할 수 있는지 운영 경계를 다시 그은 버전으로 읽는 편이 맞다.

OceanBase 4.6이 넓힌 제어면

OceanBase 4.6이 하나의 엔진 안으로 끌어들인 검색·벡터·HTAP·CDC 경계

1. `HYBRID_SEARCH`: 벡터·전문·JSON 검색을 SQL 문장 하나로 합친다

OceanBase 4.6의 가장 큰 변화는 DBMS_HYBRID_SEARCH 같은 패키지 호출이 아니라, SQL 문장 자체로 하이브리드 검색을 표현할 수 있게 됐다는 점이다. 공식 릴리스 노트는 새 문법을 SELECT ... FROM HYBRID_SEARCH(TABLE table_name, DSL_STRING)으로 설명한다.

SELECT doc_id, title, score
FROM HYBRID_SEARCH(
  TABLE kb_docs,
  '{
     "query": {"match_phrase": {"body": {"query": "redo log buffer", "slop": 1}}},
     "knn": {"field": "embedding", "query_vector": "[...]", "k": 20},
     "filter": {"term": {"tenant_id": 42}},
     "rank": {"rrf": {}},
     "size": 10
   }'
);

운영적으로 중요한 포인트는 세 가지다.

전문 검색과 벡터 검색이 같은 SQL 경로에 들어온다. query, knn, filter, rank, min_score 같은 요소를 같은 dsl_string 안에서 조합한다.
정렬 합성 로직이 엔진 안으로 들어온다. 공식 문서와 릴리스 노트는 RRF, WRRF, boolean 조합, top-level pagination을 지원한다고 설명한다.
복잡 타입 검색까지 같은 경로로 끌어들인다. Search Index는 JSON/ARRAY/MAP 경로 검색을 위해 추가된 범용 inverted index다.

여기서 단순한 “벡터 검색 추가”와 실제 운영 변화는 다르다. 중요한 것은 검색 플랜의 결합 위치가 애플리케이션 바깥으로 이동했다는 점이다. 그 전에는 보통 애플리케이션이 다음을 직접 조합했다.

벡터 후보 검색
전문 검색 후보 검색
스칼라 필터 적용
점수 합성 또는 재정렬

OceanBase 4.6은 이 순서를 엔진 내부의 search operator와 Query Profile 관측 경로로 당겨온다. 릴리스 노트가 docid 동적 pruning, block max score pruning, cost-driven iterator 선택, Query Profile 기반 진단을 강조하는 이유도 여기 있다. 검색 품질만이 아니라, 검색 플랜을 어디서 관측하고 병목을 어디서 찾을지를 SQL 엔진 쪽으로 옮긴 것이다.

같이 봐야 하는 제한도 있다.

match_phrase는 모든 전문 인덱스에 바로 되는 것이 아니라 FTS_INDEX_TYPE = PHRASE_MATCH 전제를 가진다.
Search Index는 1차 릴리스 기준으로 heap table 중심 경로다.
DSL이 강력해질수록 애플리케이션에서 조합하던 검색 semantics를 DB 레이어와 엄격히 맞춰야 한다.

즉, 4.6의 하이브리드 검색은 편의 기능이 아니라 RAG 검색 조합 지점을 미들웨어에서 SQL 엔진으로 재배치하는 변화다.

2. HNSW 세그먼트화와 recall 리포트: ANN을 “운영 가능한 인덱스”로 바꾼다

벡터 검색의 두 번째 축은 검색 품질보다 운영성이다. 릴리스 노트에 따르면 4.6은 HNSW 증분 경로를 Active/Frozen/Incr/Base의 네 세그먼트로 나누고, ob_vector_index_active_segment_max_size, ob_vector_index_merge_trigger_percentage로 메모리와 병합 임계를 제어하게 했다.

이 변화가 중요한 이유는 HNSW가 늘 같은 방식으로 망가지기 때문이다.

증분 쓰기가 누적될수록 메모리 사용량이 부풀고
인덱스 재시작 시간이 길어지고
질의 latency가 쓰기 패턴에 흔들린다

4.6은 여기에 세 가지 운영 장치를 추가한다.

세그먼트 수명 주기: Active → Frozen → Incr/Base로 분리해 flush/merge를 명시적으로 다룬다.
관리 API: dbms_vector.flush_index, dbms_vector.compact_index로 운영자가 수동 개입할 수 있다.
관측 뷰: GV$OB_HNSW_INDEX_SEGMENT_INFO로 세그먼트 상태를 본다.

이건 벡터 DB 관점에서 흔한 기능처럼 보여도, OceanBase 맥락에서는 다르게 읽어야 한다. 트랜잭션 DB 안에 들어온 ANN 인덱스를 일반 인덱스처럼 운영 문서화할 수 있게 만든 것에 가깝다.

또 다른 변화는 IVF가 heap table / 무주키 테이블까지 내려왔다는 점이다. 릴리스 노트는 IVF_flat과 IVF_pq가 무주키·heap table에 적용되고, HNSW/전문 인덱스와 함께 hybrid search 경로에 들어갈 수 있다고 설명한다. 이건 로그성 데이터, 이벤트 아카이브, 반정형 문서처럼 원래부터 기본키가 깔끔하지 않은 데이터셋에도 벡터 인덱스를 붙일 수 있다는 뜻이다.

대규모 IVF를 위한 HGraph도 실무적인 신호다. nlist > 5000에서 브루트포스 중심 탐색 대신 경량 그래프를 써서 후보 center 탐색 비용을 줄이겠다는 뜻이므로, OceanBase가 이제 단순한 “벡터 컬럼 지원”을 넘어서 대형 인덱스의 탐색 비용과 메모리 모형까지 다루기 시작했다고 볼 수 있다. 다만 릴리스 노트는 cosine 거리에서 특히 권장하고, L2에서는 큰 nlist에 주의하라고 못 박는다.

개인적으로 더 중요한 기능은 query_recall / index_recall과 DBA_VECTOR_INDEX_RECALL_REPORT다. 이유는 명확하다. ANN 운영에서 가장 어려운 것은 “지금 빠른데, 얼마나 틀리는지”를 계측하는 일인데, OceanBase는 이 문제를 엔진 안쪽 API와 리포트 뷰로 끌어들였다. 즉, 벡터 검색을 성능 기능이 아니라 SLO를 가진 데이터베이스 기능으로 다루기 시작한 것이다.

3. HTAP와 CDC까지 묶으면: 4.6의 진짜 메시지는 "검색 엔진 내장"이 아니다

하이브리드 검색과 벡터 인덱스만 보면 OceanBase 4.6을 “RAG용 DB 기능 확장”으로 오해하기 쉽다. 하지만 릴리스 전체를 보면 메시지는 더 크다.

HTAP 읽기 경계

공식 릴리스 노트는 다음을 한 묶음으로 둔다.

columnar replica의 intelligent routing
columnar replica에 대한 strong-consistent reads
columnar table의 automatic partition split
PX plan queue / adaptive task split / skip index
Append-Only table + Compaction TTL

이 조합은 분석 질의를 위한 별도 엔진을 무조건 늘리기보다, 같은 분산 SQL 엔진 내부에서 OLTP row path와 AP column path를 더 정교하게 갈라 쓰려는 방향으로 읽힌다. 운영자 입장에서는 “벡터 검색까지 들어오면 더 느려지는 것 아닌가?”가 자연스러운 질문인데, 4.6은 그 반대 질문을 던진다. 같은 엔진에 더 많은 workload를 넣되, 읽기 경로를 columnar replica와 PX로 분리해 감당할 수 있느냐는 것이다.

CDC 복구 경계

OBCDC 쪽 변화도 크다. 릴리스 노트는 다음 두 점을 명시한다.

table-level restore 이후 증분 데이터 동기화 지원
virtual generated column 실시간 계산으로 downstream MySQL binlog 호환성 보장

이건 단지 CDC 기능 확장이 아니라, 복구 이후 재동기화와 하류 호환성을 제어면에 올린 변화다. 운영에서 진짜 어려운 순간은 “백업에서 일부 테이블만 복구했는데 CDC를 어디서 다시 이어야 하는가?”인데, 4.6은 이 상황을 명시적으로 겨냥한다.

즉, 4.6의 큰 그림은 이렇다.

경계	4.5 이전에 흔했던 분리	4.6이 당겨오는 위치
검색 조합	앱 또는 별도 검색 서비스	`HYBRID_SEARCH` + Query Profile
ANN 유지보수	외부 벡터 DB 전용 운영면	HNSW segment + recall report
AP 읽기	별도 컬럼 엔진 또는 복제 계층	columnar replica + strong-consistent routing
CDC 복구	별도 런북과 수동 재개 절차	OBCDC restore-aware incremental sync

그래서 OceanBase 4.6의 핵심은 “벡터 기능 추가”보다 분산 SQL 엔진이 애플리케이션 플랫폼 쪽 경계를 얼마나 더 삼킬 수 있는지 보여준 버전이라는 데 있다.

4. 도입 전에 반드시 확인할 체크리스트

1) 검색 경계

hybrid search를 붙일 테이블이 heap table 제약에 걸리지 않는지 확인
기존 애플리케이션이 직접 하던 score fusion을 RRF/WRRF로 바꿔도 의미가 유지되는지 비교
match_phrase가 필요하면 전문 인덱스 타입을 PHRASE_MATCH로 설계하고 저장 공간 증가를 감수할지 판단

2) 벡터 인덱스 경계

쓰기 많은 HNSW에서 Active 세그먼트 메모리 상한과 merge trigger를 먼저 canary로 검증
GV$OB_HNSW_INDEX_SEGMENT_INFO와 recall 리포트를 운영 대시보드에 붙일지 결정
IVF를 heap table에 붙일 경우, 무주키 데이터셋의 DML/쿼리 패턴이 정말 ANN 이득을 주는지 확인
HGraph는 large-nlist cosine 시나리오에 맞는지 먼저 분리 검증

3) HTAP 경계

columnar replica strong-consistent read를 켠다고 해서 OLTP row path 비용이 자동으로 사라지는 것은 아니다. 쿼리 라우팅과 capacity isolation을 같이 봐야 한다.
PX queue / adaptive task split 개선이 실제 mixed workload에서 tail latency를 낮추는지는 staging replay로 확인

4) CDC / 복구 경계

table-level restore 이후 OBCDC 재개 절차를 restore drill에 포함
generated column이 하류 MySQL binlog 소비기와 정말 동일 semantics를 주는지 샘플 테이블로 재생 검증
RAG/검색 workload와 CDC backlog가 동시에 올라갈 때 같은 클러스터에서 자원 경합이 생기지 않는지 확인

어떤 팀이 먼저 볼 만한가

다음 조건 중 두세 개 이상이 겹치면 OceanBase 4.6은 바로 검토할 가치가 있다.

MySQL 호환 OLTP와 반정형 검색 요구가 한 서비스 경계 안에 같이 있는 팀
벡터 DB, 전문 검색, CDC, 분석 복제를 각각 따로 운영하는 비용이 커진 팀
RAG용 검색과 본 트랜잭션 데이터를 너무 멀리 떼어 놓고 싶지 않은 팀
복구 이후 CDC 재개와 하류 MySQL 호환성이 런북의 아픈 지점인 팀
분산 SQL 엔진 안에서 HTAP와 검색을 같이 넣어도 되는지 실험할 수 있는 팀

반대로, 이미 벡터 검색과 전문 검색, CDC, 분석 경로가 각자 최적화된 독립 플랫폼으로 잘 분리돼 있고, 장애 도메인도 의도적으로 분리하고 싶다면 4.6의 “all in one” 방향은 오히려 과할 수 있다. 이 경우에는 검색·벡터만 보고 들어가기보다 관측, 자원 격리, 복구 drill까지 함께 옮겨야 하는지를 먼저 따져보는 편이 안전하다.

Open question

공식 릴리스 노트는 하이브리드 검색과 벡터 인덱스 성능 향상을 강하게 강조하지만, 실제 mixed workload에서 OLTP tail latency와 어떤 교환 관계가 생기는지는 별도 재현 검증이 필요하다.
Search Index와 heap table 제약이 향후 row store 일반 경로까지 넓어질지 아직 더 지켜봐야 한다.
columnar replica strong-consistent read는 매력적이지만, 실제 장애 분리 관점에서 “한 엔진 안에서 다 처리하는 전략”이 항상 더 단순한지는 팀의 운영 모델에 따라 달라질 수 있다.
공식 릴리스 노트의 성능 수치(예: 전문 인덱스 빌드, lock-free allocator)는 벤더 측정이므로, 실서비스 전에는 대표 워크로드로 다시 재봐야 한다.

References

OceanBase, "V4.6.0_CE Release Notes" (GitHub release, published 2026-07-17). https://github.com/oceanbase/oceanbase/releases/tag/v4.6.0_CE
OceanBase Docs, "Overview | V4.6.0 | OceanBase Database". https://en.oceanbase.com/docs/common-oceanbase-database-10000000003684408
OceanBase Docs, "HYBRID_SEARCH | V4.6.0 | OceanBase Database". https://en.oceanbase.com/docs/common-oceanbase-database-10000000003683916
OceanBase Docs, "HNSW index | V4.6.0 | OceanBase Database". https://en.oceanbase.com/docs/common-oceanbase-database-10000000003679548
OceanBase Docs, "Vector index | V4.6.0 | OceanBase Database". https://en.oceanbase.com/docs/common-oceanbase-database-10000000003683575