Home
Blog
Cara Meningkatkan dengan Aman dari Milvus 2.5.x ke Milvus 2.6.x

Cara Meningkatkan dengan Aman dari Milvus 2.5.x ke Milvus 2.6.x

Tutorials

December 25, 2025

Yiqing Lu

Milvus 2.6 telah tersedia untuk sementara waktu, dan ini terbukti menjadi langkah maju yang solid untuk proyek ini. Rilis ini menghadirkan arsitektur yang disempurnakan, kinerja real-time yang lebih kuat, konsumsi sumber daya yang lebih rendah, dan perilaku penskalaan yang lebih cerdas dalam lingkungan produksi. Banyak dari peningkatan ini dibentuk langsung oleh umpan balik pengguna, dan pengguna awal 2.6.x telah melaporkan pencarian yang lebih cepat dan kinerja sistem yang lebih dapat diprediksi di bawah beban kerja yang berat atau dinamis.

Untuk tim yang menjalankan Milvus 2.5.x dan sedang mengevaluasi perpindahan ke 2.6.x, panduan ini adalah titik awal Anda. Panduan ini menguraikan perbedaan arsitektur, menyoroti kemampuan utama yang diperkenalkan di Milvus 2.6, dan menyediakan jalur peningkatan langkah demi langkah yang praktis yang dirancang untuk meminimalkan gangguan operasional.

Jika beban kerja Anda melibatkan pipeline real-time, pencarian multimodal atau hibrida, atau operasi vektor berskala besar, blog ini akan membantu Anda menilai apakah 2.6 selaras dengan kebutuhan Anda - dan jika Anda memutuskan untuk melanjutkan, tingkatkan dengan percaya diri dengan tetap menjaga integritas data dan ketersediaan layanan.

Perubahan Arsitektur dari Milvus 2.5 ke Milvus 2.6

Sebelum masuk ke dalam alur kerja peningkatan itu sendiri, mari kita pahami terlebih dahulu bagaimana arsitektur Milvus berubah di Milvus 2.6.

Arsitektur Milvus 2.5

Milvus 2.5 Architecture Arsitektur Milvus 2.5

Dalam Milvus 2.5, alur kerja streaming dan batch saling terkait di beberapa node pekerja:

QueryNode menangani kueri historis dan kueri tambahan (streaming).
DataNode menangani pembilasan waktu konsumsi dan pemadatan latar belakang pada data historis.

Pencampuran logika batch dan real-time ini menyulitkan untuk menskalakan beban kerja batch secara independen. Hal ini juga berarti status streaming tersebar di beberapa komponen, menimbulkan penundaan sinkronisasi, mempersulit pemulihan kegagalan, dan meningkatkan kompleksitas operasional.

Arsitektur Milvus 2.6

Milvus 2.6 Architecture Arsitektur Milvus 2.6

Milvus 2.6 memperkenalkan StreamingNode khusus yang menangani semua tanggung jawab data waktu nyata: mengonsumsi antrean pesan, menulis segmen tambahan, melayani permintaan tambahan, dan mengelola pemulihan berbasis WAL. Dengan streaming yang terisolasi, komponen yang tersisa mengambil peran yang lebih bersih dan terfokus:

QueryNode sekarang hanya menangani kueri batch pada segmen historis.
DataNode sekarang hanya menangani tugas-tugas data historis seperti pemadatan dan pembuatan indeks.

StreamingNode menyerap semua tugas terkait streaming yang tadinya dibagi di antara DataNode, QueryNode, dan bahkan Proxy di Milvus 2.5, sehingga memberikan kejelasan dan mengurangi pembagian status lintas peran.

Milvus 2.5.x vs Milvus 2.6.x: Perbandingan Komponen per Komponen

	Milvus 2.5.x	Milvus 2.6.x	Apa yang Berubah
