OceanBase의 벡터 검색을 지원하는 기술: 고속화와 비용 절감

벡터 검색을 본 서비스 환경에서 사용하려면, 검색 속도 외에도 데이터가 증가했을 때의 확장성이나 운영 비용까지 고려해야 합니다. 수백만 건에서는 원활하게 작동하던 시스템이라도, 수억 건이 되면 응답 지연이나 메모리 부족에 대응하는 것이 과제가 됩니다.

OceanBase는 일상 업무를 지원하는 트랜잭션 처리와 의미 또는 유사도 기반의 벡터 검색을 하나의 데이터베이스에서 다룰 수 있습니다. 데이터를 여러 서버에 분산하는 구조와 자체 개발한 벡터 검색 라이브러리인 "VSAG"를 결합하여, 데이터 증가에 대응하면서 검색 성능과 비용 효율성을 동시에 달성합니다.

그 기반에는 업무 처리나 분석 처리의 성능을 측정하는 TPC 벤치마크에서 세계 기록을 달성한 분산 데이터베이스 엔진이 있습니다. 벡터 검색에서도 약 10억 건 규모의 데이터를 다루는 본 서비스 환경에서 운영되고 있습니다. 본 기사에서는 이러한 성능을 뒷받침하는 구조와 구성 선택 시 고려할 점들을 소개합니다.

데이터가 늘어나도 같은 기반으로 검색 지속하기

업무용 데이터베이스 외에 벡터 데이터베이스를 별도로 도입하면, 관리해야 할 시스템이 늘어납니다. 업무용 데이터베이스의 SQL이나 메모리 설정 외에도, 벡터 검색 인덱스나 메모리 사용량 역시 각 제품에 맞춰 조정할 필요가 있습니다.

더 나아가, 단일 노드에서 처리 가능한 용량을 초과하는 경우, 구성에 따라 애플리케이션 측에서 데이터 분산 위치를 관리하고 여러 노드로 검색을 분배해야 할 수도 있습니다. 검색 결과를 반환할 때도, 각 노드가 찾은 후보들을 취합하여 전체적으로 유사도가 높은 순서로 재정렬하는 처리가 필요합니다.

OceanBase에서는 벡터 데이터와 인덱스 역시 일반 테이블과 동일한 방식으로 분산 관리합니다. 벡터 검색과 트랜잭션 처리는 실행 엔진을 공유하며, SQL 옵티마이저가 처리 과정을 최적화합니다. PoC(개념 증명)에서 본 서비스 운영으로 전환되어 데이터 규모가 커져도, 같은 기반 위에서 운영을 지속할 수 있습니다. 데이터 규모나 필요한 검색 정밀도에 맞춰 인덱스를 선택함으로써 메모리 사용량 증가도 억제할 수 있습니다.

네이티브 분산 설계를 통한 Scale-out

OceanBase와 많은 전용 벡터 데이터베이스의 차이는 우선 아키텍처에서 나타납니다.

일부 벡터 데이터베이스는 애플리케이션 측에서 검색 요청을 각 샤드(shard)에 분배하여 처리합니다. 이 방식에서는 운영 시작 후 샤딩 정책 변경이 어렵고, 샤드를 넘나드는 검색 결과 취합이나 각 인스턴스의 개별 관리도 필요합니다.

OceanBase는 분산 처리를 전제로 설계된 데이터베이스입니다. 벡터 데이터와 인덱스는 파티션(partition)별로 클러스터 내 노드에 자동으로 배치됩니다. 검색 시에는 각 파티션에서 ANN(Approximate Nearest Neighbor, 근사 최근접 이웃) 검색을 병렬로 실행하고, 각각의 Top-K 후보들을 취합하여 전체 순위를 결정합니다. 이러한 처리 과정은 OceanBase가 수행하므로, 애플리케이션 측에서 제어할 필요가 없습니다.

노드나 파티션을 추가함으로써 시스템 전체의 검색 처리량(throughput)을 향상시킬 수 있습니다. 애플리케이션 코드 변경이나 서비스 중단이 불필요합니다. 다만, 실제 QPS(Queries Per Second, 초당 질의 건수)는 파티션 수, 파티션 프루닝(pruning)의 유효성, 필터 조건에 의한 축소 정도 등에 영향을 받습니다. 검색 대상이 많은 파티션을 넘나드는 경우, 결과 취합에 추가 비용이 발생합니다. 따라서 예상하는 검색 조건으로 응답 시간과 QPS가 요구 사항을 충족하는지 여부를 파티션 키 설계와 함께 확인해야 합니다.

