Home
Blog
Berhenti Membayar untuk Data Dingin: Pengurangan Biaya 80% dengan Pemuatan Data Panas-Dingin Sesuai Permintaan di Penyimpanan Berjenjang Milvus

Berhenti Membayar untuk Data Dingin: Pengurangan Biaya 80% dengan Pemuatan Data Panas-Dingin Sesuai Permintaan di Penyimpanan Berjenjang Milvus

Engineering

December 15, 2025

Buqian Zheng

Berapa banyak dari Anda yang masih membayar tagihan infrastruktur premium untuk data yang hampir tidak pernah disentuh oleh sistem Anda? Jujur saja - sebagian besar tim masih melakukannya.

Jika Anda menjalankan pencarian vektor dalam produksi, Anda mungkin pernah melihat hal ini secara langsung. Anda menyediakan memori dan SSD dalam jumlah besar agar semuanya tetap "siap untuk kueri," meskipun hanya sebagian kecil dari kumpulan data Anda yang benar-benar aktif. Dan Anda tidak sendirian. Kami telah melihat banyak kasus serupa juga:

Platform SaaS multi-penyewa: Ratusan penyewa yang bergabung, tetapi hanya 10-15% yang aktif pada hari tertentu. Sisanya hanya diam saja tetapi masih menghabiskan sumber daya.
Sistem rekomendasi e-commerce: Sejuta SKU, namun 8% produk teratas menghasilkan sebagian besar rekomendasi dan lalu lintas pencarian.
Pencarian AI: Arsip penyematan yang sangat banyak, meskipun 90% dari kueri pengguna mengenai item dari minggu lalu.

Ini adalah cerita yang sama di seluruh industri: kurang dari 10% data Anda sering ditanyakan, tetapi sering kali menghabiskan 80% penyimpanan dan memori Anda. Semua orang tahu bahwa ketidakseimbangan itu ada - tetapi sampai saat ini, belum ada cara arsitektural yang jelas untuk memperbaikinya.

Hal itu berubah dengan Milvus 2.6.

Sebelum rilis ini, Milvus (seperti kebanyakan basis data vektor) bergantung pada model muatan penuh: jika data perlu dicari, data tersebut harus dimuat ke simpul-simpul lokal. Tidak masalah apakah data itu diakses seribu kali dalam satu menit atau seperempat menit sekali - semuanya harus tetap panas. Pilihan desain tersebut memastikan kinerja yang dapat diprediksi, tetapi juga berarti cluster yang terlalu besar dan membayar sumber daya yang tidak layak untuk data dingin.

Penyimpanan Berjenjang adalah jawaban kami.

Milvus 2.6 memperkenalkan arsitektur penyimpanan berjenjang baru dengan pemuatan sesuai permintaan yang sebenarnya, sehingga sistem dapat membedakan antara data panas dan data dingin secara otomatis:

Segmen panas tetap tersimpan di dalam cache dekat dengan komputasi
Segmen dingin disimpan dengan murah di penyimpanan objek jarak jauh
Data ditarik ke node lokal hanya ketika kueri benar-benar membutuhkannya

Hal ini mengubah struktur biaya Anda dari "berapa banyak data yang Anda miliki" menjadi "berapa banyak data yang benar-benar Anda gunakan." Dan dalam penerapan produksi awal, pergeseran sederhana ini menghasilkan pengurangan biaya penyimpanan dan memori hingga 80%.

Di bagian selanjutnya dari artikel ini, kami akan menjelaskan cara kerja Tiered Storage, membagikan hasil kinerja nyata, dan menunjukkan di mana perubahan ini memberikan dampak terbesar.

Mengapa Pemuatan Penuh Rusak pada Skala Besar

Sebelum masuk ke dalam solusi, ada baiknya kita melihat lebih dekat mengapa mode beban penuh yang digunakan di Milvus 2.5 dan rilis sebelumnya menjadi faktor pembatas saat beban kerja meningkat.

