Koleksi Eksternal Milvus: Mengindeks dan Mengambil Data yang Berada di Data Lake Tanpa Memindahkannya

Dalam banyak pipeline AI, embedding dan metadata sudah diproduksi dan disimpan di data lake. Pipeline produk mungkin menulis atribut produk dan embedding multimodal ke file Parquet di S3. Korpus retrieval atau training mungkin berada di tabel Iceberg atau Lance. Lake sudah menjadi tempat dataset tersebut dibuat, diperbarui, diberi versi, dan digunakan oleh seluruh stack data.

Vector database, bagaimanapun, secara tradisional dibangun di sekitar salinan penyajian (serving copy) yang dimiliki database. Jika tim menginginkan pencarian vektor berlatensi rendah pada data yang sudah berada di lake, mereka umumnya memiliki dua pilihan:

• Menyalin data ke vector database. Ini menyediakan indeks ANN dan jalur penyajian produksi, tetapi membuat salinan kedua dari dataset dan pipeline ETL yang harus tetap sinkron dengan sumbernya.
• Menanyai lake secara langsung. Ini menghindari duplikasi, tetapi tanpa lapisan indeks dan penyajian ANN, pencarian vektor kembali ke pemindaian yang tidak dirancang untuk latensi produksi.

Milvus 3.0 External Collection memperkenalkan jalur ketiga. Data sumber tetap berada di Parquet, Iceberg, Lance, Vortex, atau format eksternal lain yang didukung, sementara Milvus membangun dan menyajikan indeks di atasnya. Anda memetakan field eksternal ke skema Milvus, mendefinisikan indeks yang Anda butuhkan, me-refresh koleksi, dan menggunakan API pencarian dan kueri Milvus normal—tanpa harus menyalin baris sumber terlebih dahulu ke koleksi yang dikelola Milvus.

Perubahan arsitekturnya sederhana: data dapat tetap berada di lake, sementara Milvus menambahkan lapisan indeks dan retrieval.

Hal itu juga menjadikan External Collection langkah penting menuju Vector Lakebase, arsitektur data lake-native terpadu untuk AI yang menggabungkan penyajian kelas vector database dengan penyimpanan lake terbuka, indeks tingkat lake yang dapat digunakan kembali, dan lapisan semantik bersama. Retrieval online tidak lagi harus dimulai dari salinan penyajian terpisah sementara Spark, pipeline training, job evaluasi, dan alat tata kelola beroperasi pada versi lain dari data tersebut. Mereka dapat bekerja dari fondasi data yang sama yang berada di lake.

Apa itu External Collection, dan apa yang diubahnya

External Collection adalah jenis koleksi Milvus yang data sumbernya berada di luar penyimpanan yang dikelola Milvus.

Tanpa External Collection, menempatkan katalog tersebut di belakang pencarian vektor produksi biasanya berarti membuat salinan lain di Milvus:

Setiap kali katalog berubah, model embedding berubah, atau sebuah field di-backfill, pipeline lain harus memindahkan data yang diperbarui melintasi batas tersebut.

Dengan External Collection, arsitekturnya menjadi:

Milvus tidak menjadikan file eksternal sebagai salinan data sumbernya sendiri. Sebaliknya, External Collection berisi informasi yang dibutuhkan Milvus untuk menafsirkan dan mencari file-file tersebut:

1. Sebuah external_source yang mengidentifikasi file atau tabel eksternal.
2. Sebuah external_spec yang mendeskripsikan format sumber dan akses penyimpanan.
3. Pemetaan external_field yang menghubungkan field di skema Milvus ke kolom di dataset eksternal.
4. Indeks, manifest, dan status penyajian yang dibuat Milvus untuk retrieval.

Data sumber zero-copy tidak berarti tanpa status di dalam Milvus. Milvus tetap membangun indeks. Milvus tetap menggunakan komputasi. Milvus tetap menyimpan data dalam cache. Perubahannya adalah baris otoritatif tidak lagi harus disalin ke Milvus hanya karena Anda membutuhkan Milvus untuk mencarinya.

Koleksi Milvus Normal vs. External Collection