밀집 벡터(dense vector) 인덱스는 주로 HNSW와 IVF 중에서 선택할 수 있습니다. HNSW는 메모리 상에서 빠르게 검색하며, 낮은 지연 시간(low latency)과 높은 처리 성능을 중시하는 용도에 적합합니다. IVF는 디스크를 활용하여 모든 벡터를 메모리에 유지하지 않고 더 대규모의 데이터를 다룰 수 있습니다.

| 데이터 규모 예상 | 예상되는 용도 | 권장 구성 |
|---|---|
| 수천만 건 규모 | 중견/대기업 이용. 수십만~수천만 건 | HNSW / HNSW_SQ / HNSW_BQ. 필요한 재현율과 메모리 용량에 따라 선택 |
| ... |
구성 검토 시에는 공식 문서의 벡터 인덱스 베스트 프랙티스를 참조해 주십시오. 필요한 메모리 용량 추정은 INDEX_VECTOR_MEMORY_ADVISOR 함수를 이용할 수 있습니다. 인덱스나 파티션 구성에 대해서는 OceanBase 기술 지원팀에도 문의하실 수 있습니다.

VSAG: 벡터 검색을 고속화하는 방법

데이터 분산을 통해 대규모 검색을 지탱하는 것이 OceanBase의 아키텍처라면, 각 노드에서의 검색을 고속화하는 것이 VSAG입니다.

VSAG는 오픈소스 벡터 검색 라이브러리입니다. HNSW와 IVF를 지원하며, 용도에 따라 Flat, SQ8, PQ, BQ 등과 조합하여 사용할 수 있습니다. 높은 재현율(reproducibility)을 중시할 경우 HNSW가, 대규모 데이터에서 메모리 사용량을 줄이고 싶을 경우에는 IVF_PQ가 선택지가 됩니다.

검색에 사용하는 거리/유사도 지표로는 맨해튼 거리(L1), 유클리드 거리(L2), 내적, 코사인 유사도를 이용할 수 있습니다. 또한, 밀집 벡터(dense vector)와 희소 벡터(sparse vector) 모두를 지원합니다.

검색 정확도를 유지하면서 처리 건수를 늘리기

벡터 검색 성능을 비교할 때는 검색 속도와 재현율을 함께 봐야 합니다.

VSAG는 벡터 검색 벤치마크인 'ANN-Benchmarks'의 gist-960 데이터셋에서, 재현율 96.7%를 유지하면서 당시 최고 성능을 보이던 Glass보다 90% 높은 QPS(Queries Per Second)를 기록했습니다. 이 조건에서는 당시 최첨단 수준의 검색 성능을 보여준 것입니다. 즉, 같은 하드웨어에서 검색 정확도를 유지하면서 더 많은 요청을 처리할 수 있다는 의미입니다. 같은 QPS를 목표로 할 경우 계산 리소스를 약 절반으로 줄일 수도 있습니다.

이 결과는 특정 공개 데이터셋으로 측정된 것입니다. 실제 운영 환경의 성능은 벡터 차원 수, 데이터 분포, 인덱스 설정에 따라 달라지므로 실제 데이터와 검색 조건에서 확인해야 합니다.

VSAG는 ARM 지원 외에도 IVF 인덱스나 BQ 양자화의 단일 노드에서의 성능 개선도 진행하고 있습니다. x86과 ARM 환경 모두에서 높은 성능을 발휘할 수 있도록 최적화를 진행하고 있습니다.

SQL과 벡터 검색을 통합적으로 최적화하기

VSAG는 OceanBase 내부에서 SQL 엔진과 동일한 메모리 풀 및 스레드 풀을 사용합니다. 벡터 검색을 위해 별도의 프로세스를 호출할 필요가 없어, 메모리나 CPU 할당도 데이터베이스 내에서 일괄 관리할 수 있습니다. 이를 통해 프로세스 간 통신이나 개별적인 메커니즘으로 리소스를 확보할 때 발생하는 경합(contention)을 줄일 수 있습니다.

옵티마이저는 벡터 검색, 일반 컬럼 값에 의한 필터링, 테이블 조인(JOIN)을 일련의 처리로 취급합니다. 각각에 필요한 처리 비용을 추정하고 어떤 순서로 실행할지 결정합니다. 예를 들어, 조건으로 후보군을 줄인 후에 벡터 검색을 하는 것이 더 효율적이라면 그 순서를 선택할 수 있습니다.

이처럼 SQL과 벡터 검색을 같은 엔진에서 실행함으로써 쿼리 전체를 최적화할 수 있습니다. 업무용 데이터베이스와 외부의 벡터 데이터베이스를 결합하는 경우에는, 양쪽의 처리 순서나 데이터 전달 방식을 애플리케이션 측에서 조정해야 합니다.

조건 필터링과 벡터 검색을 조합하기

