벡터 레이크베이스란 무엇인가?
TL;DR
- Vector Lakebase는 벡터 데이터베이스 수준의 서빙을 개방형 레이크 스토리지, 재사용 가능한 레이크 수준 인덱스, 공유 시맨틱 레이어와 결합한 AI를 위한 통합 레이크 네이티브 데이터 아키텍처입니다.
- 이는 동일한 비정형 데이터가 온라인 서빙(RAG, 에이전트, 시맨틱 검색)과 오프라인 탐색(클러스터링, 중복 제거, 재임베딩, 거버넌스)을 지원하게 해줍니다 — 시스템 간에 데이터를 복사하지 않고도 가능합니다.
- Zilliz Vector Lakebase는 이 아키텍처의 구현체입니다. 관리형 벡터 데이터베이스에서 통합 AI 데이터 플랫폼으로 진화한 Zilliz Cloud의 발전 형태입니다.
Vector Lakebase란 무엇인가?
Vector Lakebase는 AI를 위한 통합 레이크 네이티브 데이터 아키텍처입니다. 벡터 데이터베이스 수준의 서빙, 개방형 레이크 스토리지, 재사용 가능한 레이크 수준 인덱스, 공유 시맨틱 레이어를 결합하여, 동일한 비정형 데이터가 온라인 AI 애플리케이션, 인터랙티브 탐색, 오프라인 분석을 지원할 수 있게 합니다 — 시스템 간에 데이터를 복사하지 않고도 가능합니다. 이는 단순한 검색과는 다른 질문에 답합니다. 프로덕션 AI 팀이 검색, 탐색, 분석, 거버넌스, 피드백, 지속적인 개선을 위해 동일한 데이터를 필요로 할 때 어떤 일이 일어나는가?
이는 벡터 데이터베이스의 대체물이 아니라 확장으로 이해하는 것이 가장 좋습니다. 벡터 검색은 여전히 저지연 서빙 경로로 남아 있습니다. Vector Lakebase는 그 경로를 데이터를 저장, 인덱싱, 거버넌스 적용, 지속적으로 개선할 수 있는 더 넓은 기반 안에 배치합니다.
현대 AI 워크로드에 Vector Lakebase가 필요한 이유
벡터 데이터베이스는 현대 AI의 첫 번째 데이터 문제를 해결했습니다. 바로 RAG, 에이전트, 시맨틱 검색을 지원하는 대규모 고속 시맨틱 검색입니다. 그 문제는 여전히 중요합니다 — AI 시스템이 확산되면서 그 어느 때보다 더 중요합니다.
하지만 프로덕션 AI 팀은 점점 더 동일한 데이터에서 검색 이상의 것을 필요로 합니다 — 학습 세트를 위한 중복 제거와 클러스터링, 이상 및 드리프트 탐지, 모델 변경에 따른 재임베딩, 거버넌스와 계보, 그리고 프로덕션 동작에서 얻는 피드백입니다.
대부분의 스택은 이러한 워크플로를 별도 시스템으로 처리합니다. 원시 파일을 위한 데이터 레이크, 온라인 검색을 위한 벡터 데이터베이스, 전처리를 위한 배치 파이프라인, 임베딩과 인덱스를 위한 별도 작업이 그것입니다. 데이터는 이들 사이에서 복사되고, 인덱스는 다시 구축되며, 온라인 서빙과 오프라인 탐색은 서로 동기화되지 않은 채 어긋납니다.
Vector Lakebase는 서빙과 탐색을 위한 단일 논리적 데이터 기반을 제공함으로써 이러한 단편화를 제거합니다. 벡터 데이터베이스가 제공하도록 설계된 저지연 검색 경로는 유지하되, 데이터, 벡터, 인덱스, 메타데이터, 시맨틱 컨텍스트를 시간이 지남에 따라 저장, 거버넌스 적용, 버전 관리, 재사용, 개선할 수 있는 레이크 네이티브 기반에 연결합니다. 목표는 벡터 데이터베이스를 레이크로 대체하는 것이 아닙니다. 벡터 검색, 시맨틱 컨텍스트, 비정형 데이터 처리를 단일 아키텍처로 통합하는 것입니다. (이러한 변화의 산업적 맥락과 엔지니어링 배경은 Why We Built Vector Lakebase를 참조하세요.)
Vector Lakebase 핵심 설계 원칙: One Data, One Index, One Semantic Layer
Vector Lakebase 아키텍처는 세 가지 원칙에 기반합니다. One Data, One Index, and One Semantic Layer. 이들은 기록 시스템이 어디에 존재하는지, 인덱스가 어떻게 관리되는지, 의미가 어떻게 조직되는지를 설명합니다.
One Data: 공유 데이터 기반으로서의 레이크
One Data는 개방형 레이크 스토리지가 비정형 AI 데이터의 공유 기반이 된다는 뜻입니다. 원시 파일, 정제된 데이터, 벡터, 스칼라 필드, 메타데이터, 인덱스 아티팩트, 시맨틱 라벨, 계보, 오프라인 처리 결과가 모두 단일 논리적 데이터 기반 안에 존재합니다.
이 아키텍처에서 벡터 데이터베이스는 새로운 데이터 사일로가 아닙니다. 이는 저지연 서빙 경로의 일부가 됩니다. 권위 있는 데이터는 레이크 네이티브 상태로 유지되고, 온라인 시스템은 필요할 때 핫 데이터와 인덱스를 캐시합니다. 이를 통해 중복 저장소, 거버넌스, 시스템 간 마이그레이션을 줄이고, 동일한 데이터가 온라인 애플리케이션, 오프라인 처리, 모델 학습, 평가, 거버넌스를 지원할 수 있습니다.
예를 들어, RAG 시스템에서 사용되는 문서는 오프라인 클러스터링 작업, 학습 데이터 탐색 워크플로, 규정 준수 검토, 향후 재임베딩 프로세스의 일부이기도 할 수 있습니다. 단편화된 아키텍처에서는 각 워크플로가 자체 복사본이나 파생 표현을 생성합니다. Vector Lakebase에서는 이러한 워크플로가 동일한 논리적 데이터 기반 위에서 작동합니다.
One Index: 인덱스가 레이크 수준 자산이 됩니다
One Index는 인덱스가 단일 온라인 서빙 엔진 내부에 갇히지 않는다는 의미입니다. 인덱스는 다양한 컴퓨트 모드 전반에서 구축, 버전 관리, 재사용, 서빙될 수 있는 데이터 자산이 됩니다. 이는 인덱스가 비용이 많이 들고 운영상 중요하기 때문에 중요합니다. 인덱스는 시스템이 데이터를 검색하고 조직화하는 방식을 인코딩합니다. 모든 워크플로가 자체 인덱스를 구축해야 한다면, 팀은 컴퓨트를 낭비하고, 일관성 없는 검색 동작을 만들며, 거버넌스를 더 어렵게 만듭니다.
Vector Lakebase에서 논리적 인덱스는 액세스 패턴과 비용에 따라 다양한 서빙 형태에 매핑될 수 있습니다. 핫 인덱스는 밀리초 수준의 온라인 검색을 지원하고, 웜 데이터는 캐시 또는 계층형 스토리지를 통해 서빙되며, 콜드 데이터는 탐색, 거버넌스, 오프라인 분석을 위해 레이크에 남아 있습니다. 동일한 인덱스 계보는 RAG 서빙, 의미 검색, 에이전트 메모리, 데이터 탐색, 배치 처리를 지원할 수 있어 팀이 데이터 모델을 깨뜨리지 않고도 적절한 지연 시간과 비용 프로필을 선택할 수 있게 합니다.
One Semantic Layer: 의미가 공유 시스템 계층이 됩니다
One Semantic Layer는 시스템이 임베딩 이상의 것을 관리한다는 의미입니다. 임베딩은 기반 자산의 표현 중 하나일 뿐입니다. 유용한 AI 데이터 기반에는 엔터티, 레이블, 요약, 주제, 컨텍스트 조각, 소스 정보, 모델 버전, 액세스 정책, 계보, 피드백 신호도 필요합니다. 이 의미 계층은 팀이 파일 경로, 테이블, 버킷 또는 컬렉션만이 아니라 의미를 기준으로 비정형 데이터를 조직화할 수 있게 합니다.
RAG 시스템은 의미 계층에서 신뢰할 수 있는 컨텍스트를 검색할 수 있습니다. AI 에이전트는 이전 작업, 메모리, 도구 호출 결과를 이해할 수 있습니다. 학습 데이터 워크플로는 커버리지 격차, 중복, 이상치, 편향을 발견할 수 있습니다. 거버넌스 시스템은 답변, 피처 또는 샘플을 이를 생성한 소스 데이터와 모델 버전까지 추적할 수 있습니다.
의미 계층은 데이터 플라이휠의 중심이기도 합니다. 온라인 애플리케이션은 쿼리, 클릭, 인용, 수정, 피드백을 생성하고, 오프라인 발견은 이러한 신호를 더 나은 메타데이터, 더 깨끗한 데이터셋, 개선된 인덱스, 더 강력한 컨텍스트로 바꾸며, 이러한 개선 사항은 다시 서빙으로 흘러갑니다. 그 루프가 Vector Lakebase를 단순한 스토리지와 검색 이상의 것으로 만드는 지점입니다.
Vector Lakebase의 작동 방식: 네 단계로 보는 CS/CD 플라이휠
Vector Lakebase는 서빙과 발견 사이의 지속적인 루프로 실행되며, 이를 CS/CD(Continuous Serving and Continuous Discovery)라고 부릅니다. 서빙은 피드백과 새로운 데이터를 생성하고, 발견은 이를 더 깨끗한 데이터와 더 나은 인덱스로 바꾸며, 이러한 개선 사항은 다시 서빙으로 흘러갑니다.
운영상 동일한 루프는 데이터 수집, 벡터화 및 보강, 쿼리 서빙, 오프라인 처리라는 네 단계를 거칩니다.
데이터 수집
데이터는 벡터 데이터베이스 API, 문서 파이프라인, 객체 스토리지 또는 기존 오픈 레이크 형식을 통해 시스템에 들어올 수 있습니다. 데이터에는 문서, 벡터, 스칼라 필드, 비즈니스 메타데이터, 이미지, 오디오, 비디오, 코드, 로그, 대화, 지원 티켓 또는 에이전트 추적이 포함될 수 있습니다.
비정형 데이터가 증가함에 따라 수집은 정제, 정규화, 접근 제어, 소스 추적, 계보도 지원해야 합니다. 시스템은 데이터가 무엇인지뿐만 아니라, 어디에서 왔는지, 어떤 모델이 이를 처리했는지, 누가 접근할 수 있는지, 어떻게 사용할 수 있는지도 알아야 합니다. 이는 엔터프라이즈 AI에서 특히 중요합니다. RAG 시스템이나 에이전트는 검색된 모든 데이터를 동일하게 신뢰할 수 있는 것으로 취급할 수 없습니다. 컨텍스트에는 소스 인식, 권한 인식, 최신성, 때로는 비즈니스별 거버넌스 규칙이 필요합니다.
벡터화, 보강 및 인덱스 구축
수집 후, 시스템은 임베딩 모델과 데이터 처리 작업을 사용해 벡터 표현을 생성합니다. 또한 엔터티, 레이블, 요약, 주제, 소스 정보, 권한, 타임스탬프, 모델 버전 등의 메타데이터로 데이터를 보강합니다. 그런 다음 레이크 데이터 위에 쿼리 구조를 구축합니다: 벡터 인덱스, 키워드 인덱스, 전문 검색 인덱스, JSON 인덱스, 스칼라 인덱스, 그리고 하이브리드 검색에 필요한 기타 구조입니다.
아키텍처적으로, 이것이 핵심입니다: 인덱스는 특정 서빙 엔진 하나에 묶여 있지 않습니다. 인덱스는 버전 관리, 게시, 재사용이 가능하며, 인덱스가 구축된 데이터 스냅샷까지 추적할 수 있습니다. 이는 인덱스 수명 주기 관리가 하나의 애플리케이션 내부에 묻힌 구현 세부 사항이 아니라 데이터 기반의 일부가 되게 합니다.
쿼리 서빙
Vector Lakebase는 RAG, 에이전트형 검색, 시맨틱 검색, 멀티모달 검색, AI 메모리, 추천 및 기타 AI 애플리케이션 워크로드를 위한 검색 경로를 제공합니다. 쿼리 경로는 낮은 지연 시간이 필요한 핫 데이터에는 벡터 데이터베이스나 캐시 레이어를 사용할 수 있으며, 더 차갑거나 덜 빈번한 워크로드에는 레이크 네이티브 데이터와 인덱스에 접근할 수 있습니다.
쿼리는 벡터 검색, 키워드 검색, 전문 검색, 메타데이터 필터링, 스칼라 조건, 권한, 하이브리드 랭킹을 결합할 수 있습니다. 프로덕션 AI 검색은 벡터 유사도만을 기반으로 하는 경우가 드물기 때문입니다. 좋은 결과는 종종 시맨틱 관련성, 최신성, 접근 권한, 소스 품질, 비즈니스 메타데이터, 사용자 의도에 따라 달라집니다.
오프라인 처리
오프라인 처리에는 클러스터링, 중복 제거, 이상 탐지, 데이터 품질 분석, 학습 데이터 탐색, 스키마 진화, 재임베딩, 평가, 인덱스 재구축이 포함됩니다. 이러한 워크플로는 대규모 데이터 배치에서 실행되며 항상 밀리초 단위 지연 시간이 필요한 것은 아니지만, 온라인 애플리케이션에서 사용하는 동일한 벡터, 메타데이터, 인덱스, 시맨틱 컨텍스트에 접근해야 합니다.
그 결과물은 레이크, 인덱스 시스템, 시맨틱 레이어에 다시 기록됩니다. 더 깨끗한 데이터셋, 더 나은 레이블, 개선된 컨텍스트 조각, 새로운 인덱스 버전, 또는 업데이트된 피드백 신호가 원자적 스냅샷으로 게시되어 프로덕션이 절반만 구축된 인덱스를 읽지 않도록 합니다. 이것이 핵심 운영 루프입니다: 서빙은 피드백을 생성하고, 디스커버리는 데이터를 개선하며, 개선된 데이터는 다시 서빙으로 돌아갑니다.
Vector Lakebase를 위한 세 가지 워크로드 형태
AI 데이터 워크로드는 하나의 형태가 아닙니다. 어떤 것은 하루 종일 밀리초 수준의 서빙이 필요합니다. 어떤 것은 짧은 분석 세션을 위한 대화형 검색이 필요합니다. 어떤 것은 실행되고, 결과를 게시하고, 사라지는 대규모 오프라인 처리 작업이 필요합니다. 단일한 상시 가동 온라인 스토리지 모델로는 이 모든 것을 효율적으로 포괄할 수 없습니다.
전통적인 벡터 데이터베이스는 주로 첫 번째 워크로드 형태에 최적화되어 있습니다. Vector Lakebase는 하나의 논리적 데이터셋 위에서 세 가지 모두를 위해 설계되었습니다.
Zilliz Vector Lakebase에서 이러한 워크로드는 세 가지 컴퓨트 모드에 매핑됩니다 — long-running(상주형, 밀리초 서빙), on-demand(대화형, 분 단위 과금, 서빙과 디스커버리 사이의 브리지), 그리고 offline batch(완료되면 컴퓨트를 해제하는 대규모 작업).
| 워크로드 유형 | 일반적인 예시 | 컴퓨트 패턴 |
|---|---|---|
| 실시간 서빙 | 프로덕션 RAG, 에이전트 메모리, 시맨틱 검색, 추천, 개인화, AI 검색 | 핫 인덱스, 웜 캐시, 예측 가능한 지연 시간을 갖춘 장기 실행 서빙 클러스터 |
| 대화형 탐색 | 피드백 분석, 에이전트 추적 검사, 이상 탐색, 콜드 데이터 검색, 시맨틱 탐색 | 필요할 때 시작되고 세션이 끝나면 리소스를 해제하는 온디맨드 컴퓨트 |
| 배치 분석 | 코퍼스 중복 제거, 클러스터링, 전체 재임베딩, 학습 데이터 준비, 인덱스 재구축 | 실행되고, 결과를 게시한 뒤 사라지는 대규모 작업용 배치 컴퓨트 |
Vector Lakebase의 일반적인 사용 사례
Vector Lakebase는 단일 기반 위에서 서빙과 탐색을 통합하므로, 사용 사례는 두 그룹으로 나뉩니다.
图片12
검색 사용 사례(벡터 데이터베이스와 공유되며, 이제 거버넌스가 적용된 기반 위에서 제공):
- RAG — 문서, 지식 베이스, 코드, 로그를 검색 가능한 컨텍스트로 활용하며, 모델이 변경될 때 최신 상태로 유지되고, 권한이 적용되며, 재인덱싱 가능합니다.
- AI 에이전트 메모리 및 도구 사용 — 에이전트 메모리를 저장하고 검색한 다음, 이를 오프라인으로 분석하고 발견한 내용을 다시 반영합니다.
- 에이전틱 및 멀티모달 검색 — 텍스트, 이미지, 오디오, 비디오, 엔터티 전반에서 벡터, 키워드, 전체 텍스트, 메타데이터 검색을 수행합니다.
- 추천 시스템 등.
데이터 수명 주기 사용 사례(벡터 데이터베이스만으로는 다루기 어려운 영역):
- 특징 및 컨텍스트 엔지니어링 — 엔터티, 요약, 주제, 레이블, 클러스터를 도출하고, 그 출처 데이터 옆에 저장합니다.
- 학습 데이터 탐색 — 샘플을 클러스터링하고, 거의 중복된 항목을 찾고, 이상치를 검사하며, 예시를 소스까지 추적합니다.
- 비정형 데이터 전처리 — 중복 제거, 이상 탐지, 보강, 품질 필터링을 수행하고, 그 결과를 레이크에 다시 기록합니다.
Vector Lakebase와 벡터 데이터베이스 및 Lakebase의 관계
Vector Lakebase는 두 가지 아키텍처, 즉 벡터 데이터베이스와 Lakebase와 관련이 있습니다. 어느 것도 대체하지 않습니다. 아래 표는 간단한 개요이며, 이어지는 섹션에서 각 관계를 설명합니다.
| 벡터 데이터베이스 | Vector Lakebase | Lakebase | |
|---|---|---|---|
| 기본 데이터 | 벡터 임베딩 + 관련 비정형 데이터 | 비정형 및 멀티모달 데이터와 이를 둘러싼 전체 수명 주기 | 구조화된 / 트랜잭션 애플리케이션 데이터 |
| 핵심 작업 | 저지연 시맨틱 검색 | 하나의 기반 위에서 온라인 서빙과 오프라인 탐색 통합 | 오픈 레이크 스토리지에 데이터베이스(OLTP) 기능 제공 |
| 인덱스 | 서빙 엔진 내부에서 구축되고 유지됨 | 레이크 수준 자산: 컴퓨트 모드 전반에서 구축, 버전 관리, 재사용 | 테이블 / SQL 인덱스 |
| 컴퓨트 | 상시 실행 서빙 | 장기 실행 + 온디맨드 + 오프라인 배치 | 트랜잭션 |
| 기록 저장소 | 엔진에 결합되는 경우가 많음 | 오픈 레이크 스토리지 | 오픈 레이크 스토리지 |
| 최적 용도 | 온라인 애플리케이션을 위한 빠른 벡터 검색 | 대규모 비정형 데이터의 서빙 및 지속적 개선 | 레이크 위의 트랜잭션 앱 데이터 |
| Vector Lakebase와의 관계 | Vector Lakebase 내부의 서빙 엔진이 됨 | - | 동일한 레이크 네이티브 아이디어의 구조화 데이터 대응물 |
Vector Lakebase vs. 벡터 데이터베이스
Vector Lakebase는 벡터 데이터베이스를 대체하지 않습니다. 조직이 단일 애플리케이션을 위한 저지연 벡터 검색만 필요로 한다면, 벡터 데이터베이스로 충분할 수 있습니다 — 지연 시간, 규모, 필터링, 운영 안정성이 중요할 때 프로덕션 검색에 적합한 시스템으로 남아 있습니다. 예를 들어 Milvus는 이러한 종류의 프로덕션 벡터 검색을 위해 구축되었습니다.
조직이 동일한 비정형 데이터, 임베딩, 인덱스, 시맨틱 컨텍스트를 여러 팀, 모델, 애플리케이션, 처리 워크플로 전반에서 재사용해야 할 때 계산 방식은 달라집니다.
그러한 세계에서 벡터 데이터베이스는 데이터와 인덱스가 존재하는 유일한 장소가 되어서는 안 됩니다. 벡터 데이터베이스는 더 넓은 비정형 데이터 아키텍처 내부의 서빙 엔진이 됩니다. 그 역할은 더 구체적이고 더 중요해집니다 — AI 애플리케이션이 필요로 하는 서빙 경로를 제공하는 동시에, Vector Lakebase는 그 경로를 둘러싼 더 넓은 데이터 기반을 제공합니다. 그 결과는 벡터 검색의 축소가 아니라, 비정형 데이터의 전체 수명 주기와 연결된 벡터 검색입니다.
벡터 데이터베이스만 필요하다면, Vector Lakebase는 여전히 적합한가요?
그것은 시작하기에 아주 좋은 지점입니다 — 벡터 데이터베이스는 이미 Vector Lakebase의 일부이기 때문입니다. 서빙 클러스터 계층을 독립형 벡터 데이터베이스와 똑같이 사용할 수 있습니다(저지연 ANN 검색, 하이브리드 검색, 메타데이터 필터링, 전문 검색, JSON 필터링, 인덱스 관리, 프로덕션 안정성). 그리고 첫날에는 대화형 탐색이나 배치 분석을 전혀 건드리지 않아도 됩니다. 차이점은 검색 전용 아키텍처에 갇히지 않는다는 점입니다. 나중에 워크로드가 콜드 데이터 검색, 대규모 중복 제거, 재임베딩, 학습 데이터 준비, 또는 시맨틱 거버넌스로 확장되더라도, 더 넓은 아키텍처가 이미 마련되어 있습니다 — 재구축도, 데이터 중복도 없습니다.
Vector Lakebase vs. Lakebase
Vector Lakebase는 Lakebase와 관련이 있지만, 단순히 "Lakebase에 벡터를 더한 것"은 아닙니다.
Lakebase 스타일의 아키텍처는 정형 애플리케이션 데이터를 위한 오픈 레이크 스토리지에 데이터베이스와 유사한 기능을 제공합니다 — 정형 레코드, 트랜잭션, 스키마, 탄력적 컴퓨트, 통합 거버넌스가 포함되며, 알려진 필드와 관계를 통해 쿼리됩니다.
Vector Lakebase는 다른 중심축을 다룹니다: AI를 위한 비정형 및 멀티모달 데이터. 문제는 애플리케이션 상태를 레이크에 저장하는 방법이 아니라, 비정형 데이터 전반에서 시맨틱 표현, 벡터 인덱스, 메타데이터, 컨텍스트, 피드백, 오프라인 탐색 워크플로를 관리하는 방법입니다 — 이는 알려진 필드에 대한 조회가 아니라 시맨틱 해석, 검색, 정제, 피드백을 필요로 합니다. 이는 Lakebase를 대체하는 것으로 설명하는 것보다, 벡터, 인덱스, 시맨틱 컨텍스트의 시대에 맞게 Lakebase 개념을 확장한 것으로 설명하는 것이 가장 적절합니다.
| 차원 | Lakebase | Vector Lakebase |
|---|---|---|
| 주요 데이터 | 정형 애플리케이션 데이터, 트랜잭션 레코드, 애플리케이션 상태 | 문서, 이미지, 오디오, 비디오, 로그, 코드, 대화, 벡터, 메타데이터, 시맨틱 컨텍스트 |
| 핵심 추상화 | 테이블, 트랜잭션, 스키마, 브랜치, 클론 | 벡터, 인덱스, 청크, 엔터티, 레이블, 요약, 권한, 피드백, 시맨틱 관계 |
| 주요 워크로드 | 애플리케이션 읽기 및 쓰기, 트랜잭션, 실시간 분석 | RAG, 에이전트 메모리, 에이전틱 검색, 멀티모달 검색, 탐색, 컨텍스트 엔지니어링, 학습 데이터 워크플로 |
| 쿼리 모델 | SQL, 트랜잭션 쿼리, 분석 쿼리 | 벡터 검색, 하이브리드 검색, 전문 검색, JSON 필터링, 멀티모달 검색, 시맨틱 탐색 |
| 시맨틱 모델 | 주로 스키마를 통해 표현되는 비즈니스 의미 | 임베딩, 메타데이터, 엔터티, 요약, 모델 버전, 계보, 피드백을 통해 표현되는 의미 |
| AI 가치 | 오픈 레이크 스토리지에 데이터베이스와 유사한 기능 제공 | 레이크 네이티브 비정형 데이터에 AI 컨텍스트, 벡터 인덱싱, 시맨틱 검색, 오프라인 탐색 제공 |
Vector Lakebase가 아닌 것
Vector Lakebase는 새로운 아키텍처 패턴이기 때문에, 그것이 무엇이 아닌지 명확히 하는 것이 중요합니다.
- 이는 임베딩이 열에 저장된 데이터 레이크에 불과한 것이 아닙니다. 레이크 테이블에 임베딩을 저장하면 벡터는 보존되지만, 프로덕션 AI 시스템에 필요한 인덱싱, 서빙, 시맨틱 메타데이터, 하이브리드 검색, 피드백 루프, 또는 저지연 검색 경로는 전혀 제공되지 않습니다. 벡터는 단순히 저장될 때가 아니라, 검색되고, 거버넌스가 적용되고, 버전 관리되고, 필터링되고, 원본 데이터와 연결되며, 시간이 지남에 따라 개선될 수 있을 때 유용합니다.
- 이는 오브젝트 스토리지에 연결된 벡터 데이터베이스에 불과한 것이 아닙니다. 벡터 데이터베이스 뒤에 오브젝트 스토리지를 두면 스토리지 비용은 줄일 수 있지만, 인덱스 재사용, 오프라인 탐색, 거버넌스, 버전 관리, 또는 처리된 데이터와 제공되는 데이터 간의 일관성 문제는 해결하지 못합니다. 어려운 부분은 바이트가 어디에 존재하느냐가 아니라, 데이터, 인덱스, 메타데이터, 시맨틱 신호, 컴퓨트 모드가 하나의 운영 시스템으로 함께 작동하는 방식입니다.
- 이는 오프라인 분석 시스템이 아닙니다. 오프라인 탐색은 아키텍처의 한 측면일 뿐입니다. Vector Lakebase는 프로덕션 트래픽도 처리하고, 핫 검색 경로를 지원하며, 인덱스를 관리하고, 액세스 제어를 적용하며, 애플리케이션과 에이전트에 관련 컨텍스트를 반환합니다. 핵심은 서빙과 분석 중 하나를 선택하는 것이 아니라, 둘을 연결하는 것입니다.
- 이는 벡터 데이터베이스에서 벗어나는 것이 아닙니다. 이것은 우리가 반복해서 언급한 가장 중요한 지점일 수 있습니다. Vector Lakebase는 벡터 데이터베이스의 중요성을 낮추지 않습니다. 오히려 벡터 데이터베이스가 작동할 수 있는 더 넓은 아키텍처를 제공합니다.
Zilliz Vector Lakebase가 공개 프리뷰로 제공됩니다
저희는 Zilliz Vector Lakebase의 공개 프리뷰를 출시했습니다. 이는 Zilliz Cloud가 순수 관리형 벡터 데이터베이스에서, 저지연 벡터 서빙과 데이터 레이크의 개방성, 확장성, 경제성을 결합한 통합 시맨틱 데이터 플랫폼으로 진화하는 중요한 변화입니다.
Zilliz Vector Lakebase의 핵심 기능:
- 서로 다른 실시간 성능-비용 절충에 최적화된 계층형 서빙
- 상시 실행 컴퓨트 없이 대규모 또는 탐색형 워크로드를 위한 온디맨드 검색
- 기존 레이크 데이터 위에서 직접 인덱싱하고 검색하는 외부 데이터 레이크 검색
- 하이브리드 검색 및 재랭킹을 통해 벡터, 텍스트, JSON, 지리공간 데이터를 아우르는 전체 스펙트럼 AI 검색
- Lance 또는 Parquet보다 더 빠르고 저렴한 랜덤 읽기를 제공하는 오픈 포맷인 Vortex 기반의 통합 레이크 네이티브 스토리지
현재 스택이 서빙과 탐색을 별도 시스템으로 분리하고 있다면, Vector Lakebase를 살펴볼 가치가 있습니다. Zilliz Cloud에서 사용해 보세요 — 새 업무용 이메일로 가입하면 $100 무료 크레딧을 받을 수 있습니다 — 또는 사용 사례에 대해 저희에게 문의하세요.
Vector Lakebase에 대해 더 알아보기
계속 읽기
Zilliz Cloud Now Available in Azure North Europe: Bringing AI-Powered Vector Search Closer to European Customers
The addition of the Azure North Europe (Ireland) region further expands our global footprint to better serve our European customers.
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.
Vector Databases vs. Time Series Databases
Use a vector database for similarity search and semantic relationships; use a time series database for tracking value changes over time.