Pada Milvus 2.5 dan sebelumnya, ketika pengguna mengeluarkan permintaan Collection.load(), setiap QueryNode men-cache seluruh koleksi secara lokal, termasuk metadata, data lapangan, dan indeks. Komponen-komponen ini diunduh dari penyimpanan objek dan disimpan sepenuhnya dalam memori atau dipetakan dalam memori (mmap) ke disk lokal. Hanya setelah semua data ini tersedia secara lokal, koleksi ditandai sebagai dimuat dan siap untuk melayani kueri.

Dengan kata lain, koleksi tidak dapat di-query hingga seluruh dataset-panas atau dingin-tersedia di dalam node.

Catatan: Untuk jenis indeks yang menyematkan data vektor mentah, Milvus hanya memuat file indeks, bukan bidang vektor secara terpisah. Meskipun demikian, indeks harus dimuat secara penuh untuk melayani kueri, terlepas dari berapa banyak data yang sebenarnya diakses.

Untuk melihat mengapa hal ini menjadi masalah, pertimbangkan sebuah contoh konkret:

Misalkan Anda memiliki kumpulan data vektor berukuran sedang dengan:

100 juta vektor
768 dimensi (penyematan BERT)
presisifloat32 (4 byte per dimensi)
Indeks HNSW

Dalam pengaturan ini, indeks HNSW saja-termasuk vektor mentah yang disematkan-menghabiskan sekitar 430 GB memori. Setelah menambahkan bidang skalar umum seperti ID pengguna, stempel waktu, atau label kategori, total penggunaan sumber daya lokal dengan mudah melebihi 500 GB.

Ini berarti bahwa meskipun 80% data jarang atau tidak pernah ditanyakan, sistem masih harus menyediakan dan menyimpan lebih dari 500 GB memori lokal atau disk hanya untuk menjaga koleksi tetap online.

Untuk beberapa beban kerja, perilaku ini dapat diterima:

Jika hampir semua data sering diakses, memuat semuanya secara penuh akan menghasilkan latensi kueri serendah mungkin - dengan biaya tertinggi.
Jika data dapat dibagi menjadi subset panas dan hangat, pemetaan memori data hangat ke disk dapat mengurangi sebagian tekanan memori.

Namun, dalam beban kerja di mana 80% atau lebih data berada di bagian ekor panjang, kelemahan pemuatan penuh muncul dengan cepat, baik dalam hal kinerja maupun biaya.

Kemacetan kinerja

Dalam praktiknya, pemuatan penuh memengaruhi lebih dari sekadar kinerja kueri dan sering kali memperlambat alur kerja operasional rutin:

Peningkatan bergulir yang lebih lama: Dalam cluster besar, peningkatan bergulir dapat memakan waktu berjam-jam atau bahkan sehari penuh, karena setiap node harus memuat ulang seluruh dataset sebelum tersedia kembali.
Pemulihan yang lebih lambat setelah kegagalan: Ketika QueryNode dimulai ulang, QueryNode tidak dapat melayani lalu lintas hingga semua data dimuat ulang, yang secara signifikan memperpanjang waktu pemulihan dan memperbesar dampak kegagalan node.
Iterasi dan eksperimen yang lebih lambat: Pemuatan penuh memperlambat alur kerja pengembangan, memaksa tim AI menunggu berjam-jam hingga data dimuat saat menguji set data atau konfigurasi indeks baru.

Inefisiensi biaya

Pemuatan penuh juga meningkatkan biaya infrastruktur. Misalnya, pada instance yang dioptimalkan untuk memori cloud utama, menyimpan 1 TB data secara lokal membutuhkan biaya sekitar $berdasarkan harga kons$ $70.000 per tahun**, berdasarkan harga konservatif (AWS r6i: ~$ $*$ $berdasarkan harga$ : $5.74 / GB/bulan; GCP n4-highmem: ~5$ $. 68/GB/bulan; AzureE-series :$ 5 $.68/GB/bulan; Azure E-series: ~$ 5 $. 68/GB/bulan; AzureE -$ $seri$ : $5.67 / GB/bulan).$

