우리는 벡터 데이터베이스를 더 빠르게 만드는 데 8년을 보냈습니다. 그러고는 멈췄습니다.
비용은 중요합니다. 늘 그래왔습니다. 하지만 순서가 있습니다. 성능 기준을 충족한 뒤에야 비용을 줄일 수 있습니다. 저렴하지만 잘못된 결과를 반환하는 시스템은 유용하지 않습니다. 부하가 걸렸을 때 지연 시간을 억제하지 못하는 시스템도 마찬가지입니다.
Milvus는 2019년에 단순한 믿음과 함께 오픈소스로 공개되었습니다. 벡터 데이터베이스는 애플리케이션 안에 숨겨진 기능이 아니라 핵심 데이터 인프라가 될 것이라는 믿음이었습니다. 8년이 넘는 시간 동안 그 믿음은 우리를 한 방향으로 이끌었습니다. 벡터 검색을 더 빠르고 더 예측 가능하게 만드는 것이었습니다. 인덱스 압축, 세그먼트 스케줄링, HNSW 튜닝, 프리페치 전략 — 거의 모든 주요 최적화는 같은 목표를 향했습니다. 데이터를 로컬 캐시에 올리고 더 빠르게 검색하는 것입니다.
그 작업은 여전히 기반입니다. 항상 켜져 있는 서빙은 높은 QPS와 낮은 지연 시간이 필요한 벡터 검색 워크로드에 적합한 아키텍처입니다. 컬렉션이 지속적으로 쿼리된다면 인덱스를 메모리에 상주시켜 두는 것은 낭비가 아닙니다. 제품 경험을 제공하기 위한 비용입니다.
그다음 우리는 비용에 눈을 돌렸습니다. 계층형 스토리지는 도움이 되었습니다. 핫 세그먼트는 메모리에, 콜드 데이터는 디스크와 오브젝트 스토리지에 두면서 실제 비용 절감이 가능했습니다. 하지만 노드는 꺼지지 않았습니다. 한 달에 다섯 시간만 실행되는 워크로드라도 나머지 715시간에 대한 비용을 계속 지불해야 했습니다.
그 간극은 새로운 Zilliz Vector Lakebase가 해결하도록 설계된 문제 중 하나입니다. 더 큰 변화는 단순히 “벡터 검색을 더 저렴하게 만드는 것”이 아닙니다. 지속적인 시맨틱 데이터가 하나 이상의 컴퓨트 수명 주기를 지원할 수 있게 하는 것입니다. 지연 시간과 처리량이 중요할 때는 항상 켜져 있는 서빙을 사용하고, 데이터는 계속 쿼리 가능해야 하지만 한 달 내내 전용 머신을 실행할 필요가 없을 때는 온디맨드 컴퓨트를 사용하는 것입니다.
항상 켜져 있는 서빙 모델 뒤의 물리적 현실
S3 읽기 지연 시간은 요청당 20~50ms입니다. HNSW 그래프 탐색은 쿼리마다 수백 개의 노드에 접근합니다. 이 두 숫자를 함께 놓으면 결론은 분명합니다. 쿼리를 처리하려면 벡터 인덱스가 로컬 메모리에 있어야 합니다. 설계 결함이 아니라 물리적 현실입니다.
구체적으로 보겠습니다. 1억 개의 벡터, 768차원, float32입니다. 원시 벡터 데이터는 약 286GB이고, HNSW 그래프(M=48)는 이웃 링크로 약 55GB를 추가합니다. 총 약 340GB입니다.
전통적인 Milvus QueryNode 모델:
┌──────────────────────────────────────────────────────────────┐
│ Traditional Milvus architecture │
│ │
│ 100M × 768-dim float32 → ~340 GB split across 3 QueryNodes │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ QueryNode 1 │ │ QueryNode 2 │ │ QueryNode 3 │ │
│ │ 128GB RAM │ │ 128GB RAM │ │ 128GB RAM │ │
│ │ + NVMe │ │ + NVMe │ │ + NVMe │ │
│ │ seg 0-99 │ │ seg 100-199 │ │ seg 200-299 │ │
│ │ (~113 GB) │ │ (~113 GB) │ │ (~113 GB) │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ load() │ load() │ load() │
│ └─────────────────┼─────────────────┘ │
│ ▼ │
│ ┌───────────────────────┐ │
│ │ S3 (source of truth) │ │
│ │ 340 GB full dataset │ │
│ └───────────────────────┘ │
│ Collection queryable only when all 340 GB are loaded │
│ Node fails → its segments go dark → reload from S3 │
└──────────────────────────────────────────────────────────────┘
컬렉션이 쿼리 가능해지려면 모든 세그먼트에 상주 노드가 필요합니다. 340GB의 데이터, 128GB 머신 3대가 24시간 내내 실행됩니다. 자주 쿼리되는 컬렉션에는 이 방식이 잘 작동합니다. 그러다 AI가 수요 패턴을 바꿨습니다.
제품 팀은 2주짜리 A/B 실험을 실행하고, 그 이후에는 해당 임베딩을 다시 조회하지 않습니다. SaaS 제품에서는 사용자의 90%가 지난주에 로그인하지 않았습니다. RAG 지식 베이스에서는 문서의 80%가 지난 한 달 동안 검색되지 않았습니다. 데이터가 쓸모없는 것은 아닙니다 — 언제든지 조회될 수 있습니다 — 하지만 거의 조회되지 않습니다. 전통적인 데이터베이스는 이를 티어링으로 처리합니다: 핫 데이터는 메모리에, 콜드 데이터는 디스크에 두고, 필요할 때 페이지인합니다. 벡터 데이터베이스에는 그런 개념이 없었습니다. 전체 컬렉션을 로드하거나, 아니면 조회할 수 없거나 둘 중 하나였습니다.
AI 생성 임베딩이 널리 퍼지기 전에는, 그 이분법이 문제가 아니었습니다. 대부분의 벡터 워크로드는 인덱스를 메모리에 상주시켜 두는 것이 합리적인 명확한 온라인 서빙 시스템이거나, 맞춤형 파이프라인을 감수할 수 있는 오프라인 실험이었습니다. AI가 그 중간 지대를 바꿨습니다.
우리는 고객과의 대화에서 이러한 변화를 보기 시작했습니다. 임베딩은 더 이상 프로덕션 RAG 챗봇만 구동하는 것이 아니었습니다. 한 글로벌 GPU 선도 기업은 자율주행 데이터를 임베딩하고 있었습니다 — 카메라 프레임, 주행 세션, 날씨, 위치, 타임스탬프, 기타 메타데이터 — 엔지니어들이 수백억 개의 벡터에서 드문 주행 시나리오를 마이닝할 수 있도록 하기 위해서였습니다. 한 교육 기술 회사는 다국어 표절 탐지를 위해 의미 검색을 사용하고 있었는데, 시험 기간에는 워크로드가 소수의 문서에서 배치당 10,000개 이상의 문서로 급증할 수 있었습니다.
이것이 Vector Lakebase의 맥락입니다. AI 팀들은 영속적으로 유지되고 발견 가능해야 하는 비정형 데이터를 축적하고 있지만, 접근 패턴은 고르지 않습니다. 어떤 경로는 지속적인 서빙이 필요합니다. 다른 경로는 동일한 기반 데이터에 대한 가끔의 검색, 탐색, 또는 배치 발견이 필요합니다. 이 모든 경로를 항상 켜져 있는 서빙으로 취급하면 너무 많은 인프라가 유휴 상태로 남습니다.
한 사용자가 우리 커뮤니티 Slack에 게시했습니다:
"내 임베딩은 이미 S3에 있습니다. 그런데 가끔 쿼리를 실행하기 위해, 임포트하는 데 세 시간을 쓰고, 128 GB RAM을 가진 머신 세 대를 24/7 계속 실행하며, 연간 $24,000를 내야 한다는 말인가요?"
그가 옳았습니다. 문제는 데이터가 어디에 있느냐도, 인덱스가 충분히 빠르냐도 아니었습니다. 그는 콜드 데이터 접근 패턴에 대해 핫 데이터 가격을 지불하고 있었습니다: 0.7% 활성, 100% 과금.
시장은 이미 객체 스토리지 우선 경제성이 벡터 워크로드에 중요하다는 것을 증명하기 시작했습니다. 그리고 객체 스토리지 위에 무상태 컴퓨트를 유지하는 것은 많은 사용자가 원하던 방향이었습니다. 하지만 우리에게 더 어려운 질문은 그 비용 모델을 완전한 벡터 데이터베이스로 어떻게 가져올 것인가였습니다: 필터링된 검색, 데이터베이스 시맨틱스, 운영적 격리, 그리고 워크로드가 뜨거워질 때 항상 켜져 있는 서빙으로 다시 연결되는 경로까지 포함해서 말입니다.
이것이 우리의 Vector Lakebase 논제입니다: 의미 데이터를 영속적으로 유지하고, 컴퓨트 계층이 워크로드에 맞게 하라. 온디맨드 검색은 그 아키텍처의 한 표현입니다. 이를 제대로 구현하려면 네 가지 기술적 장애물을 제거해야 했습니다.
Lakebase 온디맨드 검색의 네 가지 장벽
Lakebase 온디맨드 검색 모델에서는 QueryNode가 필요할 때 스핀업되어 쿼리를 처리한 다음 해제됩니다. 데이터는 진실의 원천으로 객체 스토리지에 남아 있습니다. 컴퓨트는 쿼리 세션 사이에 0까지 확장됩니다. 단순하게 들리지만, 이를 사용 가능하게 만들려면 콜드 스타트 지연 시간, 스캔 볼륨, 검색 중 I/O 증폭, 그리고 컨트롤 플레인 고정 비용을 해결해야 했습니다.
콜드 스타트가 너무 느렸습니다
340 GB의 HNSW 인덱스. S3에서 로드: 4분 이상. 4분의 콜드 스타트는 모든 온디맨드 사용 사례를 망칩니다. 사용자가 쿼리를 실행하고 4분을 기다립니다 — 그것은 지연이 아니라, 고장 난 제품입니다.
해결책은 인덱스를 사용 가능하게 유지하면서 압축하는 것이었습니다. 우리는 RabitQ (Gao & Long, 2024)를 기반으로 1+3-bit 마트료시카 양자화를 구축했습니다. 마트료시카 인형처럼 중첩된 두 계층입니다.
1-bit 계층이 먼저 로드됩니다 — 340 GB 대신 13 GB입니다. 검색은 즉시 그 위에서 실행됩니다: RabitQ는 1-bit 거리의 증명 가능한 오차 한계를 제공하므로, 후보를 안전하게 가지치기하고 진짜 top-k에 포함되는 어떤 것도 누락되지 않도록 보장할 수 있습니다. 첫 쿼리에서 85–90% 재현율입니다.
3비트 레이어는 1비트 검색이 실행되는 동안 백그라운드에서 다운로드됩니다. 준비되면 정제 패스로 사용됩니다 — 1비트 단계에서 살아남은 후보들이 전체 1+3비트 정밀도로 다시 점수화됩니다. 재현율은 95%+로 올라갑니다. 두 레이어는 대안이 아닙니다. 내부 레이어는 필터링을 수행하고, 외부 레이어는 결과를 개선합니다.
원시 양자화 처리량은 대규모 환경에서 병목입니다. GPU 가속 인덱스 빌드와 AVX512 / ARM SVE 쿼리 커널은 거리 계산 처리량을 양자화 오버헤드가 무시할 수 있는 수준까지 끌어올립니다. 두 가지 추가 개선은 재현율을 더 높입니다: 각 벡터가 전역 계수를 공유하는 대신 자체 양자화 오류를 최소화하는 벡터별 최적 스케일링, 그리고 분산을 기반으로 차원 전반에 걸쳐 비균일 비트 할당을 적용해 정보 밀도가 높은 차원에 더 많은 비트를 부여하는 것입니다. 둘 다 인덱스 크기를 늘리지 않고 양자화 오류를 직접 줄입니다.
첫 번째 장애물을 넘었습니다. 하지만 완전한 양자화를 적용해도 100M 벡터를 스캔하는 것은 여전히 비용이 큽니다.
100M 벡터 스캔
1비트 인덱스는 작지만, 100M 벡터에 대한 거리 계산은 여전히 선형입니다. 온디맨드 모델에서는 이것이 누적됩니다: 계산 시간이 길어질수록 QueryNode가 더 오래 상주해야 하며, 이는 탄력적 해제를 위한 시간을 줄입니다.
글로벌 인덱스 프루닝을 갖춘 IVF 클러스터링(버킷 수는 데이터 볼륨에 따라 확장):
┌──────────────────────────────────────────────────────────────┐
│ 글로벌 인덱스 + IVF 프루닝 │
│ │
│ 100M 벡터 → IVF 클러스터링 (N개 버킷, N은 │
│ 데이터 볼륨에 따라 확장) │
│ │
│ ┌───┬───┬───┬───┬───┬───┬───┬───┬─── ··· ───┬───┐ │
│ │ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ 7 │ 8 │ │ N │ │
│ └───┴───┴───┴───┴───┴───┴───┴───┴─── ··· ───┴───┘ │
│ ▲ ▲ ▲ │
│ █ █ █ ← 약 3%만 스캔 │
│ │
│ 쿼리 q → 가장 가까운 중심점 찾기 → 해당 버킷 검색 │
│ │
│ 스캔되는 데이터: 전체의 약 3% │
│ S3 I/O: 데이터의 약 3% 가져오기 │
│ 계산: 약 3%에 대해서만 거리 계산 │
└──────────────────────────────────────────────────────────────┘
IVF는 새로운 것이 아니지만, 두 가지 점이 우리의 것을 다르게 만듭니다.
첫째, 규모입니다. 대부분의 IVF 구현은 인덱스를 구축하려면 모든 것을 한 번에 메모리에 로드해야 하기 때문에 십억 벡터 규모에서 무너집니다. 우리는 클러스터링 작업을 노드들에 샤딩하는 분산 인덱스 구성을 만들었습니다 — 수십억 벡터를 포함한 어떤 규모에서도 가능한 IVF입니다.
둘째, Lakebase와의 상호작용입니다. 쿼리 시점에는 관련 버킷만 S3에서 가져옵니다. 클러스터의 약 3%를 프로브하고, 데이터의 약 3%를 가져오며, QueryNode 메모리에 약 3%만 보관합니다. 데이터셋의 3%만 로드한 노드는 쿼리가 완료된 직후 거의 즉시 회수될 수 있습니다.
1비트 양자화와 함께 두 장벽은 복합적으로 작용합니다: 340 GB → 13 GB(양자화) → 쿼리당 약 400 MB(IVF 프루닝). 콜드 스타트는 클러스터 중심점과 1비트 인덱스 메타데이터만 로드합니다 — 5–10초. 이후 각 쿼리는 전체 13 GB가 아니라 관련 버킷만 가져옵니다.
두 번째 장애물을 넘었습니다.
Retrieve가 S3 I/O를 증폭하고 있었습니다
벡터 검색은 원시 데이터가 아니라 ID를 반환합니다. 원본 벡터나 스칼라 필드를 가져오려면 두 번째 읽기 라운드가 필요하며, 스토리지 네이티브 쿼리 경로에서는 각각이 S3 포인트 읽기입니다.
문제는 스토리지 형식이었습니다. 표준 Parquet 파일은 64 MB 행 그룹을 사용합니다. 단일 벡터 레코드는 약 3 KB입니다. 이를 읽는다는 것은 전체 행 그룹을 다운로드한다는 뜻입니다: 유용한 데이터 3 KB, 실제 I/O 64 MB — 약 20,000배 증폭입니다. 로컬 디스크에서는 견딜 만합니다. S3에서는 가혹합니다.
Storage V2는 그중 절반을 해결했습니다. 넓은 컬럼과 좁은 컬럼을 분리하고, 벡터와 스칼라 필드를 독립적으로 저장하며, row group을 1 MB로 줄였습니다 — 증폭이 64배 감소한 것입니다. 문제는 Parquet의 블록 수준 압축이 큰 row group에 의존한다는 점입니다. 이를 줄이면 압축 효율이 떨어지고, 파일은 더 커집니다. Parquet에서는 작은 row group과 좋은 압축을 동시에 얻을 수 없습니다. 바로 이 지점에서 Vortex가 등장합니다.
Spiral이 개발하고 Linux Foundation이 호스팅하는 Vortex는 강제된 row group 구조가 없는 완전 구성 가능한 레이아웃을 갖추고 있습니다. Delta → RLE → BitPacking 중첩 인코딩을 통해 압축된 데이터에 대해 직접 포인트 쿼리를 수행할 수 있어 압축 해제가 필요 없습니다. 또한 BtrBlocks 알고리즘을 기반으로 압축률, 인코딩 속도, 디코딩 속도의 균형을 맞추는 자동 인코딩 선택 기능을 제공합니다.
벤치마크: 300만 행, 128차원 벡터, S3, 동시 reader 256개, read당 10행 배치.
| 지표 | Parquet | Lance | Vortex |
|---|---|---|---|
| 포인트 read 처리량 (reads/s) | 162 | 464 | 620 |
| read당 S3 바이트 (MB) | 9.44 | 0.006 | 0.07 |
| 행당 S3 GET | ~2 | ~5 | ~2 |
| 전체 scan 처리량 (MB/s) | 638 | 730 | 1,548 |
| write 처리량 (MB/s) | 216 | 247 | 244 |
Parquet는 read당 9.44 MB를 다운로드합니다 — 전체 row group입니다. Lance는 512바이트 단위로 읽어 이를 0.006 MB까지 낮추지만, 그 대가로 IOPS를 지불합니다. 행당 S3 GET이 다른 경우의 ~2회인 데 비해 ~5회입니다. Vortex는 행당 ~2 GET으로 0.07 MB에 도달합니다 — IOPS 페널티 없이 Parquet보다 트래픽이 135배 적습니다. 전체 scan 처리량은 Parquet보다 2.4배 높고, write는 비슷합니다.
세 번째 장애물을 넘었습니다.
Control plane 비용은 0으로 확장되지 않았습니다
처음 세 가지 변경은 query path에 있었습니다. 네 번째는 control plane에 숨겨져 있었습니다.
모든 QueryNode가 유휴 상태일 때도 각 Milvus 인스턴스는 Coordinator와 etcd를 계속 유지합니다. N개의 tenant는 N개의 세트를 의미합니다. QueryNode는 0으로 scale할 수 있었지만, 이 두 구성 요소는 그럴 수 없었습니다 — stateful하며 상주 상태를 유지해야 하기 때문입니다. tenant가 백만 개에 이르면 control plane 오버헤드는 QueryNode 비용을 초과합니다.
Lakebase control plane은 이를 O(N)에서 O(1)로 바꿉니다.
기존 Milvus: control plane 비용 O(N)
┌──────────────────────────────────────────────────────────────┐
│ Shared infrastructure │
│ Kafka / Pulsar (shared) Index Pool (shared) │
└──────────────────────────────────────────────────────────────┘
| | |
Tenant A Tenant B Tenant C
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Coordinator │ │ Coordinator │ │ Coordinator │
│ etcd │ │ etcd │ │ etcd │
├──────────────────┤ ├──────────────────┤ ├──────────────────┤
│ QueryNode │ │ QueryNode │ │ QueryNode │
│ (dedicated) │ │ (dedicated) │ │ (dedicated) │
└────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘
└─────────────────────┼─────────────────────┘
↓
┌──────┐
│ S3 │
└──────┘
Lakebase: control plane 비용 O(1)
┌───────────────────────────────────────────────────────────────┐
│ 공유 제어 플레인(리전별) │
│ │
│ ┌──────────────────┐ ┌──────────┐ ┌───────────────────┐ │
│ │ 공유 │ │ Catalog │ │ WAL Service │ │
│ │ Coordinator │ │ ≠ etcd │ │ → S3, ≠ Kafka │ │
│ │ │ │ │ │ │ │
│ └──────────────────┘ └──────────┘ └───────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ Index Service (GPU 빌드 풀) │ │
│ └───────────────────────────────────────────────────────┘ │
└─────────────────────────────┬─────────────────────────────────┘
┌────────────────────┼─────────────────────┐
테넌트 A NS 테넌트 B NS 테넌트 C NS
┌────────────┐ ┌────────────┐ ┌───────────┐
│ QueryNode │ │ (유휴) │ │ QueryNode │
│ QueryNode │ │ scale = 0 │ └────┬──────┘
└──────┬─────┘ └────────────┘ │
└─────────────────────┬─────────────────────┘
↓
┌──────┐
│ S3 │
└──────┘
Lakebase는 기존 테넌트별 모델의 각 요소를 대체합니다. Coordinator는 테넌트 간에 공유되어 테넌트별 Coordinator를 대체합니다. Catalog는 인스턴스별 etcd를 대체하고 2 GB 스토리지 상한을 없앱니다. WAL Service는 로컬 디스크 없이 S3에 직접 기록합니다 — 측정 처리량 750 MB/s, Kafka의 5.8배 — Kafka/Pulsar를 대체합니다. Index Service는 테넌트 간에 공유되는 GPU 빌드 풀로, 인스턴스별 GPU 할당을 대체합니다.
"Scale to zero"는 더 이상 "QueryNode가 해제될 수 있다"는 의미가 아니라, "유휴 상태일 때 전체 인스턴스 비용이 거의 들지 않는다"는 의미가 됩니다.
┌──────────────────────────────────────────────────────────────┐
│ 멀티테넌트 × Lakebase 온디맨드 검색 │
│ │
│ S3 스토리지 계층 컴퓨트(온디맨드) │
│ ┌──────────────┐ │
│ │테넌트 A 데이터│ ◄──── 쿼리 ──── QueryNode A (활성) │
│ ├──────────────┤ │
│ │테넌트 B 데이터│ (유휴, QueryNode 없음) │
│ ├──────────────┤ │
│ │테넌트 C 데이터│ (유휴, QueryNode 없음) │
│ ├──────────────┤ │
│ │테넌트 N 데이터│ ◄──── 쿼리 ──── QueryNode N (활성) │
│ └──────────────┘ │
│ │
│ 테넌트 100만, 1% 활성 → 데이터의 99%는 컴퓨트 비용 0 │
└──────────────────────────────────────────────────────────────┘
전통적으로 멀티테넌시는 별도 컬렉션이나 파티션을 통해 테넌트 간에 클러스터를 공유하는 것을 의미했습니다 — 하지만 그 클러스터에는 엄격한 상한이 있었습니다: etcd의 2 GB 메타데이터 한도, Coordinator의 처리량, 그리고 고정된 QueryNode 용량입니다. 이러한 한계를 넘어 확장하려면 더 많은 클러스터가 필요했고, 이는 더 많은 오버헤드를 의미했습니다.
Lakebase는 그 상한을 바꿉니다. Catalog는 etcd를 확장 가능한 메타데이터 저장소로 대체하고, 공유 Coordinator는 테넌트별 오버헤드 없이 훨씬 더 많은 테넌트를 처리합니다. S3는 스토리지 탄력성을 제공합니다. 그 결과, 단일 클러스터가 훨씬 더 많은 격리된 테넌트를 서비스할 수 있으며 — 실제로 쿼리를 받는 테넌트만 컴퓨트를 소비합니다. 나머지는 스토리지 비용만 지불합니다.
그 Slack 사용자 이야기로 돌아가서
같은 시나리오: 1억 개 벡터, 768차원 float32, 하루 10개 쿼리, 각각 1분. 월 활성 시간 약 5시간.
이 워크로드에서 중요한 차이는 바이트가 어디에 있느냐만이 아닙니다. 아무도 쿼리하지 않는 동안에도 컴퓨팅이 그 바이트에 계속 붙어 있어야 하는지 여부입니다.
셀프 호스팅 Milvus와 Zilliz Cloud 계층형 스토리지 모델의 콜드 스타트 시간은 모두 일회성 로딩 비용입니다 — 일단 워밍되면 쿼리는 빠릅니다. Lakebase 온디맨드 콜드 스타트는 노드가 0으로 스케일 다운된 뒤 각 세션이 시작될 때 발생하며, 이 워크로드에서는 사실상 매번 발생합니다. 세션 사이에는 아무것도 지불하지 않는 대신 세션당 5~10초를 감수하는 것이 트레이드오프입니다.
셀프 호스팅 비용은 대부분 EC2 상시 가동 비용으로, 온디맨드 3 × r6g.4xlarge가 월 약 $2,073이고 여기에 Kafka가 추가됩니다. Zilliz Cloud 계층형 스토리지 모델은 운영 부담을 없애지만, 과금 모델은 동일하게 유지됩니다. Lakebase 온디맨드 검색은 모델을 바꿉니다: 실제로 사용하는 5시간에 대해서만 지불합니다.
| 셀프 호스팅 Milvus | Zilliz Cloud 계층형 스토리지 모델 | Lakebase 온디맨드 검색 | |
|---|---|---|---|
| 컴퓨팅 라이프사이클 | 항상 켜짐 | 항상 켜짐 | 온디맨드 |
| 유휴 컴퓨팅 비용 | 전체 요금 | 전체 요금 | $0 |
| 콜드 스타트 패턴 | 일회성 로드 후 워밍 상태 | 일회성 로드 후 워밍 상태 | 세션 시작 시 5~10초 |
| 최적 사용 사례 | 핫 서빙 워크로드 | 관리형 핫/콜드 계층화 | 드물게 쿼리되는 시맨틱 데이터 |
연간 약 $240. 시간의 99%는 컴퓨팅 비용 0. 네 가지 장애물, 네 가지 계층의 변화.
물리는 바뀌지 않았습니다. S3는 여전히 읽기당 20~50 ms입니다.
바뀐 것은 그 물리적 제약을 둘러싼 컴퓨팅 모델입니다: 계층형 스토리지는 더 차가운 데이터를 저장하는 비용을 줄였지만, Lakebase 온디맨드 검색은 대부분 유휴 상태인 워크로드에 대해 상시 가동 컴퓨팅 하한선을 제거합니다.
그 차이는 절감액보다 더 중요합니다. 연간 $24,000을 정당화할 수 없었던 Slack 사용자는 이전하면서 단지 돈만 아낀 것이 아닙니다 — 검색이 더 많이 수행할 수 있을 만큼 저렴해졌기 때문에 더 많은 데이터를 인덱싱하기 시작했습니다. 더 낮은 가격, 더 많은 수요.
이것이 더 큰 Vector Lakebase 이야기입니다. 시맨틱 데이터가 단일 상시 가동 서빙 클러스터와 독립적으로 지속될 수 있게 되면, 팀은 워크로드에 맞는 컴퓨팅 형태를 선택할 수 있습니다: 핫 경로에는 지속적 서빙, 드물게 쿼리되는 데이터에는 온디맨드 검색, 탐색 또는 처리 작업에는 배치 컴퓨팅.
Zilliz Vector Lakebase가 공개 프리뷰로 제공됩니다
Zilliz Vector Lakebase의 공개 프리뷰를 출시했습니다— 이는 Zilliz Cloud가 관리형 벡터 데이터베이스에서 통합 시맨틱 데이터 플랫폼으로 진화하는 중요한 변화로, 저지연 벡터 서빙과 데이터 레이크의 개방성, 확장성, 경제성을 결합합니다.
Vector Lakebase 핵심 기능:
- 다양한 실시간 성능-비용 트레이드오프에 최적화된 계층형 서빙
- 상시 가동 컴퓨팅 없이 대규모 또는 탐색적 워크로드를 위한 온디맨드 검색
- 외부 데이터 레이크 검색 — 기존 레이크 데이터 위에서 직접 인덱싱하고 검색
- 하이브리드 검색 및 리랭킹을 통해 벡터, 텍스트, JSON, 지리공간 데이터 전반을 아우르는 풀 스펙트럼 검색
- Lance나 Parquet보다 더 빠르고 저렴한 랜덤 읽기를 제공하는 개방형 포맷 Vortex 기반의 통합 레이크 네이티브 스토리지
현재 스택이 서빙과 디스커버리를 별도 시스템으로 나누고 있다면, Vector Lakebase를 살펴볼 만합니다. Zilliz Cloud에서 사용해 보세요 — 새 업무용 이메일 가입자는 $100 무료 크레딧을 받습니다 — 또는 사용 사례에 대해 문의하세요.
계속 읽기
How Zilliz Saw the Future of Vector Databases—and Built for Production
An inside look at how Zilliz built vector databases for real-world use, focusing on scalability, stability, and running them reliably at scale.
The Real Bottlenecks in Autonomous Driving — And How AI Infrastructure Can Solve Them
Autonomous driving faces a data bottleneck. Learn how AI-native vector databases like Zilliz solve scale, cost, and insight challenges across AV pipelines.
1 Table = 1000 Words? Foundation Models for Tabular Data
TableGPT2 automates tabular data insights, overcoming schema variability, while Milvus accelerates vector search for efficient, scalable decision-making.