Gambaran umum arsitektur terdistribusi

Milvus bertujuan untuk mencapai pencarian kemiripan dan analisis yang efisien untuk vektor berskala besar. Instance Milvus mandiri dapat dengan mudah menangani pencarian vektor untuk vektor berskala miliaran. Namun, untuk 10 miliar, 100 miliar, atau bahkan set data yang lebih besar, diperlukan cluster Milvus. Cluster ini dapat digunakan sebagai instance mandiri untuk aplikasi tingkat atas dan dapat memenuhi kebutuhan bisnis dengan latensi rendah dan konkurensi tinggi untuk data berskala besar. Cluster Milvus dapat mengirim ulang permintaan, memisahkan pembacaan dan penulisan, skala secara horizontal, dan berkembang secara dinamis, sehingga menyediakan instance Milvus yang dapat berkembang tanpa batas. Mishards adalah solusi terdistribusi untuk Milvus.

Artikel ini akan memperkenalkan secara singkat komponen-komponen arsitektur Mishards. Informasi yang lebih rinci akan diperkenalkan di artikel-artikel selanjutnya.

1-milvus-cluster-mishards.png

Gambaran umum arsitektur terdistribusi

2-gambaran-arsitektur-terdistribusi.png

Penelusuran layanan

3-penelusuran-layanan-milvus.png

Komponen layanan utama

• Kerangka kerja penemuan layanan, seperti ZooKeeper, etcd, dan Consul.
• Penyeimbang beban, seperti Nginx, HAProxy, Ingress Controller.
• Simpul Mishards: tanpa kewarganegaraan, dapat diskalakan.
• Node Milvus yang hanya dapat ditulis: simpul tunggal dan tidak dapat diskalakan. Anda perlu menggunakan solusi ketersediaan tinggi untuk simpul ini untuk menghindari titik kegagalan tunggal.
• Simpul Milvus hanya-baca: Simpul yang dapat diatur dan dapat diskalakan.
• Layanan penyimpanan bersama: Semua node Milvus menggunakan layanan penyimpanan bersama untuk berbagi data, seperti NAS atau NFS.
• Layanan metadata: Semua node Milvus menggunakan layanan ini untuk berbagi metadata. Saat ini, hanya MySQL yang didukung. Layanan ini membutuhkan solusi ketersediaan tinggi MySQL.

Komponen yang dapat diskalakan

• Kesalahan
• Node Milvus hanya-baca

Pengenalan komponen

Node Mishards

Mishards bertanggung jawab untuk memecah permintaan hulu dan merutekan sub-permintaan ke sub-layanan. Hasilnya dirangkum untuk dikembalikan ke hulu.

4-mishards-nodes.jpg

Seperti yang ditunjukkan pada bagan di atas, setelah menerima permintaan pencarian TopK, Mishards pertama-tama memecah permintaan menjadi sub-permintaan dan mengirim sub-permintaan ke layanan hilir. Ketika semua sub-respon dikumpulkan, sub-respon digabungkan dan dikembalikan ke hulu.

Karena Mishards adalah layanan tanpa nama, layanan ini tidak menyimpan data atau berpartisipasi dalam komputasi yang rumit. Dengan demikian, node tidak memiliki persyaratan konfigurasi yang tinggi dan daya komputasi terutama digunakan dalam penggabungan sub-hasil. Jadi, dimungkinkan untuk meningkatkan jumlah node Mishards untuk konkurensi yang tinggi.

Node Milvus

Milvus node bertanggung jawab atas operasi inti terkait CRUD, sehingga memiliki persyaratan konfigurasi yang relatif tinggi. Pertama, ukuran memori harus cukup besar untuk menghindari terlalu banyak operasi IO disk. Kedua, konfigurasi CPU juga dapat memengaruhi kinerja. Seiring dengan bertambahnya ukuran cluster, semakin banyak node Milvus yang dibutuhkan untuk meningkatkan throughput sistem.