Sekarang pertimbangkan pola akses yang lebih realistis, di mana 80% dari data tersebut adalah data dingin dan dapat disimpan di penyimpanan objek sebagai gantinya (dengan biaya sekitar $ 0,023 / GB / bulan):

200 GB data panas × $5,68
800 GB data dingin × $0,023

Biaya tahunan: (200 × 5,68 + 800 × 0,023) × 12≈ $14.000

Itu adalah pengurangan 80% dalam total biaya penyimpanan, tanpa mengorbankan performa yang sebenarnya penting.

Apa Itu Penyimpanan Berjenjang dan Bagaimana Cara Kerjanya?

Untuk menghilangkan trade-off, Milvus 2.6 memperkenalkan Penyimpanan Berjenjang, yang menyeimbangkan performa dan biaya dengan memperlakukan penyimpanan lokal sebagai cache, bukan sebagai wadah untuk seluruh dataset.

Dalam model ini, QueryNodes hanya memuat metadata ringan saat startup. Data lapangan dan indeks diambil sesuai permintaan dari penyimpanan objek jarak jauh ketika kueri membutuhkannya, dan di-cache secara lokal jika sering diakses. Data yang tidak aktif dapat digusur untuk mengosongkan ruang.

Hasilnya, data panas tetap berada di dekat lapisan komputasi untuk kueri latensi rendah, sementara data dingin tetap berada di penyimpanan objek hingga dibutuhkan. Hal ini mengurangi waktu muat, meningkatkan efisiensi sumber daya, dan memungkinkan QueryNodes untuk melakukan kueri terhadap set data yang jauh lebih besar daripada memori lokal atau kapasitas disk.

Dalam praktiknya, Penyimpanan Berjenjang bekerja sebagai berikut:

Menyimpan data yang penting secara lokal: Sekitar 20% data yang sering diakses tetap berada di node lokal, memastikan latensi rendah untuk 80% kueri yang paling penting.
Memuat data dingin sesuai permintaan: Sisa 80% data yang jarang diakses diambil hanya jika diperlukan, sehingga membebaskan sebagian besar memori lokal dan sumber daya disk.
Beradaptasi secara dinamis dengan penggusuran berbasis LRU: Milvus menggunakan strategi penggusuran LRU (Least Recently Used) untuk terus menyesuaikan data mana yang dianggap panas atau dingin. Data yang tidak aktif secara otomatis digusur untuk memberi ruang bagi data yang baru diakses.

Dengan desain ini, Milvus tidak lagi dibatasi oleh kapasitas tetap dari memori lokal dan disk. Sebaliknya, sumber daya lokal berfungsi sebagai cache yang dikelola secara dinamis, di mana ruang terus menerus diambil kembali dari data yang tidak aktif dan dialokasikan kembali ke beban kerja yang aktif.

Di balik tenda, perilaku ini diaktifkan oleh tiga mekanisme teknis inti:

1. Beban Malas

Pada inisialisasi, Milvus hanya memuat metadata tingkat segmen yang minimal, sehingga koleksi dapat langsung di-query segera setelah dijalankan. Data lapangan dan file indeks tetap berada di penyimpanan jarak jauh dan diambil sesuai permintaan selama eksekusi kueri, sehingga menjaga memori lokal dan penggunaan disk tetap rendah.

Bagaimana pemuatan koleksi bekerja di Milvus 2.5

Cara kerja pemuatan malas di Milvus 2.6 dan yang lebih baru

Metadata yang dimuat selama inisialisasi terbagi dalam empat kategori utama:

Statistik segmen (Informasi dasar seperti jumlah baris, ukuran segmen, dan metadata skema)
Stempel waktu (Digunakan untuk mendukung kueri penelusuran waktu)
Menyisipkan dan menghapus catatan (Diperlukan untuk menjaga konsistensi data selama eksekusi kueri)
Filter Bloom (Digunakan untuk pemfilteran awal yang cepat untuk menghilangkan segmen yang tidak relevan dengan cepat)

2. Pemuatan Sebagian

Sementara Lazy loading mengontrol kapan data dimuat, partial loading mengontrol berapa banyak data yang dimuat. Setelah kueri atau pencarian dimulai, QueryNode melakukan pemuatan parsial, hanya mengambil potongan data yang diperlukan atau file indeks dari penyimpanan objek.

Indeks vektor: Pemuatan yang sadar penyewa

Salah satu kemampuan yang paling berdampak yang diperkenalkan di Milvus 2.6+ adalah pemuatan indeks vektor yang sadar-penyewa, yang dirancang khusus untuk beban kerja multi-penyewa.

Ketika sebuah kueri mengakses data dari satu penyewa, Milvus hanya memuat bagian dari indeks vektor milik penyewa tersebut, dan melewatkan data indeks untuk semua penyewa lainnya. Hal ini membuat sumber daya lokal tetap terfokus pada penyewa yang aktif.

Desain ini memberikan beberapa manfaat:

Indeks vektor untuk penyewa yang tidak aktif tidak menggunakan memori lokal atau disk
Data indeks untuk penyewa aktif tetap tersimpan di cache untuk akses latensi rendah
Kebijakan penggusuran LRU tingkat penyewa memastikan penggunaan cache yang adil di seluruh penyewa

Bidang skalar: Pemuatan parsial tingkat kolom

Pemuatan parsial juga berlaku untuk bidang skalar, yang memungkinkan Milvus memuat hanya kolom yang secara eksplisit direferensikan oleh kueri.

Pertimbangkan sebuah koleksi dengan 50 kolom skema, seperti id, vector, title, description, category, price, stock, dan tags, dan Anda hanya perlu mengembalikan tiga kolom -id, title, dan price.

Dalam Milvus 2.5, semua 50 bidang skalar dimuat terlepas dari persyaratan kueri.
Pada Milvus 2.6+, hanya tiga field yang diminta yang dimuat. Sisa 47 field yang lain tidak dimuat dan hanya diambil secara malas jika akan diakses kemudian.

Penghematan sumber daya bisa sangat besar. Jika setiap bidang skalar menempati 20 GB:

Memuat semua bidang membutuhkan 1.000 GB (50 × 20 GB)
Memuat hanya tiga bidang yang diperlukan menggunakan 60 GB

Ini merupakan pengurangan 94% dalam pemuatan data skalar, tanpa memengaruhi kebenaran kueri atau hasil.

Catatan: Pemuatan parsial yang sadar penyewa untuk bidang skalar dan indeks vektor akan secara resmi diperkenalkan dalam rilis yang akan datang. Setelah tersedia, fitur ini akan semakin mengurangi latensi pemuatan dan meningkatkan performa kueri dingin dalam penerapan multi-penyewa yang besar.

3. Penggusuran Cache Berbasis LRU

Pemuatan malas dan pemuatan parsial secara signifikan mengurangi jumlah data yang dibawa ke dalam memori dan disk lokal. Namun, dalam sistem yang berjalan lama, cache masih akan bertambah seiring dengan diaksesnya data baru dari waktu ke waktu. Ketika kapasitas lokal tercapai, penggusuran cache berbasis LRU mulai berlaku.

Penggusuran LRU (Least Recently Used) mengikuti aturan sederhana: data yang belum pernah diakses akan digusur terlebih dahulu. Hal ini membebaskan ruang lokal untuk data yang baru diakses sambil menjaga data yang sering digunakan tetap berada di cache.

Evaluasi Kinerja: Penyimpanan Berjenjang vs Pemuatan Penuh