Aspek	Koleksi yang dikelola Milvus	External Collection
Catatan sumber	Disimpan dan dikelola oleh Milvus	Tetap di file atau tabel eksternal
Bagaimana data masuk ke Milvus	Insert, upsert, import, atau streaming write	Pemetaan sumber eksternal + Refresh
Mutasi online	Didukung	Hanya baca dari Milvus
Kesegaran (freshness)	Mengikuti jalur penulisan dan model konsistensi Milvus	Mengikuti Refresh terakhir yang berhasil dipublikasikan
Status yang dikelola Milvus	Data sumber, metadata, indeks, cache	Pemetaan, manifest, indeks, cache
Jalur kueri	API pencarian dan kueri Milvus	API pencarian dan kueri Milvus
Cocok untuk	Data online yang terus berubah	Data lake berukuran besar, diproduksi secara batch, dengan banyak pembacaan

External Collection karena itu melengkapi koleksi Milvus normal, bukan menggantikannya.

Sebuah sistem dapat menyimpan status online yang berubah cepat di koleksi Milvus normal sambil menggunakan External Collection untuk korpus besar, katalog, dataset historis, fitur model, atau data lain yang sudah diproduksi dan dikelola di lake.

Mengapa menghilangkan salinan kedua itu penting

Sangat menggoda untuk menggambarkan External Collection sebagai optimasi penyimpanan: jangan salin beberapa terabyte data ke database lain, dan Anda menghemat penyimpanan. Itu berguna, tetapi bukan masalah arsitektural utama.

Biaya yang lebih tinggi berasal dari menjaga dua sistem data tetap selaras.

Pertimbangkan kembali katalog produk. Platform data memproduksi dataset Parquet otoritatif. Search mengimpornya ke vector database. Tim rekomendasi mungkin membaca data lake yang sama melalui Spark untuk analisis offline. Sebuah model embedding baru kemudian menghasilkan kolom vektor pengganti. Inventaris dan metadata terus berubah secara bersamaan.

Begitu salinan penyajian online menjadi independen dari lake, setiap perubahan harus melintasi batas tersebut:

• data perlu disalin;
• transfer perlu dijadwalkan dan dipantau;
• job yang gagal memerlukan percobaan ulang;
• skema dan izin mungkin perlu direpresentasikan di beberapa sistem;
• kesegaran bergantung pada seberapa cepat pipeline sinkronisasi mengejar ketertinggalan;
• tim harus tahu salinan mana yang mewakili versi yang sebenarnya mereka inginkan.

Penyimpanan hanyalah satu item baris.

Biaya	Salinan lake + serving terpisah	External Collection
Salinan data sumber	Salinan lake ditambah salinan serving terpisah	Baris sumber tetap di lake
Perpindahan data	Pipeline ETL/import yang persisten	Refresh atas sumber eksternal
Kesegaran	Tergantung pada irama ekspor/impor	Dikendalikan oleh kapan Refresh baru dipublikasikan
Tata kelola	Salinan sumber dan serving harus tetap selaras	Kepemilikan sumber, lineage, dan versioning tetap di platform lake
Penggunaan kembali offline	Konsumen lain mungkin menyiapkan salinan mereka sendiri	Alat lake yang ada dapat terus membaca sumber yang sama
Resource serving	Disetel berdasarkan salinan database dan beban kueri	Komputasi indeks, kueri, dan cache dapat dikelola terpisah dari kepemilikan baris sumber

Perbedaan ini menjadi sangat penting seiring data AI yang berubah lebih sering.

Tim melakukan deduplikasi korpus. Mereka mengelompokkan data untuk analisis. Mereka menghasilkan embedding baru ketika model berubah. Mereka menambahkan label, ringkasan, entitas yang diekstrak, skor kualitas, atau sinyal umpan balik. Mereka menjalankan job evaluasi dan pipeline pembersihan data pada korpus yang sama yang diambil oleh aplikasi produksi.

Jika setiap sistem memiliki salinannya sendiri, setiap perbaikan menjadi job sinkronisasi tambahan.

External Collection mengubah batas tersebut: sistem offline dapat terus bekerja pada dataset lake, sementara Milvus menyajikan retrieval pada fondasi yang sama.

Sumber data apa yang didukung External Collection