Node yang hanya dapat dibaca dan node yang dapat ditulis

• Operasi inti dari Milvus adalah penyisipan vektor dan pencarian. Pencarian memiliki persyaratan yang sangat tinggi pada konfigurasi CPU dan GPU, sementara penyisipan atau operasi lainnya memiliki persyaratan yang relatif rendah. Memisahkan node yang menjalankan pencarian dari node yang menjalankan operasi lainnya akan menghasilkan penyebaran yang lebih ekonomis.
• Dalam hal kualitas layanan, ketika sebuah node melakukan operasi pencarian, perangkat keras terkait berjalan dengan beban penuh dan tidak dapat memastikan kualitas layanan operasi lainnya. Oleh karena itu, dua jenis node digunakan. Permintaan pencarian diproses oleh node read-only dan permintaan lainnya diproses oleh node writable.

Hanya satu simpul yang dapat ditulis yang diperbolehkan

• Saat ini, Milvus tidak mendukung berbagi data untuk beberapa instance yang dapat ditulis.

• Selama penerapan, satu titik kegagalan dari node yang dapat ditulis perlu dipertimbangkan. Solusi ketersediaan tinggi perlu disiapkan untuk node yang dapat ditulis.

Skalabilitas node hanya-baca

Jika ukuran data sangat besar, atau persyaratan latensi sangat tinggi, Anda dapat menskalakan node read-only secara horizontal sebagai stateful node. Asumsikan ada 4 host dan masing-masing memiliki konfigurasi sebagai berikut: Inti CPU: 16, GPU: 1, Memori: 64 GB. Bagan berikut menunjukkan cluster ketika menskalakan stateful node secara horizontal. Baik daya komputasi dan memori meningkat secara linear. Data dibagi menjadi 8 pecahan dengan setiap node memproses permintaan dari 2 pecahan.

5-skalabilitas-simpul-hanya-baca-milvus.png

Ketika jumlah permintaan besar untuk beberapa pecahan, node read-only tanpa nama dapat digunakan untuk pecahan ini untuk meningkatkan throughput. Ambil host di atas sebagai contoh. ketika host digabungkan menjadi cluster tanpa server, daya komputasi meningkat secara linear. Karena data yang akan diproses tidak bertambah, daya pemrosesan untuk pecahan data yang sama juga meningkat secara linear.

6-skalabilitas-simpul-hanya-baca-milvus-2.png

Layanan metadata

Kata kunci: MySQL

Untuk informasi lebih lanjut tentang metadata Milvus, lihat Cara melihat metadata. Dalam sistem terdistribusi, node yang dapat ditulis Milvus adalah satu-satunya penghasil metadata. Node Mishards, node yang dapat ditulis Milvus, dan node yang hanya dapat dibaca Milvus adalah konsumen metadata. Saat ini, Milvus hanya mendukung MySQL dan SQLite sebagai backend penyimpanan metadata. Dalam sistem terdistribusi, layanan ini hanya dapat digunakan sebagai MySQL yang sangat tersedia.

Penemuan layanan

Kata kunci: Apache Zookeeper, etcd, Konsul, Kubernetes

7-penemuan-layanan.png

Penemuan layanan menyediakan informasi tentang semua node Milvus. Node Milvus mendaftarkan informasi mereka saat online dan keluar saat offline. Node Milvus juga dapat mendeteksi node yang tidak normal dengan memeriksa status kesehatan layanan secara berkala.

Penemuan layanan berisi banyak kerangka kerja, termasuk etcd, Consul, ZooKeeper, dll. Mishards mendefinisikan antarmuka penemuan layanan dan menyediakan kemungkinan untuk penskalaan dengan plugin. Saat ini, Mishards menyediakan dua jenis plugin, yang sesuai dengan cluster Kubernetes dan konfigurasi statis. Anda dapat menyesuaikan penemuan layanan Anda sendiri dengan mengikuti implementasi plugin ini. Antarmuka bersifat sementara dan perlu didesain ulang. Informasi lebih lanjut tentang menulis plugin Anda sendiri akan diuraikan dalam artikel mendatang.

