🚀 Coba Zilliz Cloud, Milvus yang sepenuhnya terkelola, secara gratis—rasakan performa 10x lebih cepat! Coba Sekarang>>

milvus-logo
LFAI
Beranda
  • Konsep

Replika Dalam Memori

Topik ini memperkenalkan mekanisme replika dalam memori (replikasi) dalam Milvus yang memungkinkan replikasi beberapa segmen dalam memori kerja untuk meningkatkan kinerja dan ketersediaan.

Untuk informasi tentang cara mengonfigurasi replika dalam memori, lihat Konfigurasi terkait Node Query.

Gambaran Umum

Replica_Availiability Replika_Ketersediaan

Dengan replika dalam memori, Milvus dapat memuat segmen yang sama pada beberapa node kueri. Jika satu simpul kueri gagal atau sibuk dengan permintaan pencarian saat ini ketika yang lain tiba, sistem dapat mengirim permintaan baru ke simpul kueri yang menganggur yang memiliki replikasi segmen yang sama.

Kinerja

Replika dalam memori memungkinkan Anda memanfaatkan sumber daya CPU dan memori ekstra. Hal ini sangat berguna jika Anda memiliki kumpulan data yang relatif kecil tetapi ingin meningkatkan throughput pembacaan dengan sumber daya perangkat keras tambahan. Keseluruhan QPS (kueri per detik) dan throughput dapat ditingkatkan secara signifikan.

Ketersediaan

Replika dalam memori membantu Milvus pulih lebih cepat jika simpul kueri mengalami kegagalan. Ketika sebuah node kueri gagal, segmen tidak harus dimuat ulang di node kueri lain. Sebaliknya, permintaan pencarian dapat dikirim ulang ke node kueri baru dengan segera tanpa harus memuat ulang data lagi. Dengan beberapa replika segmen yang dipertahankan secara bersamaan, sistem lebih tangguh dalam menghadapi kegagalan.

Konsep Utama

Replika dalam memori disusun sebagai grup replika. Setiap grup replika berisi replika pecahan. Setiap replika pecahan memiliki replika streaming dan replika historis yang sesuai dengan segmen yang tumbuh dan disegel dalam pecahan (yaitu saluran DML).

An illustration of how in-memory replica works Ilustrasi cara kerja replika dalam memori

Grup replika

Grup replika terdiri dari beberapa node kueri yang bertanggung jawab untuk menangani data historis dan replika.

Replika pecahan

Replika pecahan terdiri dari replika streaming dan replika historis, keduanya termasuk dalam pecahan yang sama. Jumlah replika pecahan dalam kelompok replika ditentukan oleh jumlah pecahan dalam koleksi tertentu.

Replika streaming

Replika streaming berisi semua segmen yang berkembang dari saluran DML yang sama. Secara teknis, replika streaming harus dilayani oleh hanya satu simpul kueri dalam satu replika.

Replika historis

Replika historis berisi semua segmen tersegel dari saluran DML yang sama. Segmen tersegel dari satu replika historis dapat didistribusikan pada beberapa node kueri dalam grup replika yang sama.

Pemimpin pecahan

Shard leader adalah simpul kueri yang melayani replika streaming dalam replika pecahan.

Detail Desain

Keseimbangan

Segmen baru yang perlu dimuat akan dialokasikan ke beberapa node kueri yang berbeda. Permintaan pencarian dapat diproses setelah setidaknya satu replika berhasil dimuat.

Cache

Proksi memelihara cache yang memetakan segmen ke node kueri dan memperbaruinya secara berkala. Ketika proksi menerima permintaan, Milvus mendapatkan semua segmen tersegel yang perlu dicari dari cache dan mencoba menetapkannya ke node kueri secara merata.

Untuk segmen yang terus bertambah, proksi juga memelihara cache saluran-ke-simpul-simpul dan mengirimkan permintaan ke simpul-simpul kueri yang sesuai.

Failover

Cache pada proxy tidak selalu diperbarui. Beberapa segmen atau saluran mungkin telah dipindahkan ke node kueri lain ketika permintaan masuk. Dalam kasus ini, proxy akan menerima respons kesalahan, memperbarui cache dan mencoba untuk menugaskannya ke node kueri lain.

Segmen akan diabaikan jika proxy masih tidak dapat menemukannya setelah memperbarui cache. Hal ini dapat terjadi jika segmen telah dipadatkan.

Jika cache tidak akurat, proxy mungkin melewatkan beberapa segmen. Node kueri dengan saluran DML (segmen yang berkembang) mengembalikan respons pencarian bersama dengan daftar segmen yang dapat diandalkan yang dapat dibandingkan oleh proxy dan memperbarui cache.

Peningkatan

Proxy tidak dapat mengalokasikan permintaan pencarian ke node kueri secara merata dan node kueri mungkin memiliki sumber daya yang berbeda untuk melayani permintaan pencarian. Untuk menghindari distribusi sumber daya yang berekor panjang, proksi akan menetapkan segmen aktif pada node kueri lain ke node kueri yang menganggur yang juga memiliki segmen ini.

Coba Milvus yang Dikelola secara Gratis

Zilliz Cloud bebas masalah, didukung oleh Milvus dan 10x lebih cepat.

Mulai
Umpan balik

Apakah halaman ini bermanfaat?