External Collection dirancang di sekitar data terbuka yang dikelola secara eksternal, bukan tata letak sumber khusus Milvus. External Collection mendukung beberapa format sumber eksternal melalui Storage V3:

Format eksternal	Nilai format	Apa yang dibaca Milvus
Apache Parquet	parquet	Direktori atau prefiks object-storage yang berisi file Parquet dan row group
Vortex	vortex	File Vortex dan metadata tata letaknya
Lance	lance-table	Dataset Lance dan metadata fragmennya
Apache Iceberg	iceberg-table	Metadata Iceberg ditambah snapshot yang dipilih
Snapshot Milvus	milvus-table	Snapshot Milvus yang didukung yang diekspos sebagai sumber eksternal

Pemetaan antara sumber dan Milvus bersifat eksplisit.

Kolom sumber bernama product_id dapat menjadi field Milvus id; image_vec dapat menjadi embedding; dan tabel sumber yang lebar tidak perlu mengekspos setiap kolom ke koleksi. Itu berarti platform data tidak harus mengganti nama atau menulis ulang sumbernya hanya untuk memenuhi database penyajian.

Format berversi menambahkan properti berguna lainnya. Dengan sumber seperti Iceberg, koleksi dapat menunjuk ke snapshot tertentu daripada apa pun yang kebetulan berlaku saat kueri dijalankan. Versi sumber tetap berguna untuk evaluasi yang dapat diulang, pengujian regresi, analisis historis, dan beban kerja audit.

File yang mendasarinya juga tetap dapat digunakan oleh seluruh stack data. Spark, framework training, sistem tata kelola, dan alat lain yang kompatibel dengan lake dapat terus membaca data terbuka yang sama.

External Collection menambahkan satu konsumen lagi untuk data tersebut; ini tidak menjadikan Milvus sebagai satu-satunya pemiliknya.

Mengakses penyimpanan eksternal dengan aman

Milvus juga memerlukan izin untuk membaca penyimpanan eksternal.

Tergantung pada penyedia penyimpanan, deployment dapat menggunakan mekanisme seperti workload atau instance identity, asumsi peran AWS STS, impersonasi service account, akses berbasis SAS, atau sistem peran khusus penyedia alih-alih menyematkan kredensial berumur panjang di konfigurasi aplikasi.

Identitas penyimpanan ini mengontrol bagaimana Milvus menjangkau sumbernya. Otorisasi di dalam Milvus tetap menjadi batas keamanan yang terpisah.

Cara membuat, mengindeks, me-refresh, dan menanyai external collection

Siklus hidup External Collection memiliki empat langkah utama:

1. Definisikan sumber eksternal dan petakan kolomnya ke dalam skema Milvus.
2. Definisikan indeks yang dibutuhkan beban kerja.
3. Jalankan Refresh sehingga Milvus menemukan data sumber dan menyiapkan versi yang dapat ditanyai.
4. Load koleksi dan gunakan API pencarian dan kueri Milvus normal.

Berikut adalah katalog produk yang sama yang direpresentasikan sebagai 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,
)

Indeks menggunakan antarmuka Milvus normal:

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,
)

Kemudian refresh sumber eksternal:

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)

Setelah versi yang di-refresh siap, load dan cari seperti koleksi Milvus normal:

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”],
)

Perbedaan pentingnya bukan pada panggilan pencariannya. Perbedaannya adalah di mana siklus hidup dimulai. Koleksi yang dikelola Milvus dimulai dengan data yang ditulis atau diimpor ke Milvus. External Collection dimulai dengan referensi ke data yang sudah ada di tempat lain.

Bagaimana Refresh menangkap perubahan pada data eksternal

External Collection bersifat hanya-baca dari sisi Milvus, tetapi dataset lake yang mendasarinya tidak harus tetap membeku selamanya.

Misalkan pipeline produk menambahkan batch lain, memperbarui metadata, atau menulis embedding dari model baru. Milvus tidak terus-menerus mengikuti setiap objek yang muncul di jalur sumber. Perubahan tersebut menjadi terlihat melalui Refresh.

Refresh membaca metadata eksternal, menyelesaikan fragmen sumber, memperbarui manifest yang menghubungkannya ke koleksi Milvus, dan menyiapkan status indeks yang sesuai.

