Gambaran Umum Arsitektur Milvus

Milvus adalah basis data vektor open-source, cloud-native yang dirancang untuk pencarian kemiripan berkinerja tinggi pada set data vektor yang sangat besar. Dibangun di atas pustaka pencarian vektor yang populer, termasuk Faiss, HNSW, DiskANN, dan SCANN, Milvus memberdayakan aplikasi AI dan skenario pencarian data yang tidak terstruktur. Sebelum melanjutkan, biasakan diri Anda dengan prinsip-prinsip dasar pengambilan embedding.

Diagram Arsitektur

Diagram berikut ini menggambarkan arsitektur tingkat tinggi Milvus, yang menampilkan desain modular, dapat diskalakan, dan cloud-native dengan lapisan penyimpanan dan komputasi yang terpilah-pilah.

Architecture_diagram Arsitektur_diagram

Prinsip Arsitektur

Milvus mengikuti prinsip disagregasi bidang data dan bidang kontrol, yang terdiri dari empat lapisan utama yang saling independen dalam hal skalabilitas dan pemulihan bencana. Arsitektur penyimpanan bersama dengan lapisan penyimpanan dan komputasi yang terpilah sepenuhnya ini memungkinkan penskalaan horizontal node komputasi sambil menerapkan Woodpecker sebagai lapisan WAL tanpa disk untuk meningkatkan elastisitas dan mengurangi biaya operasional.

Dengan memisahkan pemrosesan aliran menjadi Streaming Node dan pemrosesan batch menjadi Query Node dan Data Node, Milvus mencapai kinerja tinggi sekaligus memenuhi persyaratan pemrosesan waktu nyata secara bersamaan.

Arsitektur Lapisan Terperinci

Lapisan 1: Lapisan Akses

Terdiri dari sekelompok proksi tanpa kewarganegaraan, lapisan akses adalah lapisan depan sistem dan titik akhir bagi pengguna. Lapisan ini memvalidasi permintaan klien dan mengurangi hasil yang dikembalikan:

  • Proxy dengan sendirinya tidak memiliki kewarganegaraan. Ia menyediakan alamat layanan terpadu menggunakan komponen penyeimbang beban seperti Nginx, Kubernetes Ingress, NodePort, dan LVS.
  • Karena Milvus menggunakan arsitektur pemrosesan paralel masif (MPP), proksi mengumpulkan dan memproses hasil antara sebelum mengembalikan hasil akhir ke klien.

Lapisan 2: Koordinator

Koordinator berfungsi sebagai otak Milvus. Setiap saat, ada satu Koordinator yang aktif di seluruh cluster, yang bertanggung jawab untuk menjaga topologi cluster, menjadwalkan semua jenis tugas, dan menjanjikan konsistensi tingkat cluster.

Berikut ini adalah beberapa tugas yang ditangani oleh Koordinator:

  • Manajemen DDL/DCL/TSO: Menangani permintaan bahasa definisi data (DDL) dan bahasa kontrol data (DCL), seperti membuat atau menghapus koleksi, partisi, atau indeks, serta mengelola cap waktu Oracle (TSO) dan penerbitan penanda waktu.
  • Manajemen Layanan Streaming: Mengikat Write-Ahead Log (WAL) dengan Streaming Node dan menyediakan penemuan layanan untuk layanan streaming.
  • Manajemen Kueri: Mengelola topologi dan penyeimbangan beban untuk Query Node, serta menyediakan dan mengelola tampilan kueri yang disajikan untuk memandu perutean kueri.
  • Manajemen Data Historis: Mendistribusikan tugas-tugas offline seperti pemadatan dan pembuatan indeks ke Node Data, dan mengelola topologi segmen dan tampilan data.

Lapisan 3: Simpul Pekerja

Lengan dan kaki. Node pekerja adalah eksekutor bodoh yang mengikuti instruksi dari koordinator. Node pekerja tidak memiliki kewarganegaraan berkat pemisahan penyimpanan dan komputasi, dan dapat memfasilitasi peningkatan skala sistem dan pemulihan bencana saat digunakan di Kubernetes. Ada tiga jenis simpul pekerja:

Node streaming

Streaming Node berfungsi sebagai "otak mini" tingkat pecahan, memberikan jaminan konsistensi tingkat pecahan dan pemulihan kesalahan berdasarkan WAL Storage yang mendasarinya. Sementara itu, Streaming Node juga bertanggung jawab untuk mengembangkan kueri data dan menghasilkan rencana kueri. Selain itu, node ini juga menangani konversi data yang terus bertambah menjadi data yang tersegel (historis).

Node kueri

Query node memuat data historis dari penyimpanan objek, dan menyediakan kueri data historis.

Simpul data

Simpul data bertanggung jawab untuk pemrosesan data historis secara offline, seperti pemadatan dan pembuatan indeks.