Layanan Koordinator	RootCoord / QueryCoord / DataCoord (atau MixCoord)	MixCoord	Manajemen metadata dan penjadwalan tugas dikonsolidasikan ke dalam satu MixCoord, menyederhanakan logika koordinasi dan mengurangi kompleksitas yang terdistribusi.
Lapisan Akses	Proxy	Proxy	Permintaan penulisan hanya diarahkan melalui Streaming Node untuk konsumsi data.
Node Pekerja	-	Streaming Node	Node pemrosesan streaming khusus yang bertanggung jawab atas semua logika inkremental (segmen yang terus bertambah), termasuk: - Konsumsi data inkremental - Kueri data inkremental - Menyimpan data inkremental ke penyimpanan objek - Penulisan berbasis streaming - Pemulihan kegagalan berdasarkan WAL
	Simpul Kueri	Simpul Kueri	Node pemrosesan batch yang menangani kueri atas data historis saja.
	Simpul Data	Simpul Data	Node pemrosesan-batch yang bertanggung jawab atas data historis saja, termasuk pemadatan dan pembuatan indeks.
	Simpul Indeks	-	Index Node digabungkan ke dalam Data Node, menyederhanakan definisi peran dan topologi penyebaran.

Singkatnya, Milvus 2.6 menarik garis yang jelas antara beban kerja streaming dan batch, menghilangkan keterikatan lintas komponen yang terlihat pada 2.5 dan menciptakan arsitektur yang lebih terukur dan dapat dipelihara.

Sorotan Fitur Milvus 2.6

Sebelum masuk ke alur kerja peningkatan, berikut ini adalah sekilas tentang apa yang dibawa Milvus 2.6. Rilis ini berfokus pada penurunan biaya infrastruktur, peningkatan kinerja pencarian, dan membuat beban kerja AI yang besar dan dinamis menjadi lebih mudah untuk diskalakan.

Peningkatan Biaya & Efisiensi

KuantisasiRaBitQ untuk Indeks Utama - Metode kuantisasi 1-bit baru yang memampatkan indeks vektor menjadi 1/32 dari ukuran aslinya. Dikombinasikan dengan SQ8 reranking, metode ini mengurangi penggunaan memori hingga ~28%, meningkatkan QPS hingga 4×, dan mempertahankan recall ~95%, sehingga secara signifikan menurunkan biaya perangkat keras.
Pencarian Teks Lengkapyang Dioptimalkan BM25 - Penilaian BM25 asli yang didukung oleh vektor bobot istilah yang jarang. Pencarian kata kunci berjalan 3-4× lebih cepat (hingga 7× pada beberapa dataset) dibandingkan dengan Elasticsearch, dengan tetap menjaga ukuran indeks sekitar sepertiga dari data teks asli.
Pengindeksan Jalur JSON dengan Penghancuran JSON - Pemfilteran terstruktur pada JSON bersarang sekarang jauh lebih cepat dan jauh lebih dapat diprediksi. Jalur JSON yang telah diindeks sebelumnya memotong latensi filter dari 140 ms → 1,5 ms (P99: 480 ms → 10 ms), sehingga pencarian vektor hibrida + pemfilteran metadata menjadi jauh lebih responsif.
Dukungan Tipe Data yang Diperluas - Menambahkan tipe vektor Int8, bidang Geometri (POINT / LINESTRING / POLYGON), dan Array-of-Structs. Ekstensi ini mendukung beban kerja geospasial, pemodelan metadata yang lebih kaya, dan skema yang lebih bersih.
Upsert untuk Pembaruan Parsial - Anda sekarang dapat menyisipkan atau memperbarui entitas menggunakan satu panggilan primary-key. Pembaruan parsial hanya memodifikasi bidang yang disediakan, mengurangi amplifikasi penulisan dan menyederhanakan pipeline yang sering menyegarkan metadata atau penyematan.

Peningkatan Pencarian dan Pengambilan