Kuncinya adalah pekerjaan ini dapat dilakukan secara inkremental.

Milvus mengidentifikasi fragmen sumber yang tidak berubah dan dapat menggunakan kembali pekerjaan segmen dan indeks yang sudah ada. Fragmen baru atau yang berubah adalah bagian yang memerlukan pemrosesan baru.

Perubahan kecil pada dataset multi-terabyte, oleh karena itu, tidak harus memicu import penuh dan pembangunan ulang indeks penuh lagi.

Refresh juga memberikan batas versi yang jelas pada sistem penyajian. Sementara versi baru sedang disiapkan, kueri terus menggunakan status yang dipublikasikan sebelumnya. Setelah Refresh selesai, status baru tersedia sebagai versi lengkap, bukan mengekspos campuran data lama dan data yang baru disiapkan sebagian.

Model ini cocok secara alami dengan pembangunan katalog per jam, pembaruan basis pengetahuan malam hari, refresh embedding berkala, pipeline fitur yang dihasilkan model, dan beban kerja berorientasi batch serupa.

Ini tidak menggantikan jalur streaming write. Jika setiap insert atau delete harus segera dapat dicari melalui Milvus, koleksi terkelola tetap menjadi model yang lebih baik.

Bagaimana Lazy Loading mengurangi penggunaan memori untuk dataset lebar

Menyimpan baris sumber di object storage hanya membantu jika lapisan penyajian tidak harus memuat setiap byte secara lokal sebelum dapat menjawab kueri. Dengan Milvus Tiered Storage yang diaktifkan, hal itu tidak terjadi.

Pada saat load koleksi, QueryNodes awalnya hanya menyimpan metadata ringan seperti informasi skema, definisi indeks, peta chunk, dan referensi ke objek jarak jauh. Data field diambil di tingkat chunk ketika kueri membutuhkannya; indeks dapat tetap di remote sampai penggunaan pertama, kemudian di-cache secara lokal. Data yang sering digunakan tetap panas, sementara data yang jarang diakses dapat di-evict.

Ini sangat berguna untuk dataset AI yang lebar.

Sebuah baris produk mungkin berisi beberapa embedding, deskripsi panjang, JSON mentah, metadata gambar, ringkasan yang dihasilkan, inventaris, harga, rating, dan banyak atribut lainnya. Pencarian kemiripan yang khas mungkin hanya menyentuh satu vektor ditambah inventaris, harga, dan rating. Tidak ada alasan setiap field lain harus secara permanen menempati memori penyajian hanya karena field tersebut milik record yang sama.

External Collection dapat mempersempit jejak penyajian di dua tingkat:

• Pertama, proyeksi tingkat skema. Melalui external_field, External Collection dapat mengekspos hanya kolom sumber yang dibutuhkan aplikasi. Kolom lain tetap di dataset lake dan tidak disertakan dalam skema penyajian ini.
• Kedua, proyeksi runtime. Di bawah model penyajian bertingkat, QueryNodes mengambil dan meng-cache field serta indeks yang benar-benar dibutuhkan beban kerja, alih-alih memuat seluruh dataset yang dipetakan di awal.

Dengan kata lain, dataset dapat tetap lebar di lake tanpa memaksa jejak penyajian menjadi sama lebarnya.

Ada tradeoff yang jelas. Kueri yang mengenai field atau indeks dingin mungkin membayar biaya pembacaan jarak jauh pada akses pertama. Kebijakan warm-up dapat memuat terlebih dahulu field atau indeks yang kritis terhadap latensi, sementara kebijakan cache dan eviction mencegah status yang jarang diakses menempati resource lokal tanpa batas waktu.

Intinya bukan bahwa object storage berperilaku seperti RAM. Intinya adalah memori dan disk lokal dapat mengikuti working set dari beban kerja retrieval, bukan ukuran total dan lebar dataset sumber.

Format sumber juga berperan di sini. Format yang dirancang untuk pemindaian analitis luas dan format yang dioptimalkan untuk pembacaan yang lebih sempit atau acak dapat menghasilkan perilaku I/O yang berbeda di bawah akses on-demand. External Collection tidak menghapus tradeoff tingkat penyimpanan tersebut; ini memungkinkan Milvus membangun lapisan retrieval di atasnya.

