홈
Blog
Milvus 외부 컬렉션: 데이터 이동 없이 레이크 상주 데이터 인덱싱 및 검색

Milvus 외부 컬렉션: 데이터 이동 없이 레이크 상주 데이터 인덱싱 및 검색

Engineering

August 24, 2026

Leo Liu

많은 AI 파이프라인에서 임베딩과 메타데이터는 이미 데이터 레이크에서 생성되어 저장됩니다. 제품 파이프라인은 제품 속성과 멀티모달 임베딩을 S3의 Parquet 파일에 쓸 수 있습니다. 검색 또는 학습 코퍼스는 Iceberg 또는 Lance 테이블에 저장될 수 있습니다. 데이터 레이크는 이미 이러한 데이터셋이 생성, 업데이트, 버전 관리되고 나머지 데이터 스택에서 사용되는 곳입니다.

그러나 벡터 데이터베이스는 전통적으로 데이터베이스가 소유한 서빙 복사본을 중심으로 구축되어 왔습니다. 팀이 이미 레이크에 있는 데이터에 대해 저지연 벡터 검색을 원한다면 일반적으로 두 가지 옵션이 있었습니다:

데이터를 벡터 데이터베이스에 복사. 이는 ANN 인덱스와 프로덕션 서빙 경로를 제공하지만, 데이터셋의 두 번째 복사본과 소스와 동기화를 유지해야 하는 ETL 파이프라인을 생성합니다.
레이크를 직접 쿼리. 이는 중복을 피하지만, ANN 인덱싱 및 서빙 레이어가 없으면 벡터 검색이 프로덕션 지연 시간에 맞게 설계되지 않은 스캔으로 대체됩니다.

Milvus 3.0 External Collection은 세 번째 경로를 도입합니다. 소스 데이터는 Parquet, Iceberg, Lance, Vortex 또는 기타 지원되는 외부 형식에 그대로 유지되며, Milvus는 그 위에 인덱스를 구축하고 서빙합니다. 외부 필드를 Milvus 스키마에 매핑하고, 필요한 인덱스를 정의하고, 컬렉션을 새로 고치고, 일반 Milvus 검색 및 쿼리 API를 사용합니다. 소스 행을 먼저 Milvus 관리 컬렉션에 복사할 필요가 없습니다.

아키텍처 변경은 간단합니다. 데이터는 레이크에 그대로 남아 있고, Milvus가 인덱싱 및 검색 레이어를 추가합니다.

이는 또한 External Collection을 Vector Lakebase, 즉 오픈 레이크 스토리지, 재사용 가능한 레이크 수준 인덱스, 공유 의미론적 레이어와 벡터 데이터베이스급 서빙을 결합한 AI를 위한 통합 레이크 네이티브 데이터 아키텍처로 가는 중요한 단계로 만듭니다. 온라인 검색은 더 이상 별도의 서빙 복사본에서 시작할 필요가 없으며, Spark, 학습 파이프라인, 평가 작업, 거버넌스 도구가 데이터의 다른 버전에서 작동할 필요도 없습니다. 동일한 레이크 상주 데이터 기반 위에서 작업할 수 있습니다.

External Collection이란 무엇이며, 무엇을 바꾸는가

External Collection은 소스 데이터가 Milvus 관리 스토리지 외부에 있는 Milvus 컬렉션 유형입니다.

External Collection이 없으면 해당 카탈로그를 프로덕션 벡터 검색 뒤에 배치하는 것은 일반적으로 Milvus에 또 다른 복사본을 만드는 것을 의미합니다:

카탈로그가 변경되거나, 임베딩 모델이 변경되거나, 필드가 백필될 때마다 다른 파이프라인이 업데이트된 데이터를 그 경계를 넘어 이동해야 합니다.

External Collection을 사용하면 아키텍처는 다음과 같습니다:

Milvus는 외부 파일을 자체 소스 데이터 복사본으로 만들지 않습니다. 대신 External Collection에는 Milvus가 해당 파일을 해석하고 검색하는 데 필요한 정보가 포함됩니다:

외부 파일이나 테이블을 식별하는 external_source.
소스 형식과 스토리지 접근을 설명하는 external_spec.
Milvus 스키마의 필드를 외부 데이터셋의 열에 연결하는 external_field 매핑.
Milvus가 검색을 위해 생성하는 인덱스, 매니페스트 및 서빙 상태.

소스 데이터의 제로 카피가 Milvus 내부의 상태가 제로라는 의미는 아닙니다. Milvus는 여전히 인덱스를 구축합니다. 여전히 컴퓨팅을 사용합니다. 여전히 데이터를 캐시합니다. 달라진 점은 Milvus에서 검색해야 한다는 이유만으로 권위 있는 행을 Milvus에 복사할 필요가 없다는 것입니다.

일반 Milvus 컬렉션과 External Collection 비교

관심사	Milvus 관리 컬렉션	External Collection
소스 레코드	Milvus에 저장 및 관리	외부 파일 또는 테이블에 유지
데이터가 Milvus에 들어오는 방식	Insert, upsert, import, 또는 스트리밍 쓰기	외부 소스 매핑 + Refresh
온라인 변경	지원됨	Milvus에서 읽기 전용
신선도	Milvus 쓰기 경로 및 일관성 모델을 따름	마지막으로 성공적으로 게시된 Refresh를 따름
Milvus 관리 상태	소스 데이터, 메타데이터, 인덱스, 캐시	매핑, 매니페스트, 인덱스, 캐시
쿼리 경로	Milvus 검색 및 쿼리 API	Milvus 검색 및 쿼리 API
최적 적합	지속적으로 변화하는 온라인 데이터	대규모, 배치 생성, 읽기 중심 레이크 데이터

따라서 External Collection은 일반 Milvus 컬렉션을 대체하기보다 보완합니다.

시스템은 빠르게 변화하는 온라인 상태를 일반 Milvus 컬렉션에 유지하면서, 대규모 코퍼스, 카탈로그, 과거 데이터셋, 모델 피처 또는 레이크에서 이미 생성되고 관리되는 기타 데이터에는 External Collection을 사용할 수 있습니다.

두 번째 복사본을 제거하는 것이 중요한 이유

External Collection을 스토리지 최적화로 설명하고 싶은 유혹이 있습니다. 수 테라바이트의 데이터를 다른 데이터베이스에 복사하지 않으면 스토리지를 절약할 수 있으니까요. 유용하지만 이것이 주요 아키텍처 문제는 아닙니다.

더 큰 비용은 두 데이터 시스템을 정렬된 상태로 유지하는 데서 발생합니다.

제품 카탈로그를 다시 생각해 보겠습니다. 데이터 플랫폼은 권위 있는 Parquet 데이터셋을 생성합니다. 검색은 이를 벡터 데이터베이스로 가져옵니다. 추천 팀은 오프라인 분석을 위해 Spark를 통해 동일한 레이크 데이터를 읽을 수 있습니다. 그런 다음 새로운 임베딩 모델이 대체 벡터 열을 생성합니다. 재고와 메타데이터는 동시에 계속 변경됩니다.

온라인 서빙 복사본이 레이크와 독립적으로 되면 모든 변경 사항은 그 경계를 넘어야 합니다:

데이터를 복사해야 합니다;
전송을 예약하고 모니터링해야 합니다;
실패한 작업은 재시도가 필요합니다;
스키마와 권한은 여러 시스템에서 표현해야 할 수 있습니다;
신선도는 동기화 파이프라인이 따라잡는 속도에 따라 달라집니다;
팀은 어떤 복사본이 실제로 원하는 버전인지 알아야 합니다.

스토리지는 하나의 비용 항목에 불과합니다.

비용	별도 레이크 + 서빙 복사본	External Collection
소스 데이터 복사본	레이크 복사본 + 별도 서빙 복사본	소스 행은 레이크에 유지
데이터 이동	지속적인 ETL/import 파이프라인	외부 소스에 대한 Refresh
신선도	export/import 주기에 따라 달라짐	새 Refresh가 게시되는 시점에 의해 제어됨
거버넌스	소스와 서빙 복사본이 정렬된 상태를 유지해야 함	소스 소유권, 계보, 버전 관리는 레이크 플랫폼에 유지됨
오프라인 재사용	다른 소비자가 자체 복사본을 준비할 수 있음	기존 레이크 도구가 동일한 소스를 계속 읽을 수 있음
서빙 리소스	데이터베이스 복사본과 쿼리 워크로드에 맞게 크기 조정	인덱싱, 쿼리 컴퓨팅, 캐시를 소스 행의 소유권과 별도로 관리할 수 있음