실제 서비스에서는 단순히 '비슷한 것'을 찾는 것만으로는 부족합니다. 예를 들어 상품 검색이라면, '지정된 매장에서 취급하는 특정 카테고리의 상품' 중에서 사용자 입력 내용과 의미가 가까운 것을 찾고 싶을 수 있습니다. 이런 검색에서는 일반 컬럼 값에 의한 필터링과 벡터를 이용한 유사도 검색을 조합합니다.

OceanBase의 옵티마이저는 처리 비용을 추정한 후, 다음 두 가지 방식을 활용합니다.

• pre_filter: 먼저 조건으로 대상을 좁힌(필터링) 후, 그 범위 내에서 벡터 검색을 수행합니다.
• post_filter: 먼저 벡터 검색으로 후보군을 찾은 후, 그 후보군에 조건을 적용합니다.

조건에 의해 대상이 크게 줄어들 수 있는 경우에는, 미리 필터링하여 불필요한 벡터 계산을 생략할 수 있습니다. 그다지 많이 줄어들지 않는 경우에는, 벡터 검색을 먼저 수행하는 방법도 고려하여 재현율과 레이턴시를 고려한 실행 방식을 선택합니다. VECTOR_INDEX

힌트를 사용하여 명시적으로 지정할 수도 있습니다.

전체 텍스트 검색과 벡터 검색 결과를 결합하는 하이브리드 검색에는 HYBRID_SEARCH

SQL 인터페이스를 이용할 수 있습니다. 단일 쿼리로 여러 검색 결과를 통합할 수 있으며, 밀집 벡터와 희소 벡터 모두를 활용할 수 있습니다.

양자화로 메모리/스토리지 비용 줄이기

데이터가 증가했을 때의 비용을 좌우하는 것은 벡터 한 개당 필요한 메모리와 스토리지입니다. 양자화(Quantization)는 벡터를 더 적은 비트 수로 표현하여 데이터 크기를 줄이는 기술입니다. 필요한 검색 정확도와의 균형을 맞추면서 사용 리소스를 절약합니다.

• HNSW_BQ: 높은 압축률을 실현하는 양자화 방식입니다. 768차원 표준 데이터셋에서는 최대 약 99%의 재현율을 달성할 수 있습니다. 실제 재현율은 ef_search

또는 refine_k

などのパラメータに依存します。
HNSW_SQ / IVF_PQ：数億～数十億件規模で、再現率とコストのバランスを調整できます。1,000万件・768次元の構成では、HNSW_SQの推奨テナントメモリは約48 GBで、HNSWの約160 GBから大幅に削減できます。

配送サービスのLalamove（ララムーブ）は、本番環境でHNSWの量子化による圧縮を採用しています。単一のパーティションで業務要件を満たし、アプリケーション側でデータベースやテーブルを分割する必要はありませんでした。データ量の増加に備え、今後は量子化を利用したIVF系インデックスに移行し、メモリ使用量をさらに抑える計画です。同社の事例では、インデックスの再構築にかかる時間は約25分とされています。

TPC 세계 기록과, 본번 운영을 지탱하는 가용성

벡터 검색을 지지하는 OceanBase의 분산 데이터베이스 엔진은 업무 처리와 분석 처리 양쪽에서 실적을 보유하고 있습니다. 그중 하나가, 데이터베이스의 성능을 측정하는 TPC 벤치마크입니다.

• TPC-C：수발주 등의 트랜잭션 처리를 평가하는 벤치마크입니다. OceanBase는 2020년에 7.07억 tpmC를 기록하며, 당시 세계 기록을 경신했습니다. -
  TPC-H：대량의 데이터를 집계·분석하는 처리를 평가합니다. OceanBase는 2021년에 1,526만 QphH@30000GB를 기록하여, 세계 기록을 달성했습니다.

이것들은 벡터 검색 자체의 측정 결과는 아니지만, 검색을 지지하는 엔진이 트랜잭션 처리와 대규모 분석 처리에 모두 대응할 수 있음을 보여줍니다.

가용성에 대해서는, 3개의 지역에 5개의 데이터센터를 배치하는 구성으로 RPO = 0、RTO < 8초를 실현합니다. RPO는 데이터를 어느 시점까지 복구시킬지, RTO는 얼마나 짧은 시간 안에 복구시킬지를 나타내는 목표입니다. 이 구성에서는, 데이터 손실을 제로에 가깝게 줄이고, 8초 미만에서의 복구를 실현합니다. 벡터 데이터와 업무 데이터 양쪽을 같은 메커니즘으로 보호할 수 있습니다.

2025년 8월 시점에서는, OceanBase는 DB-Engines의 벡터 데이터베이스 순위에서 8위에 올랐으며, Multi-model로 분류되었습니다. 이는 당시의 순위입니다. 제품을 선택할 때는, 최신 공개 벤치마크나 PoC 결과를 함께 확인해 주십시오.