Peningkatan Pemrosesan Teks & Dukungan Multibahasa: Tokeniser Lindera dan ICU baru meningkatkan penanganan teks bahasa Jepang, Korea, dan multi-bahasa. Jieba sekarang mendukung kamus khusus. run_analyzer membantu men-debug perilaku tokenisasi, dan penganalisis multi-bahasa memastikan pencarian lintas-bahasa yang konsisten.
Pencocokan Teks Presisi Tinggi: Pencocokan Frasa memberlakukan kueri frasa yang dipesan dengan slop yang dapat dikonfigurasi. Indeks NGRAM yang baru mempercepat kueri substring dan LIKE pada bidang VARCHAR dan jalur JSON, sehingga memungkinkan pencocokan teks parsial dan fuzzy yang cepat.
Pemeringkatan Sadar Waktu dan Sadar Metadata: Pemeringkat Peluruhan (eksponensial, linier, Gaussian) menyesuaikan skor menggunakan stempel waktu; Pemeringkat Peningkatan menerapkan aturan berbasis metadata untuk mempromosikan atau menurunkan hasil. Keduanya membantu menyempurnakan perilaku pencarian tanpa mengubah data dasar Anda.
Integrasi Model yang Disederhanakan & Vektorisasi Otomatis: Integrasi bawaan dengan OpenAI, Hugging Face, dan penyedia penyematan lainnya memungkinkan Milvus secara otomatis memvektorisasi teks selama operasi penyisipan dan kueri. Tidak ada lagi pipeline penyematan manual untuk kasus penggunaan umum.
Pembaruan Skema Online untuk Bidang Skalar: Tambahkan bidang skalar baru ke koleksi yang sudah ada tanpa waktu henti atau pemuatan ulang, menyederhanakan evolusi skema seiring dengan bertambahnya kebutuhan metadata.
Deteksi Hampir Duplikat dengan MinHash: MinHash + LSH memungkinkan deteksi nyaris duplikat yang efisien di seluruh kumpulan data yang besar tanpa perbandingan tepat yang mahal.

Peningkatan Arsitektur dan Skalabilitas

Penyimpanan Berjenjang untuk Manajemen Data Panas-Dingin: Memisahkan data panas dan dingin di seluruh SSD dan penyimpanan objek; mendukung pemuatan malas dan parsial; menghilangkan kebutuhan untuk memuat koleksi secara lokal; mengurangi penggunaan sumber daya hingga 50% dan mempercepat waktu muat untuk set data besar.
Layanan Streaming Waktu Nyata: Menambahkan Node Streaming khusus yang terintegrasi dengan Kafka/Pulsar untuk konsumsi terus menerus; memungkinkan pengindeksan langsung dan ketersediaan kueri; meningkatkan throughput penulisan dan mempercepat pemulihan kegagalan untuk beban kerja yang real-time dan cepat berubah.
Skalabilitas & Stabilitas yang Ditingkatkan: Milvus kini mendukung 100.000+ koleksi untuk lingkungan multi-penyewa yang besar. Peningkatan infrastruktur - Woodpecker (zero-disk WAL), Storage v2 (mengurangi IOPS/memori), dan Penggabungan Koordinator - meningkatkan stabilitas cluster dan memungkinkan penskalaan yang dapat diprediksi di bawah beban kerja yang berat.

Untuk daftar lengkap fitur-fitur Milvus 2.6, lihat catatan rilis Milvus.

Cara Meningkatkan dari Milvus 2.5.x ke Milvus 2.6.x

Agar sistem tetap tersedia selama proses upgrade, cluster Milvus 2.5 harus diupgrade ke Milvus 2.6 dengan urutan sebagai berikut.

1. Mulai Streaming Node terlebih dahulu

Jalankan Streaming Node terlebih dahulu. Delegator baru (komponen dalam Query Node yang bertanggung jawab untuk penanganan data streaming) harus dipindahkan ke Streaming Node Milvus 2.6.

2. Tingkatkan MixCoord

Tingkatkan komponen koordinator ke MixCoord. Selama langkah ini, MixCoord perlu mendeteksi versi Worker Node untuk menangani kompatibilitas lintas versi dalam sistem terdistribusi.

3. Tingkatkan Node Kueri

Peningkatan Query Node biasanya membutuhkan waktu lebih lama. Selama fase ini, Milvus 2.5 Data Node dan Index Node dapat terus menangani operasi seperti Flush dan pembangunan Index, membantu mengurangi tekanan dari sisi kueri saat Query Node sedang diupgrade.

4. Meningkatkan Node Data

Setelah Milvus 2.5 DataNodes offline, operasi Flush menjadi tidak tersedia, dan data di Segmen Tumbuh dapat terus terakumulasi hingga semua node sepenuhnya diupgrade ke Milvus 2.6.

5. Meningkatkan Proxy

Setelah mengupgrade Proxy ke Milvus 2.6, operasi tulis pada Proxy tersebut akan tetap tidak tersedia sampai semua komponen cluster diupgrade ke 2.6.

6. Menghapus Simpul Indeks

Setelah semua komponen lain diupgrade, Node Indeks mandiri dapat dihapus dengan aman.

Catatan:

Dari selesainya peningkatan DataNode hingga selesainya peningkatan Proxy, operasi Flush tidak tersedia.
Dari saat Proxy pertama diupgrade hingga semua node Proxy diupgrade, beberapa operasi tulis tidak tersedia.
Ketika mengupgrade langsung dari Milvus 2.5.x ke 2.6.6, operasi DDL (Data Definition Language) tidak tersedia selama proses upgrade karena adanya perubahan pada kerangka kerja DDL.

Cara Meningkatkan ke Milvus 2.6 dengan Milvus Operator

Milvus Operator adalah operator Kubernetes sumber terbuka yang menyediakan cara yang dapat diskalakan dan sangat tersedia untuk menerapkan, mengelola, dan memutakhirkan seluruh tumpukan layanan Milvus pada cluster Kubernetes target. Tumpukan layanan Milvus yang dikelola oleh operator meliputi:

Komponen inti Milvus
Ketergantungan yang diperlukan seperti etcd, Pulsar, dan MinIO

Operator Milvus mengikuti pola Operator Kubernetes standar. Ini memperkenalkan Milvus Custom Resource (CR) yang menggambarkan keadaan yang diinginkan dari cluster Milvus, seperti versi, topologi, dan konfigurasinya.

Pengontrol terus memantau cluster dan merekonsiliasi kondisi aktual dengan kondisi yang diinginkan yang didefinisikan dalam CR. Ketika perubahan dilakukan-seperti meningkatkan versi Milvus-operator secara otomatis menerapkannya dengan cara yang terkendali dan berulang, memungkinkan peningkatan otomatis dan manajemen siklus hidup yang berkelanjutan.

Contoh Sumber Daya Khusus (CR) Milvus

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-milvus-mansion    
  namespace: dev       
spec:
  mode: cluster                  # cluster or standalone
  # Milvus Components
  components:
    image: milvusdb/milvus:v2.6.5
    imageUpdateMode: rollingUpgrade 
    proxy:                   
      replicas: 1          
    mixCoord:              
      replicas: 1           
    dataNode:               
      replicas: 1          
    queryNode:              
      replicas: 2           
      resources:
        requests:
          cpu: "2"
          memory: "8Gi"  
  # Dependencies, including etcd, storage and message stream
  dependencies:
    etcd:                   
      inCluster:
        values:
          replicaCount: 3    
    storage:                 
      type: MinIO
      inCluster:
        values:
          mode: distributed     
    msgStreamType: pulsar    
    pulsar:
      inCluster:
        values:
          bookkeeper:
            replicas: 3   
  # Milvus configs
  config:
    dataCoord:
      enableActiveStandby: true

Peningkatan Bergulir dari Milvus 2.5 ke 2.6 dengan Operator Milvus

Milvus Operator menyediakan dukungan bawaan untuk peningkatan bergulir dari Milvus 2.5 ke 2.6 dalam mode klaster, mengadaptasi perilakunya untuk memperhitungkan perubahan arsitektur yang diperkenalkan di 2.6.

1. Deteksi Skenario Peningkatan

Selama peningkatan, Operator Milvus menentukan versi Milvus target dari spesifikasi cluster. Hal ini dilakukan dengan cara:

Memeriksa tag gambar yang ditentukan di spec.components.image, atau
Membaca versi eksplisit yang ditentukan dalam spec.components.version

Operator kemudian membandingkan versi yang diinginkan ini dengan versi yang saat ini berjalan, yang tercatat di status.currentImage atau status.currentVersion. Jika versi saat ini adalah 2.5 dan versi yang diinginkan adalah 2.6, operator mengidentifikasi peningkatan tersebut sebagai skenario peningkatan 2.5 → 2.6.

2. Perintah Eksekusi Peningkatan Bergulir

Ketika peningkatan 2.5 → 2.6 terdeteksi dan mode peningkatan diatur ke peningkatan bergulir (spec.components.imageUpdateMode: rollingUpgrade, yang merupakan default), Operator Milvus secara otomatis melakukan peningkatan dalam urutan yang telah ditentukan sebelumnya yang selaras dengan arsitektur Milvus 2.6:

Mulai Streaming Node → Upgrade MixCoord → Upgrade Node Query → Upgrade Node Data → Upgrade Proxy → Hapus Index Node

3. Konsolidasi Koordinator Otomatis