Kemampuan pencarian dan pengindeksan apa yang didukung External Collection

External Collection tidak sekadar mengarahkan Milvus ke direktori embedding dan memindai file-file tersebut. Milvus membangun struktur retrieval di atas data eksternal dan mengeksekusi kueri melalui mesin retrieval standarnya.

Indeks Milvus yang dibangun di atas data eksternal

Tergantung pada field dan beban kerja, Milvus dapat membangun:

• indeks vektor untuk pencarian ANN;
• indeks skalar untuk pemfilteran metadata;
• indeks JSON untuk atribut semi-terstruktur;
• indeks BM25 dan full-text untuk retrieval leksikal.
• field yang dihasilkan fungsi yang didukung oleh model data Milvus.

Pencarian ANN menggunakan indeks tersebut untuk mempersempit kumpulan kandidat alih-alih membaca setiap vektor sumber.

Perbedaan itu penting karena menyimpan embedding di lake tidak sama dengan mengoperasikan vector database di atasnya. Persistensi memberi Anda byte. Retrieval produksi juga membutuhkan indeks, perencanaan kueri, pemfilteran, peringkat, caching, dan jalur penyajian berlatensi rendah.

Melampaui top-K vektor

Kesalahan umum lainnya adalah membaca "External Collection" sebagai "pencarian vektor atas Parquet." Itu meremehkan apa yang sebenarnya dibutuhkan retrieval produksi.

Hasil pencarian produksi jarang bergantung pada kemiripan vektor saja. Hasil tersebut mungkin juga bergantung pada istilah yang tepat, kebijakan akses, inventaris, timestamp, kategori, harga, kualitas sumber, atau sinyal peringkat bisnis.

Pertimbangkan kueri seperti:

gaun floral merah untuk musim panas, tersedia, rating tertinggi didahulukan

Jalur retrieval produksi mungkin membutuhkan beberapa sinyal:

• Kemiripan vektor untuk makna semantik dari "gaun floral musim panas."
• Pencarian leksikal atau full-text untuk istilah yang tepat seperti "merah."
• Filter skalar untuk menghapus produk yang tidak tersedia atau di bawah ambang rating.
• Retrieval hibrida dan peringkat untuk menggabungkan beberapa sinyal retrieval.

Milvus 3.0 juga memperluas mesin kueri melampaui retrieval tetangga terdekat awal dengan kemampuan seperti pengurutan sisi server, agregasi, dan faceting.

Poin yang lebih luas adalah External Collection memberikan jalur retrieval database untuk data yang berada di lake—bukan sekadar cara membaca vektor dari file.

Bagaimana data lake yang sama mendukung penyajian online dan pemrosesan offline

Alasan arsitektural terkuat untuk menjaga sumber tetap dalam format lake terbuka bukan sekadar karena salinan kedua membutuhkan biaya. Alasannya adalah dataset yang sama dapat tetap tersedia bagi sistem yang terus memperbaikinya.

Kembali ke katalog produk.

Sepanjang hari, Milvus dapat menyajikan External Collection untuk pencarian produk, rekomendasi, atau retrieval agen.

Pada saat yang sama, sistem lain dapat bekerja langsung pada dataset lake:

• Spark dapat mengidentifikasi produk duplikat.
• Pipeline training dapat menghasilkan embedding dari model baru.
• Job kualitas data dapat mendeteksi record yang salah format atau anomali.
• Pipeline evaluasi dapat membandingkan kualitas retrieval antar versi model.
• Proses batch dapat menghasilkan ringkasan, label, atau metadata tambahan.

External Collection tidak menjalankan job tersebut sendiri. Spark tetap Spark; training tetap training. Perannya adalah menghilangkan batas data penyajian tambahan di antara mereka.

Pekerjaan offline dapat menulis data yang lebih baik atau field baru kembali ke lake. Refresh berikutnya membuat sumber yang diperbarui tersedia untuk jalur retrieval Milvus.

Tidak ada loop ekspor-dan-impor terpisah yang satu-satunya tujuan adalah merekonstruksi salinan otoritatif lain untuk penyajian.