본번 환경에서의 도입 사례

Trip.com 그룹: 약 10억 건의 이미지 벡터 안정 운영

여행 예약 서비스를 전개하는 Trip.com 그룹에서는, Ctrip이 호텔 이미지 벡터 약 10억 건을 OceanBase로 이전했습니다. 기존 Elasticsearch와 Faiss를 조합한 구성을 대체하고, 사례 보고 시점까지, 가동 시작 후 약 1년간 장애 없이 운영하고 있습니다.

IVF 인덱스와 코사인 거리를 채택하여, 384차원의 벡터를 location 필드에서 3,000개의 파티션으로 분할했습니다. 조건에 의한 검색을 조합한 검색에 대응하며, 인덱스 구축 속도는 기존 대비 약 4배 향상되었습니다. 매일 수백만 건의 차분 업데이트도 처리하고 있습니다.

OceanBase로 통합함으로써, Elasticsearch와 Faiss를 각각 운영하며 용량이나 부하에 따라 개별적으로 확장해야 하는 번거로움이 사라졌습니다. 가용성 확보와 SQL을 통한 개발 역시 하나의 데이터베이스에서 대응할 수 있습니다.

Lalamove: 두 개의 데이터베이스를 통합하여 접근 증가에도 대응

Lalamove는 이전, 벡터 검색에 Weaviate, 업무 데이터에 관계형 데이터베이스를 사용하고 있었습니다. 동시 접속자가 늘어나면 장애가 빈번하게 발생했고, 장애 시 처리를 정상 노드로 자동 전환하는 것도 어려운 상황이었습니다.

OceanBase로 통합한 후에는, 고부하에서도 안정적으로 가동하고 있습니다. 벡터 검색과 대규모 언어 모델은, 장애나 손실로 이어질 수 있는 코드를 감지하는 메커니즘이나, 데이터 웨어하우스 관련 질문에 AI가 답변하는 메커니즘에 활용되고 있습니다.

장애 시에는, 여러 노드 간의 데이터 정합성을 유지하는 Paxos를 기반으로 자동 복구를 수행합니다. 백업과 리스트어 기능도 이용하며, 장애 대응력을 높이고 있습니다. 향후에는, Milvus 등 다른 벡터 데이터베이스도 단계적으로 OceanBase로 이전할 계획입니다.

Weaviate 클러스터를 개별적으로 관리하는 부담이 사라진 것에 더해, HNSW의 양자화에 의한 압축으로, 같은 규모의 데이터를 더 적은 메모리로 다룰 수 있게 되었습니다.

OceanBase의 강점은 데이터 규모에 따라 확장 가능하다는 점, SQL과 벡터 검색을 통합하여 최적화할 수 있다는 점, 그리고 인덱스 선택을 통해 메모리와 스토리지 비용을 조정할 수 있다는 것입니다. 벡터 검색 역시 업무 데이터와 공통의 가용성(availability) 구조를 사용할 수 있어 다음과 같은 요구사항이 있는 경우에 적합합니다.

• 벡터 데이터가 수백만 건에서 수억 건, 장기적으로는 수백억 건으로 증가할 것으로 예상되는 경우
• 조건 기반 필터링이나 전문 검색(full-text search)과 벡터 검색을 결합하여 낮은 지연 시간(low latency)으로 응답하고 싶은 경우
• 금융, 거래, 리스크 관리, EC의 핵심 시스템 등 일관성(consistency) 및 고가용성에 명확한 요구사항이 있는 경우
• 벡터 검색과 SQL 튜닝을 공통된 기반 위에서 진행하고 싶은 경우

비교 검증에는 벡터 데이터베이스 성능 측정 도구인 'VectorDBBench'도 활용할 수 있습니다. OceanBase가 공개한 테스트 절차에서는 100만 건/768차원, 50만 건/1,536차원 등의 데이터를 사용하여, 순수 벡터 검색 케이스와 조건 기반 필터링을 동반하는 케이스(필터율 1%·99%)를 비교하고 있습니다. 이는 자사 검색 조건과 유사한 케이스를 선택할 때 참고가 될 수 있습니다. 자세한 내용은 공식 웹사이트의 VectorDBBench 관련 테스트 절차를 확인해 주십시오.

내부 PoC나 수백 건 정도의 벡터를 사용한 검증이라면 다양한 제품을 활용할 수 있습니다. 하지만 장기적으로 수천만 건 이상을 다루고 벡터 데이터와 업무 데이터를 운영해야 한다면, 검색 속도뿐만 아니라 확장 시 작업 용이성, 일상적인 운영 방식, 필요한 메모리 용량까지 포함하여 비교하는 것이 중요합니다. 이러한 관점을 중시한다면 OceanBase는 고려해 볼 만한 선택지라고 할 수 있습니다.

Discussion