이 차이는 AI 데이터가 더 자주 변경될수록 특히 중요해집니다.

팀은 코퍼스를 중복 제거하고, 분석을 위해 데이터를 클러스터링하며, 모델이 변경되면 새 임베딩을 생성합니다. 레이블, 요약, 추출된 엔티티, 품질 점수 또는 피드백 신호를 추가합니다. 프로덕션 애플리케이션이 검색하는 동일한 코퍼스에 대해 평가 작업과 데이터 정리 파이프라인을 실행합니다.

모든 시스템이 자체 복사본을 소유한다면 모든 개선은 또 하나의 동기화 작업이 됩니다.

External Collection은 그 경계를 바꿉니다: 오프라인 시스템은 레이크 데이터셋에서 계속 작업할 수 있고, Milvus는 동일한 기반 위에서 검색을 서빙합니다.

External Collection이 지원하는 데이터 소스

External Collection은 Milvus 특정 소스 레이아웃이 아닌 개방형 외부 관리 데이터를 중심으로 설계되었습니다. Storage V3를 통해 여러 외부 소스 형식을 지원합니다:

외부 형식	format 값	Milvus가 읽는 대상
Apache Parquet	parquet	Parquet 파일과 행 그룹을 포함하는 디렉터리 또는 객체 스토리지 접두사
Vortex	vortex	Vortex 파일 및 레이아웃 메타데이터
Lance	lance-table	Lance 데이터셋 및 프래그먼트 메타데이터
Apache Iceberg	iceberg-table	Iceberg 메타데이터와 선택된 스냅샷
Milvus snapshot	milvus-table	외부 소스로 노출된 지원되는 Milvus 스냅샷

소스와 Milvus 간의 매핑은 명시적입니다.

product_id라는 소스 열은 Milvus 필드 id가 될 수 있고, image_vec는 embedding이 될 수 있으며, 넓은 소스 테이블이 모든 열을 컬렉션에 노출할 필요는 없습니다. 즉, 데이터 플랫폼이 서빙 데이터베이스를 충족시키기 위해 소스를 이름 변경하거나 다시 쓸 필요가 없습니다.

버전 관리 형식은 또 다른 유용한 속성을 추가합니다. Iceberg와 같은 소스를 사용하면 컬렉션이 쿼리 실행 시 현재 상태가 아닌 특정 스냅샷을 가리킬 수 있습니다. 고정된 소스 버전은 반복 가능한 평가, 회귀 테스트, 과거 분석 및 감사 워크로드에 유용합니다.

기본 파일은 나머지 데이터 스택에서도 계속 사용할 수 있습니다. Spark, 학습 프레임워크, 거버넌스 시스템 및 기타 레이크 호환 도구는 동일한 개방형 데이터를 계속 읽을 수 있습니다.

External Collection은 해당 데이터의 또 다른 소비자를 추가할 뿐, Milvus를 유일한 소유자로 만들지는 않습니다.

외부 스토리지에 안전하게 접근하기

Milvus는 또한 외부 스토리지를 읽을 수 있는 권한이 필요합니다.

스토리지 제공자에 따라 배포 시 애플리케이션 구성에 장기 자격 증명을 포함하는 대신 워크로드 또는 인스턴스 ID, AWS STS 역할 가정, 서비스 계정 가장, SAS 기반 접근 또는 제공자별 역할 시스템과 같은 메커니즘을 사용할 수 있습니다.

이 스토리지 ID는 Milvus가 소스에 도달하는 방식을 제어합니다. Milvus 내부의 권한 부여는 별도의 보안 경계로 유지됩니다.

외부 컬렉션을 생성, 인덱싱, 새로 고치고 쿼리하는 방법

External Collection 수명 주기에는 네 가지 주요 단계가 있습니다:

외부 소스를 정의하고 해당 열을 Milvus 스키마에 매핑합니다.
워크로드에 필요한 인덱스를 정의합니다.
Refresh를 실행하여 Milvus가 소스 데이터를 발견하고 쿼리 가능한 버전을 준비하게 합니다.
컬렉션을 로드하고 일반 Milvus 검색 및 쿼리 API를 사용합니다.

다음은 동일한 제품 카탈로그를 External Collection으로 표현한 예입니다:

import json
import time
from pymilvus import DataType, MilvusClient
client = MilvusClient(
uri=“http://localhost:19530”,
token=“root:Milvus”,
)
schema = client.create_schema(
external_source=“s3://my-lake/datasets/products/”,
external_spec=json.dumps(
{
“format”: “parquet”,
“extfs”: {
“cloud_provider”: “aws”,
“region”: “us-east-1”,
“use_iam”: “true”,
“iam_endpoint”: “https://sts.us-east-1.amazonaws.com”,
},
}
),
)
schema.add_field(
field_name=“id”,
datatype=DataType.INT64,
external_field=“product_id”,
)
schema.add_field(
field_name=“embedding”,
datatype=DataType.FLOAT_VECTOR,
dim=768,
external_field=“image_vec”,
)
schema.add_field(
field_name=“title”,
datatype=DataType.VARCHAR,
max_length=256,
external_field=“product_name”,
)
schema.add_field(
field_name=“stock”,
datatype=DataType.INT64,
external_field=“stock”,
)
schema.add_field(
field_name=“rating”,
datatype=DataType.FLOAT,
external_field=“rating”,
)
client.create_collection(
collection_name=“products_ext”,
schema=schema,
)

인덱스는 일반 Milvus 인터페이스를 사용합니다:

index_params = client.prepare_index_params()
index_params.add_index(
    field_name="embedding",
    index_type="HNSW",
    metric_type="COSINE",
)
index_params.add_index(field_name="stock", index_type="AUTOINDEX")
index_params.add_index(field_name="rating", index_type="AUTOINDEX")
client.create_index(
collection_name=“products_ext”,
index_params=index_params,
)

그런 다음 외부 소스를 새로 고칩니다:

job_id = client.refresh_external_collection(
    collection_name="products_ext",
)
while True:
progress = client.get_refresh_external_collection_progress(job_id=job_id)
if progress.state == “RefreshCompleted”:
break
if progress.state == “RefreshFailed”:
raise RuntimeError(progress.reason)
time.sleep(2)

새로 고쳐진 버전이 준비되면 일반 Milvus 컬렉션처럼 로드하고 검색합니다:

client.load_collection("products_ext")
results = client.search(
collection_name=“products_ext”,
data=[query_vec],
anns_field=“embedding”,
filter=“stock > 0 and rating >= 4.0”,
limit=10,
output_fields=[“id”, “title”, “stock”, “rating”],
)

중요한 차이는 검색 호출이 아니라 수명 주기가 시작되는 지점입니다. Milvus 관리 컬렉션은 데이터가 Milvus에 쓰이거나 가져와지면서 시작됩니다. External Collection은 이미 다른 곳에 존재하는 데이터에 대한 참조로 시작됩니다.

Refresh가 외부 데이터의 변경 사항을 감지하는 방법

External Collection은 Milvus 쪽에서는 읽기 전용이지만 기본 레이크 데이터셋이 영원히 고정되어 있어야 하는 것은 아닙니다.

제품 파이프라인이 다른 배치를 추가하거나, 메타데이터를 업데이트하거나, 새 모델의 임베딩을 쓴다고 가정해 보겠습니다. Milvus는 소스 경로에 나타나는 모든 객체를 지속적으로 추적하지 않습니다. 이러한 변경 사항은 Refresh를 통해 표시됩니다.

Refresh는 외부 메타데이터를 읽고, 소스 프래그먼트를 확인하고, 이를 Milvus 컬렉션에 연결하는 매니페스트를 업데이트하고, 해당 인덱스 상태를 준비합니다.

핵심은 이 작업이 증분 방식으로 수행될 수 있다는 것입니다.

Milvus는 변경되지 않은 소스 프래그먼트를 식별하고 기존 세그먼트 및 인덱스 작업을 재사용할 수 있습니다. 새로 추가되거나 변경된 프래그먼트는 새 처리가 필요한 부분입니다.