Milvus 2.6 menggantikan beberapa komponen koordinator dengan satu MixCoord. Operator Milvus menangani transisi arsitektur ini secara otomatis.

Ketika spec.components.mixCoord dikonfigurasi, operator akan memunculkan MixCoord dan menunggu hingga siap. Setelah MixCoord beroperasi penuh, operator akan mematikan komponen koordinator lama-RootCoord, QueryCoord, dan DataCoord-menyelesaikan migrasi tanpa memerlukan intervensi manual.

Langkah-langkah Peningkatan dari Milvus 2.5 ke 2.6

1. Upgrade Milvus Operator ke versi terbaru (Dalam panduan ini, kami menggunakan versi 1.3.3, yang merupakan rilis terbaru pada saat panduan ini ditulis).

# Option 1: Using Helm
helm upgrade --install milvus-operator \
  -n milvus-operator --create-namespace \
  https://github.com/zilliztech/milvus-operator/releases/download/v1.3.3/milvus-operator-1.3.3.tgz
 # Option 2: Using kubectl & raw manifests
 kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/v1.3.3/deploy/manifests/deployment.yaml

2. Gabungkan komponen koordinator

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "mixCoord": {
        "replicas": 1
      }
    }
  }
}'

3. Pastikan cluster menjalankan Milvus 2.5.16 atau yang lebih baru

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "image": "milvusdb/milvus:v2.5.22"
    }
  }
}'
# wait till updated
kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h

4. Tingkatkan Milvus ke versi 2.6

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "image": "milvusdb/milvus:v2.6.5"
    }
  }
}'
# wait till updated
kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h

Cara Memutakhirkan ke Milvus 2.6 dengan Helm

Saat menerapkan Milvus menggunakan Helm, semua sumber daya Kubernetes Deployment diperbarui secara paralel, tanpa urutan eksekusi yang terjamin. Akibatnya, Helm tidak menyediakan kontrol yang ketat terhadap urutan pemutakhiran yang bergulir di seluruh komponen. Untuk lingkungan produksi, menggunakan Milvus Operator sangat disarankan.

Milvus masih dapat ditingkatkan dari 2.5 ke 2.6 menggunakan Helm dengan mengikuti langkah-langkah di bawah ini.

Persyaratan Sistem

Versi Helm: ≥ 3.14.0
Versi Kubernetes: ≥ 1.20.0

1. Tingkatkan bagan Milvus Helm ke versi terbaru. Dalam panduan ini, kami menggunakan bagan versi 5.0.7, yang merupakan versi terbaru pada saat penulisan.

helm repo add zilliztech https://zilliztech.github.io/milvus-helm
helm repo update

2. Jika cluster digunakan dengan beberapa komponen koordinator, pertama-tama tingkatkan Milvus ke versi 2.5.16 atau yang lebih baru dan aktifkan MixCoord.

mixCoordinator
。
helm upgrade -i my-release zilliztech/milvus \
  --namespace=helm-demo \
  --set image.all.tag="v2.5.22" \
  --set mixCoordinator.enabled=true \
  --set rootCoordinator.enabled=false \
  --set indexCoordinator.enabled=false \
  --set queryCoordinator.enabled=false \
  --set dataCoordinator.enabled=false \
  --set streaming.enabled=false \
  --set indexNode.enabled=true \
  --reset-then-reuse-values \
  --version=5.0.7 \
  --wait --timeout 1h

3. Tingkatkan Milvus ke versi 2.6

helm upgrade my-release zilliztech/milvus \
  --namespace=helm-demo \
  --set image.all.tag="v2.6.5" \
  --set streaming.enabled=true \
  --set indexNode.enabled=false \
  --reset-then-reuse-values \
  --version=5.0.7 \
  --wait --timeout 1h

Pertanyaan Umum tentang Peningkatan dan Pengoperasian Milvus 2.6

T1: Milvus Helm vs. Milvus Operator - mana yang harus saya gunakan?

Untuk lingkungan produksi, Milvus Operator sangat disarankan.

Lihat panduan resmi untuk detailnya: https://github.com/zilliztech/milvus-operator?tab=readme-ov-file#milvus-operator-vs-helm

T2: Bagaimana saya harus memilih Message Queue (MQ)?

MQ yang direkomendasikan tergantung pada mode penerapan dan persyaratan operasional:

1. Mode mandiri: Untuk penerapan yang sensitif terhadap biaya, RocksMQ direkomendasikan.

2. Mode cluster

Pulsar mendukung multi-tenancy, memungkinkan cluster besar untuk berbagi infrastruktur, dan menawarkan skalabilitas horizontal yang kuat.
Kafka memiliki ekosistem yang lebih matang, dengan penawaran SaaS terkelola yang tersedia di sebagian besar platform cloud utama.

3. Woodpecker (diperkenalkan di Milvus 2.6): Woodpecker menghilangkan kebutuhan akan antrean pesan eksternal, mengurangi biaya dan kompleksitas operasional.

Saat ini, hanya mode Woodpecker tertanam yang didukung, yang ringan dan mudah dioperasikan.
Untuk penerapan mandiri Milvus 2.6, Woodpecker direkomendasikan.
Untuk penerapan cluster produksi, disarankan untuk menggunakan mode cluster Woodpecker yang akan datang setelah tersedia.

T3: Apakah Antrian Pesan dapat dialihkan selama peningkatan?

Tidak. Mengalihkan Antrian Pesan selama peningkatan saat ini tidak didukung. Rilis mendatang akan memperkenalkan API manajemen untuk mendukung peralihan antara Pulsar, Kafka, Woodpecker, dan RocksMQ.

T4: Apakah konfigurasi pembatasan laju perlu diperbarui untuk Milvus 2.6?

Tidak. Konfigurasi pembatas laju yang ada saat ini tetap efektif dan juga berlaku untuk Streaming Node yang baru. Tidak ada perubahan yang diperlukan.

T5: Setelah penggabungan koordinator, apakah peran atau konfigurasi pemantauan berubah?

Peran pemantauan tetap tidak berubah (RootCoord, QueryCoord, DataCoord).
Opsi konfigurasi yang ada akan tetap berfungsi seperti sebelumnya.
Opsi konfigurasi baru, mixCoord.enableActiveStandby, diperkenalkan dan akan kembali ke rootcoord.enableActiveStandby jika tidak diatur secara eksplisit.

T6: Apa saja pengaturan sumber daya yang direkomendasikan untuk StreamingNode?

Untuk konsumsi waktu nyata yang ringan atau beban kerja tulis-dan-query sesekali, konfigurasi yang lebih kecil, seperti 2 inti CPU dan memori 8 GB, sudah cukup.
Untuk konsumsi waktu nyata yang berat atau beban kerja tulis-dan-query yang terus menerus, disarankan untuk mengalokasikan sumber daya yang sebanding dengan sumber daya Query Node.

T7: Bagaimana cara meningkatkan penerapan mandiri menggunakan Docker Compose?

Untuk deployment mandiri berbasis Docker Compose, cukup perbarui tag citra Milvus di docker-compose.yaml.

Lihat panduan resmi untuk detailnya: https://milvus.io/docs/upgrade_milvus_standalone-docker.md

Kesimpulan

Milvus 2.6 menandai peningkatan besar dalam arsitektur dan operasi. Dengan memisahkan pemrosesan streaming dan batch dengan memperkenalkan StreamingNode, mengkonsolidasikan koordinator ke dalam MixCoord, dan menyederhanakan peran pekerja, Milvus 2.6 menyediakan fondasi yang lebih stabil, dapat diskalakan, dan lebih mudah dioperasikan untuk beban kerja vektor berskala besar.

Perubahan arsitektur ini membuat peningkatan - terutama dari Milvus 2.5 - menjadi lebih sensitif terhadap pesanan. Peningkatan yang berhasil bergantung pada ketergantungan komponen dan batasan ketersediaan sementara. Untuk lingkungan produksi, Milvus Operator adalah pendekatan yang direkomendasikan, karena mengotomatiskan urutan peningkatan dan mengurangi risiko operasional, sementara peningkatan berbasis Helm lebih cocok untuk kasus penggunaan nonproduksi.

Dengan kemampuan pencarian yang ditingkatkan, tipe data yang lebih kaya, penyimpanan berjenjang, dan opsi antrean pesan yang lebih baik, Milvus 2.6 memiliki posisi yang tepat untuk mendukung aplikasi AI modern yang membutuhkan konsumsi waktu nyata, kinerja kueri yang tinggi, dan operasi yang efisien dalam skala besar.

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.