Untuk mengevaluasi dampak dunia nyata dari Penyimpanan Berjenjang, kami menyiapkan lingkungan pengujian yang sangat mirip dengan beban kerja produksi. Kami membandingkan Milvus dengan dan tanpa Penyimpanan Bertingkat di lima dimensi: waktu muat, penggunaan sumber daya, performa kueri, kapasitas efektif, dan efisiensi biaya.

Penyiapan eksperimental

Kumpulan data

100 juta vektor dengan 768 dimensi (penyematan BERT)
Ukuran indeks vektor: sekitar 430 GB
10 bidang skalar, termasuk ID, stempel waktu, dan kategori

Konfigurasi perangkat keras

1 QueryNode dengan 4 vCPU, memori 32 GB, dan SSD NVMe 1 TB
Jaringan 10 Gbps
Cluster penyimpanan objek MinIO sebagai backend penyimpanan jarak jauh

Pola akses

Kueri mengikuti distribusi akses panas-dingin yang realistis:

80% dari kueri menargetkan data dari 30 hari terakhir (≈20% dari total data)
15% data target dari 30-90 hari (≈30% dari total data)
5% data target yang lebih tua dari 90 hari (≈50% dari total data)

Hasil utama

1. Waktu muat 33× lebih cepat

Tahap	Milvus 2.5	Milvus 2.6+ (Penyimpanan Berjenjang)	Percepatan
Pengunduhan data	22 menit	28 detik	47×
Pemuatan indeks	3 menit	17 detik	10.5×
Total	25 menit	45 detik	33×

Pada Milvus 2.5, memuat koleksi membutuhkan waktu 25 menit. Dengan Penyimpanan Berjenjang di Milvus 2.6+, beban kerja yang sama dapat diselesaikan hanya dalam waktu 45 detik, yang menunjukkan peningkatan efisiensi beban secara bertahap.

2. Pengurangan 80% dalam Penggunaan Sumber Daya Lokal

Tahap	Milvus 2.5	Milvus 2.6+ (Penyimpanan Berjenjang)	Pengurangan
Setelah memuat	430 GB	12 GB	-97%
Setelah 1 jam	430 GB	68 GB	-84%
Setelah 24 jam	430 GB	85 GB	-80%
Kondisi stabil	430 GB	85-95 GB	~80%

Pada Milvus 2.5, penggunaan sumber daya lokal tetap konstan pada 430 GB, terlepas dari beban kerja atau waktu proses. Sebaliknya, Milvus 2.6+ dimulai dengan hanya 12 GB segera setelah pemuatan.

Saat kueri berjalan, data yang sering diakses di-cache secara lokal dan penggunaan sumber daya secara bertahap meningkat. Setelah kurang lebih 24 jam, sistem menjadi stabil pada 85-95 GB, yang mencerminkan kumpulan data panas yang bekerja. Dalam jangka panjang, hal ini menghasilkan pengurangan ~ 80% dalam memori lokal dan penggunaan disk, tanpa mengorbankan ketersediaan kueri.

3. Dampak mendekati nol pada kinerja data panas

Jenis kueri	Milvus 2.5 Latensi P99	Latensi Milvus 2.6+ P99	Perubahan
Kueri data panas	15 ms	16 ms	+6.7%
Kueri data hangat	15 ms	28 ms	+86%
Kueri data dingin (akses pertama)	15 ms	120 ms	+700%
Kueri data dingin (di-cache)	15 ms	18 ms	+20%

Untuk data panas, yang menyumbang sekitar 80% dari semua kueri, latensi P99 meningkat hanya 6,7%, sehingga hampir tidak ada dampak yang terlihat dalam produksi.

Kueri data dingin menunjukkan latensi yang lebih tinggi pada akses pertama karena pemuatan sesuai permintaan dari penyimpanan objek. Namun, setelah di-cache, latensinya hanya meningkat 20%. Mengingat frekuensi akses data dingin yang rendah, pertukaran ini umumnya dapat diterima untuk sebagian besar beban kerja di dunia nyata.