따라서 수 테라바이트 규모의 데이터셋에 대한 작은 변경이 전체 import와 전체 인덱스 재구축을 다시 트리거할 필요는 없습니다.

Refresh는 또한 서빙 시스템에 명확한 버전 경계를 제공합니다. 새 버전이 준비되는 동안 쿼리는 이전에 게시된 상태를 계속 사용합니다. Refresh가 완료되면 새 상태는 이전 데이터와 부분적으로 준비된 데이터가 혼합된 상태가 아닌 완전한 버전으로 제공됩니다.

이 모델은 시간별 카탈로그 빌드, 야간 지식 베이스 업데이트, 주기적인 임베딩 새로 고침, 모델 생성 피처 파이프라인 및 유사한 배치 중심 워크로드에 자연스럽게 적합합니다.

이는 스트리밍 쓰기 경로를 대체하지 않습니다. 모든 삽입 또는 삭제가 즉시 Milvus를 통해 검색 가능해야 한다면 관리형 컬렉션이 더 나은 모델입니다.

Lazy Loading이 넓은 데이터셋의 메모리 사용을 줄이는 방법

소스 행을 객체 스토리지에 유지하는 것은 서빙 레이어가 쿼리에 응답하기 전에 모든 바이트를 로컬에 로드할 필요가 없을 때만 도움이 됩니다. Milvus Tiered Storage가 활성화되면 그렇지 않습니다.

컬렉션 로드 시점에 QueryNode는 처음에 스키마 정보, 인덱스 정의, 청크 맵, 원격 객체 참조와 같은 가벼운 메타데이터만 보관할 수 있습니다. 필드 데이터는 쿼리가 필요로 할 때 청크 수준에서 가져오며, 인덱스는 첫 사용 전까지 원격으로 유지되다가 로컬에 캐시됩니다. 자주 사용되는 데이터는 핫 상태로 유지되고, 자주 액세스되지 않는 데이터는 축출될 수 있습니다.

이는 특히 넓은 AI 데이터셋에 유용합니다.

제품 행에는 여러 임베딩, 긴 설명, 원시 JSON, 이미지 메타데이터, 생성된 요약, 재고, 가격, 평점 및 기타 많은 속성이 포함될 수 있습니다. 일반적인 유사도 검색은 하나의 벡터와 재고, 가격, 평점만 접촉할 수 있습니다. 다른 모든 필드가 동일한 레코드에 속한다는 이유만으로 영구적으로 서빙 메모리를 차지해야 할 이유는 없습니다.

External Collection은 서빙 공간을 두 수준에서 줄일 수 있습니다:

첫째, 스키마 수준 프로젝션입니다. external_field를 통해 External Collection은 애플리케이션에 필요한 소스 열만 노출할 수 있습니다. 다른 열은 레이크 데이터셋에 남아 있으며 이 서빙 스키마에 포함되지 않습니다.
둘째, 런타임 프로젝션입니다. 계층형 서빙 모델에서 QueryNode는 매핑된 데이터셋 전체를 미리 로드하는 대신 워크로드에 실제로 필요한 필드와 인덱스를 가져와 캐시합니다.

즉, 데이터셋은 레이크에서 넓게 유지되면서 서빙 공간을 그만큼 넓게 만들 필요가 없습니다.

명백한 트레이드오프가 있습니다. 콜드 필드나 인덱스를 검색하는 쿼리는 첫 액세스 시 원격 읽기 비용을 지불할 수 있습니다. 워밍업 정책은 지연 시간에 중요한 필드나 인덱스를 사전 로드할 수 있고, 캐시 및 축출 정책은 자주 액세스되지 않는 상태가 로컬 리소스를 무기한 점유하지 않도록 합니다.

핵심은 객체 스토리지가 RAM처럼 작동한다는 것이 아닙니다. 메모리와 로컬 디스크가 소스 데이터셋의 전체 크기와 너비가 아닌 검색 워크로드의 작업 세트를 따를 수 있다는 것입니다.

