Praktik Terbaik untuk Penyimpanan BerjenjangCompatible with Milvus 2.6.4+

Milvus menyediakan Penyimpanan Berjenjang untuk membantu Anda menangani data berskala besar secara efisien sekaligus menyeimbangkan latensi kueri, kapasitas, dan penggunaan sumber daya. Panduan ini merangkum konfigurasi yang direkomendasikan untuk beban kerja yang umum dan menjelaskan alasan di balik setiap strategi penyetelan.

Sebelum Anda memulai

• Milvus v2.6.4 atau yang lebih baru

• QueryNodes harus memiliki sumber daya lokal khusus (memori dan disk). Lingkungan bersama dapat mendistorsi estimasi cache dan menyebabkan kesalahan penilaian penggusuran.

Pilih strategi yang tepat

Tiered Storage menawarkan strategi pemuatan dan caching yang fleksibel yang dapat dikombinasikan agar sesuai dengan beban kerja Anda.

Sasaran	Fokus yang disarankan	Mekanisme utama
Meminimalkan latensi kueri pertama	Memuat bidang-bidang penting secara preload	Pemanasan
Menangani data berskala besar secara efisien	Memuat sesuai permintaan	Beban Malas + Beban Parsial
Menjaga stabilitas jangka panjang	Mencegah cache meluap	Penggusuran
Menyeimbangkan kinerja dan kapasitas	Menggabungkan pramuat dan cache dinamis	Konfigurasi hibrida

Skenario 1: pengambilan waktu nyata dan latensi rendah

Kapan menggunakan

• Latensi kueri sangat penting (misalnya, rekomendasi waktu nyata atau peringkat penelusuran)

• Indeks vektor inti dan filter skalar sering diakses

• Performa yang konsisten lebih penting daripada kecepatan startup

Konfigurasi yang disarankan

# milvus.yaml
queryNode:
  segcore:
    tieredStorage:
      warmup:
        # scalar field/index warm-up to eliminate first-time latency
        scalarField: sync
        scalarIndex: sync
        # warm-up of vector fields is disabled (if the original vector is not required)
        vectorField: disable
        # vector indexes warm-up to elminate first-time latenct
        vectorIndex: sync
      # enable cache eviction, and also turn on background asynchronous eviction
      # to reduce the triggering of synchronous eviction.
      evictionEnabled: true
      backgroundEvictionEnabled: true
      memoryLowWatermarkRatio: 0.75
      memoryHighWatermarkRatio: 0.8
      diskLowWatermarkRatio: 0.75
      diskHighWatermarkRatio: 0.8
      # no expiration time, which avoids frequent reloading
      cacheTtl: 0

Dasar pemikiran

• Pemanasan menghilangkan latensi pemanggilan pertama untuk indeks skalar dan vektor frekuensi tinggi.

• Penggusuran latar belakang mempertahankan tekanan cache yang stabil tanpa memblokir kueri.

• Menonaktifkan TTL cache menghindari pemuatan ulang yang tidak perlu untuk data panas.

Skenario 2: offline, analisis batch

Kapan digunakan

• Toleransi latensi kueri tinggi

• Beban kerja melibatkan kumpulan data yang sangat besar atau banyak segmen

• Kapasitas dan throughput diprioritaskan di atas daya tanggap

Konfigurasi yang disarankan

# milvus.yaml
queryNode:
  segcore:
    tieredStorage:
      enabled: true
      warmup:
        # disable scalar field/index warm-up to speed up loading
        scalarField: disable
        scalarIndex: disable
        # disable vector field/index warm-up to speed up loading
        vectorField: disable
        vectorIndex: disable
      # enable cache eviction, and also turn on background asynchronous eviction
      # to reduce the triggering of synchronous eviction.
      evictionEnabled: true
      backgroundEvictionEnabled: true
      memoryLowWatermarkRatio: 0.7
      memoryHighWatermarkRatio: 0.85
      diskLowWatermarkRatio: 0.7
      diskHighWatermarkRatio: 0.85
      # use 1 day expiration to clean unused cache
      cacheTtl: 86400

Dasar pemikiran

• Menonaktifkan pemanasan akan mempercepat pengaktifan saat menginisialisasi banyak segmen.

• Tanda air yang lebih tinggi memungkinkan penggunaan cache yang lebih padat, sehingga meningkatkan kapasitas beban total.

• Cache TTL secara otomatis membersihkan data yang tidak terpakai untuk mengosongkan ruang lokal.

Skenario 3: penerapan hibrida (campuran online + offline)

Kapan digunakan

• Satu cluster melayani beban kerja online dan analitik

• Beberapa koleksi membutuhkan latensi rendah, sementara yang lain memprioritaskan kapasitas

Strategi yang disarankan

• Menerapkan konfigurasi waktu nyata ke koleksi yang sensitif terhadap latensi

• Menerapkan konfigurasi offline ke koleksi analitik atau arsip

• Sesuaikan rasio evictableMemoryCacheRatio, cacheTtl, dan watermark secara independen untuk setiap jenis beban kerja

Dasar pemikiran

Menggabungkan konfigurasi memungkinkan kontrol alokasi sumber daya yang lebih baik.

Koleksi kritis mempertahankan jaminan latensi rendah, sementara koleksi sekunder dapat menangani lebih banyak segmen dan volume data.

Tips penyetelan tambahan

Aspek	Rekomendasi	Penjelasan
Lingkup Pemanasan	Hanya memuat bidang atau indeks yang memiliki frekuensi kueri yang tinggi.	Pemuatan awal yang tidak perlu akan meningkatkan waktu muat dan penggunaan sumber daya.
Penyetelan penggusuran	Mulailah dengan tanda air default (75-80%) dan sesuaikan secara bertahap.	Celah kecil menyebabkan penggusuran yang sering terjadi; celah yang besar akan menunda pelepasan sumber daya.
Cache TTL	Nonaktifkan untuk set data panas yang stabil; aktifkan (misalnya, 1-3 hari) untuk data dinamis.	Mencegah penumpukan cache yang basi sekaligus menyeimbangkan overhead pembersihan.
Rasio overcommit	Hindari nilai > 0,7 kecuali jika ruang sumber daya besar.	Overcommit yang berlebihan dapat menyebabkan cache meronta-ronta dan latensi yang tidak stabil.
Pemantauan	Pantau rasio hit cache, pemanfaatan sumber daya, dan frekuensi penggusuran.	Beban dingin yang sering terjadi dapat mengindikasikan bahwa pemanasan atau tanda air perlu disesuaikan.