4. 4.3× Kapasitas Efektif Lebih Besar

Dengan anggaran perangkat keras yang sama-delapan server dengan memori masing-masing 64 GB (total 512 GB)-Milvus 2.5 dapat memuat paling banyak 512 GB data, setara dengan sekitar 136 juta vektor.

Dengan Penyimpanan Berjenjang yang diaktifkan di Milvus 2.6+, perangkat keras yang sama dapat mendukung data sebesar 2,2 TB, atau sekitar 590 juta vektor. Ini merupakan peningkatan 4,3 kali lipat dalam kapasitas efektif, memungkinkan set data yang jauh lebih besar untuk dilayani tanpa memperluas memori lokal.

5. Pengurangan Biaya 80,1%

Dengan menggunakan set data vektor 2 TB di lingkungan AWS sebagai contoh, dan dengan asumsi 20% dari data tersebut panas (400 GB), perbandingan biayanya adalah sebagai berikut:

Item	Milvus 2.5	Milvus 2.6+ (Penyimpanan Berjenjang)	Penghematan
Biaya bulanan	$11,802	$2,343	$9,459
Biaya tahunan	$141,624	$28,116	$113,508
Tingkat tabungan	-	-	80.1%

Ringkasan Tolok Ukur

Di semua pengujian, Tiered Storage memberikan peningkatan yang konsisten dan terukur:

Waktu muat 33× lebih cepat: Waktu pemuatan koleksi berkurang dari 25 menit menjadi 45 detik.
Penggunaan sumber daya lokal 80% lebih rendah: Dalam operasi kondisi stabil, penggunaan memori dan disk lokal turun sekitar 80%.
Dampak mendekati nol pada kinerja data panas: Latensi P99 untuk data panas meningkat kurang dari 10%, mempertahankan kinerja kueri dengan latensi rendah.
Latensi terkendali untuk data dingin: Data dingin memiliki latensi yang lebih tinggi pada akses pertama, tetapi hal ini dapat diterima karena frekuensi akses yang rendah.
Kapasitas efektif 4,3 kali lebih tinggi: Perangkat keras yang sama dapat melayani 4-5 kali lebih banyak data tanpa memori tambahan.
Pengurangan biaya lebih dari 80%: Biaya infrastruktur tahunan berkurang lebih dari 80%.

Kapan Menggunakan Penyimpanan Berjenjang di Milvus

Berdasarkan hasil benchmark dan kasus produksi di dunia nyata, kami mengelompokkan kasus penggunaan Tiered Storage ke dalam tiga kategori untuk membantu Anda memutuskan apakah Tiered Storage cocok untuk beban kerja Anda.

Kasus Penggunaan yang Paling Sesuai

1. Platform pencarian vektor multi-penyewa

Karakteristik: Jumlah penyewa yang banyak dengan aktivitas yang sangat tidak merata; pencarian vektor adalah beban kerja inti.
Pola akses: Kurang dari 20% penyewa menghasilkan lebih dari 80% kueri vektor.
Manfaat yang diharapkan: Pengurangan biaya 70-80%; Ekspansi kapasitas 3-5 kali lipat.

2. Sistem rekomendasi e-commerce (beban kerja penelusuran vektor)

Karakteristik: Popularitas yang kuat condong di antara produk teratas dan produk ekor panjang.
Pola akses: 10% produk teratas menyumbang ~ 80% dari lalu lintas penelusuran vektor.
Manfaat yang diharapkan: Tidak perlu kapasitas ekstra selama acara puncak; Pengurangan biaya 60-70%.

3. Kumpulan data berskala besar dengan pemisahan panas-dingin yang jelas (dominan vektor)

Karakteristik: Dataset berskala TB atau lebih besar, dengan akses yang sangat bias terhadap data terbaru.
Pola akses: Distribusi klasik 80/20: 20% data melayani 80% kueri
Manfaat yang diharapkan: Pengurangan biaya sebesar 75-85