Penyeimbangan beban dan pemecahan layanan

Kata kunci: Nginx, HAProxy, Kubernetes

7-penyeimbangan-beban-dan-pemecahan-layanan.png

Penemuan layanan dan penyeimbangan beban digunakan secara bersamaan. Penyeimbangan beban dapat dikonfigurasikan sebagai polling, hashing, atau hashing yang konsisten.

Penyeimbang beban bertanggung jawab untuk mengirim ulang permintaan pengguna ke simpul Mishards.

Setiap node Mishards memperoleh informasi dari semua node Milvus hilir melalui pusat penemuan layanan. Semua metadata terkait dapat diperoleh dengan layanan metadata. Mishards mengimplementasikan sharding dengan mengonsumsi sumber daya ini. Mishards mendefinisikan antarmuka yang terkait dengan strategi perutean dan menyediakan ekstensi melalui plugin. Saat ini, Mishards menyediakan strategi hashing yang konsisten berdasarkan tingkat segmen terendah. Seperti yang ditunjukkan pada bagan, ada 10 segmen, s1 hingga s10. Sesuai dengan strategi hashing konsisten berbasis segmen, Mishards merutekan permintaan yang berkaitan dengan s1, 24, s6, dan s9 ke node Milvus 1, s2, s3, s5 ke node Milvus 2, dan s7, s8, s10 ke node Milvus 3.

Berdasarkan kebutuhan bisnis Anda, Anda dapat menyesuaikan perutean dengan mengikuti plugin perutean hashing yang konsisten secara default.

Penelusuran

Kata kunci: OpenTracing, Jaeger, Zipkin

Mengingat kompleksitas sistem terdistribusi, permintaan dikirim ke beberapa pemanggilan layanan internal. Untuk membantu menemukan masalah, kita perlu menelusuri rantai pemanggilan layanan internal. Seiring dengan meningkatnya kompleksitas, manfaat dari sistem penelusuran yang tersedia sudah cukup jelas. Kami memilih standar CNCF OpenTracing. OpenTracing menyediakan API yang tidak bergantung pada platform dan vendor bagi para pengembang untuk mengimplementasikan sistem penelusuran dengan mudah.

8-tracing-demo-milvus.png

Bagan sebelumnya adalah contoh penelusuran selama pemanggilan pencarian. Pencarian memanggil get_routing, do_search, dan do_merge secara berurutan. do_search juga memanggil search_127.0.0.1.

Seluruh catatan penelusuran membentuk pohon berikut ini:

8-penelusuran-penelusuran-milvus.png

Bagan berikut ini menunjukkan contoh info permintaan/respon dan tag dari setiap simpul:

request-response-info-tags-node-milvus.png

OpenTracing telah diintegrasikan ke Milvus. Informasi lebih lanjut akan dibahas dalam artikel mendatang.

Pemantauan dan peringatan

Kata kunci: Prometheus, Grafana

10-pemantauan-peringatan-milvus.jpg

Ringkasan

Sebagai middleware layanan, Mishards mengintegrasikan penemuan layanan, permintaan perutean, penggabungan hasil, dan penelusuran. Perluasan berbasis plugin juga disediakan. Saat ini, solusi terdistribusi berdasarkan Mishards masih memiliki beberapa kekurangan:

• Mishards menggunakan proxy sebagai lapisan tengah dan memiliki biaya latensi.
• Node yang dapat ditulis Milvus adalah layanan satu titik.
• Bergantung pada layanan MySQL yang sangat tersedia. -Penyebarannya rumit jika ada beberapa shard dan satu shard memiliki banyak salinan.
• Tidak memiliki lapisan cache, seperti akses ke metadata.

Kami akan memperbaiki masalah-masalah yang diketahui ini di versi mendatang sehingga Mishards dapat diterapkan ke lingkungan produksi dengan lebih nyaman.