Lapisan 4: Penyimpanan

Penyimpanan adalah tulang dari sistem, yang bertanggung jawab atas persistensi data. Ini terdiri dari penyimpanan meta, perantara log, dan penyimpanan objek.

Penyimpanan meta

Penyimpanan meta menyimpan snapshot dari metadata seperti skema koleksi, dan pos pemeriksaan konsumsi pesan. Menyimpan metadata menuntut ketersediaan yang sangat tinggi, konsistensi yang kuat, dan dukungan transaksi, sehingga Milvus memilih etcd untuk meta store. Milvus juga menggunakan etcd untuk registrasi layanan dan pemeriksaan kesehatan.

Penyimpanan objek

Penyimpanan objek menyimpan file snapshot dari log, file indeks untuk data skalar dan vektor, dan hasil kueri menengah. Milvus menggunakan MinIO sebagai penyimpanan objek dan dapat dengan mudah digunakan di AWS S3 dan Azure Blob, dua layanan penyimpanan yang paling populer dan hemat biaya di dunia. Namun, penyimpanan objek memiliki latensi akses yang tinggi dan biaya berdasarkan jumlah permintaan. Untuk meningkatkan kinerjanya dan menurunkan biaya, Milvus berencana untuk menerapkan pemisahan data dingin-panas pada cache pool berbasis memori atau SSD.

Penyimpanan WAL

Penyimpanan Write-Ahead Log (WAL) adalah fondasi ketahanan dan konsistensi data dalam sistem terdistribusi. Sebelum perubahan apa pun dilakukan, perubahan tersebut terlebih dahulu dicatat dalam log-memastikan bahwa, jika terjadi kegagalan, Anda dapat memulihkan tepat di tempat yang Anda tinggalkan.

Implementasi WAL yang umum termasuk Kafka, Pulsar, dan Woodpecker. Tidak seperti solusi berbasis disk tradisional, Woodpecker mengadopsi desain cloud-native, tanpa disk yang menulis langsung ke penyimpanan objek. Pendekatan ini dapat disesuaikan dengan kebutuhan Anda dengan mudah dan menyederhanakan operasi dengan menghilangkan biaya tambahan untuk mengelola disk lokal.

Dengan mencatat setiap operasi penulisan sebelumnya, lapisan WAL menjamin mekanisme pemulihan dan konsistensi di seluruh sistem yang andal dan dapat diandalkan - tidak peduli seberapa rumitnya lingkungan terdistribusi Anda.

Aliran Data dan Kategori API

API Milvus dikategorikan berdasarkan fungsinya dan mengikuti jalur tertentu melalui arsitektur:

Kategori APIOperasiContoh APIAliran Arsitektur
DDL/DCLSkema & Kontrol AksescreateCollection, dropCollection, hasCollection, createPartitionLapisan Akses → Koordinator
DMLManipulasi Datainsert, delete, upsertLapisan Akses → Node Pekerja Streaming
DQLKueri Datasearch, queryLapisan Akses → Node Pekerja Batch (Node Kueri)

Contoh Aliran Data: Operasi Pencarian

  1. Klien mengirimkan permintaan pencarian melalui SDK / API RESTful
  2. Load Balancer merutekan permintaan ke Proxy yang tersedia di Access Layer
  3. Proxy menggunakan cache perutean untuk menentukan node target; menghubungi Koordinator hanya jika cache tidak tersedia
  4. Proxy meneruskan permintaan ke Streaming Node yang sesuai, yang kemudian berkoordinasi dengan Query Node untuk pencarian data yang disegel sambil mengeksekusi pencarian data yang terus bertambah secara lokal
  5. Query Node memuat segmen yang disegel dari Object Storage sesuai kebutuhan dan melakukan pencarian tingkat segmen
  6. Hasil pencarian mengalami pengurangan multi-level: Query Node mengurangi hasil di beberapa segmen, Streaming Node mengurangi hasil dari Query Node, dan Proxy mengurangi hasil dari semua Streaming Node sebelum kembali ke klien

Contoh Aliran Data: Penyisipan Data

  1. Klien mengirimkan permintaan penyisipan dengan data vektor
  2. Access Layer memvalidasi dan meneruskan permintaan ke Streaming Node
  3. Streaming Node mencatat operasi ke Penyimpanan WAL untuk ketahanan
  4. Data diproses secara real-time dan tersedia untuk kueri
  5. Ketika segmen mencapai kapasitas, Streaming Node memicu konversi ke segmen yang disegel
  6. Data Node menangani pemadatan dan membangun indeks di atas segmen yang disegel, menyimpan hasilnya di Object Storage
  7. Query Node memuat indeks yang baru dibangun dan mengganti data yang sedang berkembang

Apa Selanjutnya