Tata kelola juga tetap terbagi dengan bersih. Versi sumber, lineage, dan kepemilikan sumber tetap berada di platform lake. Milvus mempertahankan otorisasi tingkat koleksinya sendiri dan kredensial yang diperlukan untuk membaca sumber. Berbagi satu fondasi data tidak berarti meruntuhkan setiap domain keamanan menjadi satu sistem tunggal.

Inilah hubungannya dengan Vector Lakebase: lake tetap menjadi fondasi data bersama, sementara Milvus menyediakan lapisan retrieval berlatensi rendah di atasnya. External Collection adalah salah satu bagian dari arsitektur tersebut, bersama dengan Storage V3, Snapshots, integrasi Spark, evolusi skema, dan backfill.

Di mana External Collection cocok—dan di mana tidak

External Collection sangat cocok ketika:

• Data otoritatif Anda sudah berada di Parquet, Vortex, Lance, Iceberg, atau sumber eksternal lain yang didukung.
• Dataset terutama diproduksi dalam batch, bukan melalui penulisan transaksional berfrekuensi tinggi.
• Mempertahankan salinan penyajian kedua menciptakan overhead ETL, kesegaran, atau tata kelola yang signifikan.
• Banyak sistem perlu bekerja dengan dataset terbuka yang sama.
• Batas Refresh yang eksplisit dapat diterima untuk kesegaran penyajian.
• Anda menginginkan retrieval Milvus produksi tanpa menjadikan Milvus pemilik baris sumber.

Koleksi Milvus normal masih menjadi pilihan yang lebih baik ketika:

• aplikasi terus-menerus melakukan insert atau upsert record;
• delete perlu menjadi terlihat melalui jalur penulisan online;
• beban kerja bergantung pada fitur koleksi yang tidak tersedia untuk skema eksternal;
• desain penyajian sengaja menyimpan semua data yang diperlukan di memori, menghindari cache miss jarak jauh.

Beberapa batas perlu diingat.

• External Collection bersifat hanya-baca. Perubahan sumber terjadi di luar Milvus.
• Zero-copy berlaku untuk baris sumber. Indeks, manifest, cache, dan komputasi tetap membutuhkan resource.
• Refresh bersifat eksplisit. Ini bukan mekanisme sinkronisasi streaming.
• Sumber harus tetap dapat dijangkau. Perilaku pencarian, indeks, dan refresh tetap bergantung pada akses penyimpanan dan kredensial.
• Storage V3 wajib digunakan. Di Milvus open-source 3.0, Storage V3 harus diaktifkan sebelum menggunakan External Collection.
• External Collection tidak menggantikan pemrosesan hulu. Pembuatan embedding, clustering, deduplikasi, dan pembersihan data tetap terjadi di sistem hulu yang sesuai.

Pilihannya karena itu bersifat saling melengkapi, bukan biner. Sebuah sistem dapat menggunakan koleksi Milvus normal untuk status online yang berubah cepat dan External Collection untuk dataset besar yang diproduksi secara batch yang rumah alaminya adalah lake.

Coba External Collection di Milvus 3.0

External Collection tersedia di Milvus 3.0. Mulailah dengan dataset lake yang representatif dan evaluasi aspek yang penting untuk beban kerja Anda: refresh awal dan inkremental, biaya pembangunan indeks, perilaku kueri panas dan dingin, serta interval kesegaran yang dibutuhkan aplikasi Anda.

Untuk detail implementasi, lihat:

• Membuat External Collection
• Catatan rilis Milvus 3.0
• Blog peluncuran Milvus 3.0

Jika Anda lebih memilih jalur terkelola, External Collection juga tersedia sebagai bagian dari Zilliz Vector Lakebase di Zilliz Cloud. Lihat:

• External Collection di Zilliz Cloud
• Dari Vector Database ke Vector Lakebase
• Mengapa Kami Membangun Vector Lakebase: Memikirkan Ulang Arsitektur Data Tidak Terstruktur untuk AI

Anda juga dapat menyampaikan pertanyaan implementasi atau masukan ke repositori GitHub Milvus atau komunitas Discord Milvus.