Kasus Penggunaan yang Sesuai

1. Beban kerja yang sensitif terhadap biaya

Karakteristik Anggaran yang ketat dengan beberapa toleransi untuk pertukaran kinerja kecil.
Pola akses: Permintaan vektor relatif terkonsentrasi.
Manfaat yang diharapkan: Pengurangan biaya 50-70%; Data dingin dapat menimbulkan latensi ~500 ms pada akses pertama, yang harus dievaluasi terhadap persyaratan SLA.

2. Penyimpanan data historis dan pencarian arsip

Karakteristik: Volume vektor historis yang besar dengan frekuensi kueri yang sangat rendah.
Pola akses: Sekitar 90% dari kueri menargetkan data terbaru.
Manfaat yang diharapkan: Mempertahankan set data historis lengkap; Menjaga biaya infrastruktur tetap dapat diprediksi dan dikendalikan

Kasus Penggunaan yang Tidak Sesuai

1. Beban kerja data panas yang seragam

Karakteristik: Semua data diakses pada frekuensi yang sama, tanpa perbedaan panas-dingin yang jelas.
Mengapa tidak cocok: Manfaat cache yang terbatas; Menambah kompleksitas sistem tanpa keuntungan yang berarti

2. Beban kerja dengan latensi sangat rendah

Karakteristik: Sistem yang sangat sensitif terhadap latensi, seperti perdagangan finansial atau penawaran waktu nyata
Mengapa tidak cocok: Variasi latensi yang kecil sekalipun tidak dapat diterima; Pemuatan penuh memberikan kinerja yang lebih dapat diprediksi

Mulai Cepat: Cobalah Penyimpanan Berjenjang di Milvus 2.6+

# Download Milvus 2.6.1+
$ wget https://github.com/milvus-io/milvus/releases/latest
# Configure Tiered Storage
$ vi milvus.yaml
queryNode.segcore.tieredStorage:
  warmup:
    scalarField: disable
    scalarIndex: disable
    vectorField: disable
    vectorIndex: disable
  evictionEnabled: true
# Launch Milvus
$ docker-compose up -d

Kesimpulan

Penyimpanan Berjenjang di Milvus 2.6 mengatasi ketidaksesuaian yang umum terjadi antara bagaimana data vektor disimpan dan bagaimana data tersebut diakses. Di sebagian besar sistem produksi, hanya sebagian kecil data yang sering dimintakan, namun model pemuatan tradisional memperlakukan semua data sama panasnya. Dengan beralih ke pemuatan sesuai permintaan dan mengelola memori lokal dan disk sebagai cache, Milvus menyelaraskan konsumsi sumber daya dengan perilaku kueri yang sebenarnya daripada asumsi kasus terburuk.

Pendekatan ini memungkinkan sistem untuk menskalakan ke set data yang lebih besar tanpa peningkatan sumber daya lokal secara proporsional, sambil menjaga kinerja hot-query sebagian besar tidak berubah. Data dingin tetap dapat diakses saat dibutuhkan, dengan latensi yang dapat diprediksi dan dibatasi, sehingga pertukaran menjadi eksplisit dan dapat dikontrol. Ketika pencarian vektor bergerak lebih dalam ke lingkungan produksi yang sensitif terhadap biaya, multi-penyewa, dan telah berjalan lama, Tiered Storage memberikan fondasi praktis untuk beroperasi secara efisien dalam skala besar.

Untuk informasi lebih lanjut tentang Penyimpanan Berjenjang, lihat dokumentasi di bawah ini:

Penyimpanan Berjenjang | Dokumentasi Milvus

Ada pertanyaan atau ingin mendalami fitur-fitur Milvus terbaru? Bergabunglah dengan saluran Discord kami atau ajukan pertanyaan di GitHub. Anda juga dapat memesan sesi tatap muka selama 20 menit untuk mendapatkan wawasan, panduan, dan jawaban atas pertanyaan Anda melalui Milvus Office Hours.