여기서 소스 형식도 중요합니다. 광범위한 분석 스캔용으로 설계된 형식과 더 좁은 범위 또는 무작위 읽기에 최적화된 형식은 온디맨드 액세스에서 서로 다른 I/O 동작을 생성할 수 있습니다. External Collection은 이러한 스토리지 수준의 트레이드오프를 지우지 않습니다. Milvus가 그 위에 검색 레이어를 구축할 수 있게 할 뿐입니다.

External Collection이 지원하는 검색 및 인덱싱 기능

External Collection은 단순히 Milvus가 임베딩 디렉터리를 가리키고 파일을 스캔하도록 하는 것이 아닙니다. Milvus는 외부 데이터에 검색 구조를 구축하고 표준 검색 엔진을 통해 쿼리를 실행합니다.

외부 데이터 위에 구축된 Milvus 인덱스

필드와 워크로드에 따라 Milvus는 다음을 구축할 수 있습니다:

ANN 검색용 벡터 인덱스;
메타데이터 필터링용 스칼라 인덱스;
반정형 속성용 JSON 인덱스;
어휘 검색용 BM25 및 전문(full-text) 인덱스.
Milvus 데이터 모델이 지원하는 함수 생성 필드.

ANN 검색은 모든 소스 벡터를 읽는 대신 이러한 인덱스를 사용하여 후보 집합을 좁힙니다.

이 구분이 중요한 이유는 임베딩을 레이크에 저장하는 것이 그 위에서 벡터 데이터베이스를 운영하는 것과 같지 않기 때문입니다. 지속성은 바이트를 제공합니다. 프로덕션 검색에는 인덱스, 쿼리 계획, 필터링, 랭킹, 캐싱 및 저지연 서빙 경로도 필요합니다.

벡터 top-K를 넘어서

또 다른 일반적인 실수는 'External Collection'을 'Parquet에 대한 벡터 검색'으로 읽는 것입니다. 이는 프로덕션 검색이 실제로 요구하는 바를 과소평가합니다.

프로덕션 검색 결과는 드물게 벡터 유사도만으로 결정됩니다. 정확한 용어, 접근 정책, 재고, 타임스탬프, 카테고리, 가격, 소스 품질 또는 비즈니스 랭킹 신호에 따라 달라질 수도 있습니다.

다음과 같은 쿼리를 고려해 보겠습니다:

여름용 빨간 플로럴 드레스, 재고 있음, 평점 높은 순

프로덕션 검색 경로는 여러 신호가 필요할 수 있습니다:

"여름 플로럴 드레스"의 의미적 유사성을 위한 벡터 유사도.
"빨간"과 같은 정확한 용어를 위한 어휘 또는 전문 검색.
재고가 없거나 평점 임계값 미만인 제품을 제거하기 위한 스칼라 필터.
여러 검색 신호를 결합하기 위한 하이브리드 검색 및 랭킹.

Milvus 3.0은 또한 서버 측 정렬, 집계 및 패싯과 같은 기능을 통해 초기 최근접 이웃 검색을 넘어 쿼리 엔진을 확장합니다.

더 넓은 관점은 External Collection이 레이크에 있는 데이터에 데이터베이스 검색 경로를 제공한다는 것입니다. 단순히 파일에서 벡터를 읽는 방법이 아닙니다.

동일한 레이크 데이터가 온라인 서빙과 오프라인 처리를 지원하는 방법

소스를 개방형 레이크 형식으로 유지해야 하는 가장 강력한 아키텍처 이유는 단순히 두 번째 복사본에 비용이 들기 때문이 아닙니다. 지속적으로 개선하는 시스템에 동일한 데이터셋을 계속 사용할 수 있게 하기 위해서입니다.

제품 카탈로그로 돌아가 보겠습니다.

낮에는 Milvus가 제품 검색, 추천 또는 에이전트 검색을 위해 External Collection을 서빙할 수 있습니다.

동시에 다른 시스템은 레이크 데이터셋에서 직접 작업할 수 있습니다:

Spark는 중복 제품을 식별할 수 있습니다.
학습 파이프라인은 새 모델에서 임베딩을 생성할 수 있습니다.
데이터 품질 작업은 잘못된 형식 또는 이상 레코드를 감지할 수 있습니다.
평가 파이프라인은 모델 버전 간 검색 품질을 비교할 수 있습니다.
배치 프로세스는 요약, 레이블 또는 추가 메타데이터를 생성할 수 있습니다.

External Collection은 그러한 작업을 자체적으로 실행하지 않습니다. Spark는 Spark로, 학습은 학습으로 남습니다. 그 역할은 이들 사이에 있는 추가 서빙-데이터 경계를 제거하는 것입니다.

오프라인 작업은 개선된 데이터나 새 필드를 레이크에 다시 쓸 수 있습니다. 이후의 Refresh는 업데이트된 소스를 Milvus 검색 경로에서 사용할 수 있게 합니다.

서빙을 위해 또 다른 권위 있는 복사본을 재구성하는 것만을 목적으로 하는 별도의 export-and-import 루프는 없습니다.

거버넌스도 명확하게 분리되어 유지됩니다. 소스 버전, 계보 및 소스 소유권은 레이크 플랫폼에 남아 있습니다. Milvus는 자체 컬렉션 수준 권한 부여와 소스를 읽는 데 필요한 자격 증명을 유지합니다. 단일 데이터 기반을 공유하는 것이 모든 보안 도메인을 단일 시스템으로 통합하는 것을 의미하지는 않습니다.

이것이 Vector Lakebase와의 연결점입니다. 레이크는 공유 데이터 기반으로 유지되고 Milvus는 그 위에 저지연 검색 레이어를 제공합니다. External Collection은 Storage V3, Snapshots, Spark 통합, 스키마 진화 및 백필과 함께 해당 아키텍처의 한 부분입니다.

External Collection이 적합한 곳—그리고 그렇지 않은 곳

External Collection은 다음과 같은 경우에 매우 적합합니다:

권위 있는 데이터가 이미 Parquet, Vortex, Lance, Iceberg 또는 기타 지원되는 외부 소스에 있는 경우.
데이터셋이 고빈도 트랜잭션 쓰기가 아닌 주로 배치로 생성되는 경우.
두 번째 서빙 복사본을 유지하는 것이 상당한 ETL, 신선도 또는 거버넌스 오버헤드를 만드는 경우.
여러 시스템이 동일한 개방형 데이터셋을 사용해야 하는 경우.
명시적 Refresh 경계가 서빙 신선도에 허용 가능한 경우.
Milvus를 소스 행의 소유자로 만들지 않고 프로덕션 Milvus 검색을 원하는 경우.

다음과 같은 경우에는 일반 Milvus 컬렉션이 여전히 더 나은 선택입니다:

애플리케이션이 레코드를 지속적으로 삽입하거나 upsert하는 경우;
삭제가 온라인 쓰기 경로를 통해 표시되어야 하는 경우;
워크로드가 외부 스키마에서 사용할 수 없는 컬렉션 기능에 의존하는 경우;
서빙 설계가 의도적으로 필요한 모든 데이터를 메모리에 유지하여 원격 캐시 미스를 피하는 경우.

몇 가지 경계를 염두에 둘 필요가 있습니다.

External Collection은 읽기 전용입니다. 소스 변경은 Milvus 외부에서 발생합니다.
제로 카피는 소스 행에 적용됩니다. 인덱스, 매니페스트, 캐시 및 컴퓨팅은 여전히 리소스를 소모합니다.
Refresh는 명시적입니다. 스트리밍 동기화 메커니즘이 아닙니다.
소스는 계속 접근 가능해야 합니다. 검색, 인덱스 및 새로 고침 동작은 여전히 스토리지 접근과 자격 증명에 따라 달라집니다.
Storage V3가 필요합니다. 오픈소스 Milvus 3.0에서 External Collection을 사용하려면 먼저 활성화해야 합니다.
External Collection은 업스트림 처리를 대체하지 않습니다. 임베딩 생성, 클러스터링, 중복 제거 및 데이터 정리는 여전히 적절한 업스트림 시스템에서 수행됩니다.

따라서 선택은 이분법적이기보다 상호 보완적입니다. 시스템은 빠르게 변화하는 온라인 상태에 일반 Milvus 컬렉션을 사용하고, 자연스러운 홈이 레이크인 대규모 배치 생성 데이터셋에는 External Collection을 사용할 수 있습니다.