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

milvus-logo
LFAI
  • Home
  • Blog
  • Evolusi Basis Data Vektor yang dapat diskalakan di Cloud Milvus

Evolusi Basis Data Vektor yang dapat diskalakan di Cloud Milvus

  • Engineering
December 21, 2021
Jun Gu

Dalam artikel ini, kami akan berbagi proses berpikir tentang bagaimana kami merancang arsitektur cluster database Milvus yang baru.

Tujuan dari database vektor Milvus

Ketika ide database vektor Milvus pertama kali muncul di benak kami, kami ingin membangun infrastruktur data yang dapat membantu orang mempercepat adopsi AI di organisasi mereka.

Kami telah menetapkan dua tujuan penting untuk proyek Milvus untuk memenuhi misi ini.

Kemudahan penggunaan

AI/ML adalah area yang sedang berkembang di mana teknologi baru terus bermunculan. Sebagian besar pengembang tidak sepenuhnya akrab dengan teknologi dan alat AI yang berkembang pesat. Para pengembang telah menghabiskan sebagian besar energi mereka untuk menemukan, melatih, dan menyetel model. Sulit bagi mereka untuk menghabiskan upaya tambahan untuk menangani sejumlah besar vektor penyematan yang dihasilkan oleh model. Belum lagi manipulasi data dalam jumlah besar selalu merupakan tugas yang sangat menantang.

Oleh karena itu, kami memberikan prioritas yang sangat tinggi pada "kemudahan penggunaan" karena hal ini dapat mengurangi biaya pengembangan secara signifikan.

Biaya operasional yang rendah

Salah satu rintangan utama AI dalam produksi adalah menjustifikasi pengembalian investasi. Kami akan memiliki lebih banyak kesempatan untuk memasukkan aplikasi AI kami ke dalam produksi dengan biaya operasional yang lebih rendah. Dan hal ini akan kondusif untuk meningkatkan margin manfaat potensial.

Prinsip-prinsip desain Milvus 2.0

Kami telah memulai untuk mencapai tujuan-tujuan ini di Milvus 1.0. Tapi itu masih jauh dari cukup, terutama dalam hal skalabilitas dan ketersediaan. Kemudian kami memulai pengembangan Milvus 2.0 untuk meningkatkan poin-poin ini. Prinsip-prinsip yang telah kami tetapkan untuk versi baru ini meliputi:

  • Bertujuan untuk skalabilitas dan ketersediaan yang tinggi
  • Membangun infrastruktur dan praktik cloud yang sudah matang
  • Kompromi kinerja minimum di cloud

Dengan kata lain, kami ingin membuat klaster database Milvus menjadi cloud-native.

Evolusi cluster database

Basis data vektor adalah jenis basis data baru, karena menangani jenis data baru (vektor). Namun, masih memiliki tantangan yang sama dengan database lain, dengan beberapa persyaratannya sendiri. Dalam sisa artikel ini, saya akan fokus pada apa yang telah kita pelajari dari implementasi cluster database yang sudah ada dan proses berpikir bagaimana kita merancang arsitektur grup Milvus yang baru.

Jika Anda tertarik dengan detail implementasi komponen-komponen grup Milvus, silakan ikuti terus dokumentasi Milvus. Kami akan terus mempublikasikan artikel teknis di repositori Milvus GitHub, situs web Milvus, dan Blog Milvus.

Cluster basis data yang ideal

"Bidik yang kecil, rindukan yang kecil."

Pertama-tama, mari kita buat daftar kemampuan penting yang harus dimiliki oleh sebuah cluster database yang ideal.

  1. Konkurensi dan tidak ada satu titik kegagalan: pengguna yang terhubung ke anggota grup yang berbeda dapat secara bersamaan memiliki akses baca/tulis ke bagian data yang sama.
  2. Konsistensi: anggota grup yang berbeda harus melihat data yang sama.
  3. Skalabilitas: kita dapat menambah atau menghapus anggota grup saat bepergian.

Sejujurnya, semua kemampuan ini sulit untuk didapatkan secara bersamaan. Dalam implementasi modern dari cluster database, orang harus mengorbankan beberapa kemampuan ini. Orang tidak mengharapkan cluster database yang sempurna selama itu bisa masuk ke dalam skenario pengguna. Namun, kluster shared-everything pernah sangat dekat dengan kluster database yang ideal. Jika kita ingin mempelajari sesuatu, kita harus mulai dari sini.

Pertimbangan-pertimbangan utama dari sebuah cluster database

Klaster shared-everything memiliki sejarah yang lebih panjang dibandingkan dengan implementasi modern lainnya. Grup berbagi data Db2 dan Oracle RAC merupakan contoh klaster shared-everything. Banyak orang mengira shared-everything berarti berbagi disk. Ini jauh lebih dari itu.

Sebuah shared-everything cluster hanya memiliki satu jenis anggota database di dalam grup. Pengguna dapat terhubung ke salah satu anggota simetris ini untuk mengakses data apa pun. Apa yang dimaksud dengan "segala sesuatu" yang perlu dibagikan untuk membuat ini bekerja?

Urutan peristiwa dalam grup

Pertama, urutan kejadian dalam grup sangat penting untuk menyelesaikan potensi konflik yang disebabkan oleh akses bersamaan dari anggota grup yang berbeda. Kami biasanya menggunakan nomor urut catatan log database untuk mewakili urutan kejadian. Pada saat yang sama, nomor urutan catatan log umumnya dihasilkan dari stempel waktu.

Dengan demikian, kebutuhan urutan kejadian grup sama dengan kebutuhan timer global. Jika kita dapat memiliki jam atom untuk grup, itu akan menjadi luar biasa. Namun, Milvus adalah proyek perangkat lunak sumber terbuka, yang berarti kita harus mengandalkan sumber daya yang tersedia secara umum. Sampai saat ini, jam atom masih merupakan pilihan premium untuk perusahaan besar.

Kami telah mengimplementasikan komponen sinkronisasi waktu dalam cluster database Milvus 2.0. Anda dapat menemukan tautannya di lampiran.

Penguncian global

Basis data memiliki mekanisme penguncian untuk menyelesaikan konflik akses bersamaan, baik penguncian optimis maupun pesimis. Demikian pula, kita memerlukan penguncian global untuk menyelesaikan konflik akses simultan di seluruh anggota grup yang berbeda.

Penguncian global berarti anggota grup yang berbeda harus berbicara satu sama lain untuk menegosiasikan permintaan penguncian. Beberapa faktor penting akan mempengaruhi efisiensi proses negosiasi kunci global ini:

  • Kecepatan koneksi antar sistem
  • Jumlah anggota grup yang perlu berpartisipasi dalam proses negosiasi
  • Frekuensi konflik kelompok

Ukuran kelompok yang umum adalah tidak lebih dari 100. Sebagai contoh, Db2 DSG adalah 32; Oracle RAC adalah 100. Anggota kelompok tersebut akan ditempatkan dalam satu ruang server yang terhubung dengan serat optik untuk meminimalkan latensi transfer. Itulah mengapa terkadang disebut cluster terpusat. Karena batasan ukuran grup, orang akan memilih server kelas atas (mainframe atau komputer mini, yang memiliki kapasitas lebih besar dalam hal CPU, memori, saluran I/O, dan lain-lain) untuk menjadi bagian dari klaster shared-everything.

Anggapan tentang perangkat keras ini telah berubah secara dramatis dalam lingkungan cloud modern. Saat ini, pusat data cloud terdiri dari ruang server yang sangat padat dan penuh dengan (ribuan) server X86 komoditas dengan koneksi TCP/IP. Jika kita mengandalkan server X86 ini untuk membangun klaster database, ukuran grup harus meningkat menjadi ratusan (bahkan ribuan) mesin. Dan dalam beberapa skenario bisnis, kita ingin ratusan mesin X86 ini tersebar di berbagai wilayah. Dengan demikian, mengimplementasikan penguncian global mungkin tidak layak lagi, karena kinerja penguncian global tidak akan cukup baik.

Dalam Milvus 2.0, kami tidak akan mengimplementasikan fasilitas penguncian global. Di satu sisi, tidak ada pembaruan untuk data vektor. (Orang sebaiknya melakukan delete-lalu-insert daripada update.) Jadi kita tidak perlu khawatir dengan konflik multi-penulis pada bagian data yang sama dalam grup Milvus dengan pengaturan sharding. Sementara itu, kita dapat menggunakan MVCC (kontrol konkurensi multi-versi, sebuah metode kontrol konkurensi penghindaran-kunci) untuk menyelesaikan konflik pembaca-penulis.

Di sisi lain, pemrosesan data vektor menghabiskan jejak memori yang jauh lebih tinggi daripada pemrosesan data terstruktur. Orang-orang mencari skalabilitas yang jauh lebih tinggi dalam database vektor.

Cache data dalam memori bersama

Secara singkat, kita bisa membagi mesin database menjadi dua bagian: mesin penyimpanan dan mesin komputasi. Mesin penyimpanan bertanggung jawab atas dua tugas penting:

  • Menulis data ke penyimpanan permanen untuk tujuan daya tahan.
  • Memuat data dari penyimpanan permanen ke cache data dalam memori (alias buffer pool); ini adalah satu-satunya tempat di mana mesin komputasi mengakses data.

Dalam skenario cluster database, bagaimana jika anggota A telah memperbarui data yang di-cache di anggota B? Bagaimana anggota B bisa mengetahui bahwa data dalam memorinya sudah kedaluwarsa? Klaster shared-everything klasik memiliki mekanisme buffer cross invalidation untuk mengatasi masalah ini. Mekanisme buffer cross invalidation akan bekerja mirip dengan penguncian global jika kita menjaga konsistensi yang kuat di seluruh anggota grup. Seperti yang telah dinyatakan sebelumnya, hal ini tidak praktis dalam lingkungan cloud modern. Jadi kami memutuskan untuk menurunkan tingkat konsistensi dalam grup yang dapat diskalakan di Milvus ke cara konsistensi yang akhirnya. Dengan cara ini, mekanisme invalidasi silang buffer di Milvus 2.0 dapat menjadi proses asinkron.

Penyimpanan bersama

Penyimpanan bersama mungkin merupakan hal pertama yang dipikirkan orang ketika membahas cluster database.

Opsi penyimpanan juga telah berubah secara signifikan dalam beberapa tahun terakhir dalam evolusi penyimpanan awan. Storage attached network (SAN) adalah (dan masih menjadi) fondasi penyimpanan dari kelompok penyimpanan bersama. Namun di lingkungan cloud, tidak ada SAN. Basis data harus menggunakan disk lokal yang terpasang pada mesin virtual cloud. Menggunakan disk lokal menimbulkan tantangan konsistensi data di seluruh anggota grup. Dan kami juga harus khawatir tentang ketersediaan yang tinggi dari anggota grup.

Kemudian Snowflake menjadi panutan yang bagus untuk database cloud dengan menggunakan penyimpanan bersama cloud (penyimpanan S3). Hal ini juga menginspirasi Milvus 2.0. Seperti yang telah dinyatakan sebelumnya, kami berniat untuk mengandalkan infrastruktur cloud yang sudah matang. Namun sebelum kami dapat memanfaatkan penyimpanan bersama cloud, kami harus memikirkan beberapa hal.

Pertama, penyimpanan S3 murah dan dapat diandalkan, tetapi tidak dirancang untuk akses R/W instan seperti skenario database. Kita perlu membuat komponen data (yang kita sebut sebagai node data di Milvus 2.0) untuk menjembatani memori/disk lokal dan penyimpanan S3. Ada beberapa contoh (seperti Alluxio, JuiceFS, dll) yang bisa kita pelajari. Alasan mengapa kita tidak dapat mengintegrasikan proyek-proyek ini secara langsung adalah karena kita fokus pada granularitas data yang berbeda. Alluxio dan JuiceFS didesain untuk dataset atau file POSIX, sementara kami fokus pada level record data (vektor).

Ketika data vektor diselesaikan pada penyimpanan S3, jawaban untuk metadata mudah: simpan di ETCD. Lalu, bagaimana dengan data log? Dalam implementasi klasik, penyimpanan log juga didasarkan pada SAN. File log dari satu anggota grup database dibagikan dalam cluster database untuk tujuan pemulihan kegagalan. Jadi, hal ini tidak menjadi masalah hingga kita masuk ke lingkungan cloud.

Dalam makalah Spanner, Google mengilustrasikan bagaimana mereka mengimplementasikan database yang terdistribusi secara global (grup) dengan algoritma konsensus Paxos. Anda perlu memprogram kluster database sebagai grup replikasi state machine. Redo log biasanya merupakan "state" yang akan direplikasi di seluruh grup.

Replikasi redo-log dengan algoritma konsensus adalah alat yang ampuh, dan memiliki keuntungan besar dalam beberapa skenario bisnis. Tetapi untuk database vektor Milvus, kami tidak menemukan insentif yang cukup untuk membuat grup replikasi mesin state secara keseluruhan. Kami memutuskan untuk menggunakan antrean/platform pesan awan (Apache Pulsar, Apache Kafka, dll.) sebagai penyimpanan bersama awan alternatif untuk penyimpanan log. Dengan mendelegasikan penyimpanan log ke platform perpesanan, kami memperoleh manfaat di bawah ini.

  • Grup ini lebih digerakkan oleh peristiwa, yang berarti banyak proses dapat dilakukan secara asinkron. Ini meningkatkan skalabilitas.
  • Komponen-komponen digabungkan secara lebih longgar, sehingga lebih mudah untuk melakukan peningkatan bergulir secara online. Ini meningkatkan ketersediaan dan operabilitas.

Kita akan membahas kembali topik ini di bagian selanjutnya.

Sejauh ini, kita telah menyelesaikan pertimbangan penting dari cluster database. Sebelum kita bisa melompat ke diskusi tentang arsitektur Milvus 2.0, izinkan saya menjelaskan terlebih dahulu bagaimana kita mengelola vektor di Milvus.

Manajemen data dan prediktabilitas kinerja

Milvus menyimpan vektor dalam koleksi. "Koleksi" adalah sebuah konsep logis, setara dengan "tabel" dalam database SQL. Sebuah "koleksi" dapat memiliki beberapa file fisik untuk menyimpan vektor. File fisik adalah sebuah "segmen". "Segmen" adalah konsep fisik seperti file ruang tabel dalam database SQL. Ketika volume data kecil, kita dapat menyimpan semuanya dalam satu segmen/file fisik. Namun saat ini, kita terus-menerus menghadapi data yang besar. Ketika ada beberapa segmen/file fisik, bagaimana kita harus menyebarkan data dalam partisi data yang berbeda?

Meskipun data lebih diutamakan daripada indeks, kita harus menyimpan data dengan cara yang lebih disukai oleh algoritma indeks untuk membuat akses data secara efisien dalam banyak kasus. Strategi yang sering digunakan dalam database SQL adalah partisi dengan rentang nilai kunci partisi. Orang biasanya membuat indeks berkerumun untuk menerapkan kunci partisi. Secara keseluruhan, ini adalah pendekatan yang layak untuk database SQL. Data disimpan dalam bentuk yang baik, dioptimalkan untuk I/O (prefetch). Tetapi masih ada kekurangan.

  • Kemiringan data. Beberapa partisi mungkin memiliki lebih banyak data daripada yang lain. Distribusi data dunia nyata tidak sesederhana rentang angka.
  • Akses hotspot. Lebih banyak beban kerja yang mungkin masuk ke beberapa partisi data.

Bayangkan lebih banyak beban kerja yang masuk ke partisi dengan lebih banyak data. Kita perlu menyeimbangkan kembali data di seluruh partisi ketika situasi ini terjadi. (Ini adalah kehidupan sehari-hari DBA yang membosankan).

The Clustered index for vectors Indeks berkerumun untuk vektor

Kita juga dapat membuat indeks berkerumun untuk vektor (indeks daftar terbalik). Tapi itu bukan kasus yang sama dengan database SQL. Setelah indeks dibuat dalam database SQL, akan sangat efisien untuk mengakses data melalui indeks, dengan lebih sedikit komputasi dan lebih sedikit operasi I/O. Tetapi untuk data vektor, akan ada lebih banyak komputasi dan operasi I/O bahkan dengan indeks. Jadi, kekurangan yang disebutkan sebelumnya akan memiliki dampak yang lebih parah pada cluster database vektor. Selain itu, biaya untuk menyeimbangkan kembali vektor di berbagai segmen sangat tinggi karena volume data dan kompleksitas komputasi.

Di Milvus, kami menggunakan strategi partisi berdasarkan pertumbuhan. Ketika kami menyuntikkan data ke dalam koleksi vektor, Milvus akan menambahkan vektor baru ke segmen terbaru dalam koleksi. Milvus akan menutup segmen ketika ukurannya sudah cukup besar (ambang batasnya bisa dikonfigurasi) dan membangun indeks untuk segmen yang sudah ditutup. Sementara itu, segmen baru akan dibuat untuk menyimpan data yang akan datang. Strategi sederhana ini lebih seimbang untuk pemrosesan vektor.

Kueri vektor adalah proses untuk mencari kandidat yang paling mirip dalam koleksi vektor. Ini adalah prosedur MapReduce yang umum. Sebagai contoh, kita ingin mencari 20 hasil yang paling mirip dari koleksi vektor dengan sepuluh segmen. Kita dapat mencari 20 teratas pada setiap segmen dan kemudian menggabungkan 20 * 10 hasil ke dalam 20 hasil akhir. Karena setiap segmen memiliki jumlah vektor yang sama dan indeks yang sama, waktu pemrosesan pada setiap segmen hampir sama. Hal ini memberikan kita keuntungan dalam hal prediktabilitas kinerja, yang sangat penting ketika merencanakan skala cluster database.

Paradigma baru dalam Milvus 2.0

Di Milvus 1.0, kami mengimplementasikan grup sharding pemisahan baca/tulis seperti kebanyakan database SQL. Ini adalah upaya yang baik untuk menskalakan cluster database Milvus. Tetapi masalahnya juga cukup jelas.

Milvus database 1.0 Basis data Milvus 1.0

Pada Milvus 1.0, simpul R/W harus menangani segmen terbaru, termasuk penambahan vektor, pencarian pada segmen yang tidak terindeks, membangun indeks, dll. Karena setiap koleksi hanya memiliki satu penulis, penulis akan sangat sibuk jika data terus menerus dialirkan ke dalam sistem. Kinerja pembagian data antara node R/W dan node pembaca juga menjadi masalah. Selain itu, kita harus mengandalkan NFS (tidak stabil) atau penyimpanan awan premium (terlalu mahal) untuk penyimpanan data bersama.

Masalah-masalah yang ada ini sulit untuk diatasi dalam arsitektur Milvus 1.0. Oleh karena itu, kami telah memperkenalkan paradigma baru ke dalam desain Milvus 2.0 untuk menyelesaikan masalah ini.

Milvus architecture Arsitektur Milvus

Model aktor

Ada dua model untuk memprogram sistem komputasi konkuren.

  • Memori bersama yang berarti kontrol konkurensi (penguncian) dan pemrosesan sinkron
  • Model aktor (AKA pengoperan pesan) yang berarti pemrosesan yang digerakkan oleh pesan dan asinkron

Kita juga dapat menerapkan kedua model ini dalam cluster database terdistribusi.

Seperti yang dinyatakan sebelumnya, sebagian besar database terdistribusi yang terkenal menggunakan metode yang sama: replikasi log ulang dengan algoritma konsensus. Ini adalah pemrosesan sinkron menggunakan algoritme konsensus untuk membangun memori bersama terdistribusi untuk catatan redo-log. Berbagai perusahaan dan modal ventura telah menginvestasikan miliaran dolar dalam teknologi ini. Saya tidak ingin mengomentari hal ini sampai kami mulai mengerjakan Milvus 2.0. Banyak orang menganggap teknologi ini sebagai satu-satunya cara untuk mewujudkan sistem basis data terdistribusi. Ini menjengkelkan. Jika saya tidak mengatakan sesuatu, orang mungkin akan salah paham bahwa kami gegabah dalam mendesain database terdistribusi.

Dalam beberapa tahun terakhir, replikasi Redo-log dengan algoritma konsensus telah menjadi teknologi basis data yang paling dibesar-besarkan. Ada dua masalah utama.

  • Anggapan bahwa replikasi redo-log lebih baik adalah rapuh.
  • Vendor menyesatkan ekspektasi orang pada kemampuan algoritma konsensus.

Katakanlah kita memiliki dua node database, node sumber dan node target. Pada awalnya, mereka memiliki salinan data yang sama persis. Kita memiliki beberapa operasi perubahan (pernyataan SQL I/U/D) pada node sumber, dan kita ingin agar node target tetap diperbarui. Apa yang harus kita lakukan? Cara yang paling sederhana adalah mengulang operasi pada simpul target. Tetapi ini bukan cara yang paling efisien.

Berpikir tentang biaya operasional dari pernyataan I/U/D, kita dapat membaginya ke dalam persiapan eksekusi dan bagian pekerjaan fisik. Bagian persiapan eksekusi meliputi pekerjaan pengurai SQL, pengoptimal SQL, dll. Tidak peduli berapa banyak catatan data yang akan terpengaruh, itu adalah biaya tetap. Biaya bagian pekerjaan fisik tergantung pada berapa banyak catatan data yang akan terpengaruh; ini adalah biaya mengambang. Ide di balik replikasi redo-log adalah untuk menghemat biaya tetap pada simpul target; kami hanya memutar ulang redo-log (pekerjaan fisik) pada simpul target.

Persentase penghematan biaya adalah kebalikan dari jumlah catatan redo-log. Jika satu operasi hanya memengaruhi satu catatan, saya akan melihat penghematan yang signifikan dari replikasi redo-log. Bagaimana jika jumlahnya 10.000 catatan? Maka kita harus khawatir tentang keandalan jaringan. Mana yang lebih dapat diandalkan, mengirim satu operasi atau 10.000 catatan redo-log? Bagaimana dengan satu juta catatan? Replikasi redo-log sangat bagus untuk skenario seperti sistem pembayaran, sistem metadata, dll. Dalam skenario ini, setiap operasi database I/U/D hanya mempengaruhi sejumlah kecil catatan (1 atau 2). Tetapi sulit untuk bekerja dengan beban kerja intensif I/O seperti pekerjaan batch.

Vendor selalu mengklaim algoritma konsensus dapat memberikan konsistensi yang kuat pada cluster database. Tetapi orang hanya menggunakan algoritma konsensus untuk mereplikasi catatan redo-log. Catatan redo-log konsisten pada node yang berbeda, tetapi itu tidak berarti tampilan data pada node lain juga konsisten. Kita harus menggabungkan catatan redo-log ke dalam catatan tabel yang sebenarnya. Jadi, bahkan dengan pemrosesan sinkron ini, kita masih hanya bisa mendapatkan konsistensi pada tampilan data.

Kita harus menggunakan replikasi redo-log dengan algoritma konsensus di tempat yang tepat. Sistem metadata (ETCD) dan platform pengiriman pesan (misalnya, Apache Pulsar) yang digunakan di Milvus 2.0 telah menerapkan algoritma konsensus. Namun seperti yang saya katakan sebelumnya, "untuk basis data vektor Milvus, kami tidak menemukan insentif yang cukup untuk menjadi kelompok replikasi mesin negara secara keseluruhan."

Di Milvus 2.0, kami menggunakan model aktor untuk mengatur node pekerja. Node-node pekerja itu kesepian. Mereka hanya berbicara dengan platform pengiriman pesan, menerima perintah dan mengirim hasil. Kedengarannya membosankan.

"Apa moto kita?" "Membosankan selalu yang terbaik." - The Hitman's Bodyguard (2017)

Model aktor tidak sinkron. Sangat cocok untuk skalabilitas dan ketersediaan. Karena node pekerja tidak saling mengenal, tidak ada dampak pada node pekerja lain jika beberapa node pekerja bergabung atau dihapus.

Pemisahan ketersediaan dan daya tahan

Di Milvus 2.0, kami melakukan replay operasi daripada replay log, karena dalam basis data vektor, tidak ada banyak perbedaan antara replay operasi dan replay log. Kami tidak memiliki fungsi Update maupun fungsi Insert with Select. Dan juga jauh lebih mudah untuk melakukan pengulangan operasi dengan model aktor.

Jadi, beberapa node pekerja dapat menjalankan operasi yang sama dari platform pengiriman pesan sesuai dengan tanggung jawab mereka. Saya sebutkan sebelumnya bahwa kami memutuskan untuk menggunakan penyimpanan awan S3 sebagai lapisan penyimpanan bersama dari cluster database Milvus. Penyimpanan S3 sangat andal. Lalu apakah perlu bagi node pekerja yang berbeda untuk menulis data yang sama ke penyimpanan bersama?

Oleh karena itu, kami merancang tiga peran untuk node pekerja.

  • Node kueri mempertahankan tampilan data dalam memori sesuai dengan penugasan. Pekerjaan node kueri termasuk melakukan pencarian vektor dan menjaga agar data dalam memori tetap diperbarui. Tetapi tidak perlu menulis apa pun ke penyimpanan S3. Ini adalah simpul yang paling sensitif terhadap memori dalam grup.
  • Simpul data bertanggung jawab untuk menulis data baru ke penyimpanan S3. Simpul data tidak perlu mempertahankan tampilan data dalam memori, sehingga konfigurasi perangkat keras simpul data sangat berbeda dengan simpul kueri.
  • Simpul indeks membangun indeks untuk segmen yang ditutup oleh simpul data ketika ukuran segmen mencapai ambang batas. Ini adalah pekerjaan yang paling banyak menggunakan CPU di dalam grup.

Ketiga jenis node ini mewakili berbagai jenis beban kerja. Mereka dapat menskalakan secara independen. Kami menyebutnya pemisahan ketersediaan dan daya tahan yang dipelajari dari basis data cloud Microsoft Socrates.

Akhir, juga awal

Artikel ini telah mengulas beberapa keputusan desain database vektor Milvus 2.0. Mari kita bahas poin-poin tersebut dengan cepat di sini.

  • Kami telah memilih konsistensi akhir untuk Milvus cluster 2.0.
  • Kami telah mengintegrasikan komponen cloud yang sudah matang ke dalam Milvus 2.0 sebanyak mungkin. Kami telah mengendalikan komponen baru yang diperkenalkan oleh Milvus 2.0 ke dalam lingkungan produksi pengguna.
  • Dengan mengikuti model aktor dan pemisahan ketersediaan dan daya tahan, Milvus 2.0 mudah untuk ditingkatkan di lingkungan cloud.

Sejauh ini, kami telah membentuk tulang punggung basis data yang dapat diskalakan di lingkungan cloud Milvus 2.0, tetapi backlog kami berisi banyak persyaratan dari komunitas Milvus yang harus dipenuhi. Jika Anda memiliki misi yang sama ("Membangun lebih banyak perangkat lunak infrastruktur sumber terbuka untuk mempercepat transformasi AI"), selamat datang untuk bergabung dengan komunitas Milvus.

Milvus adalah proyek kelulusan dari yayasan LF AI & Data. Anda TIDAK perlu menandatangani Perjanjian Kerja Sama (PKB) untuk Milvus!

Lampiran

Dokumen desain Milvus

https://github.com/milvus-io/milvus/tree/master/docs/design_docs

Implementasi Raft di C++

Jika Anda masih tertarik dengan algoritma konsensus, saya sarankan Anda untuk melihat proyek sumber terbuka eBay, Gringofts. Ini adalah implementasi C++ dari algoritma konsensus Raft (varian dari keluarga Paxos). Teman saya Jacky dan Elvis (mantan rekan kerja saya di Morgan Stanley) membuatnya untuk sistem pembayaran online eBay, yang merupakan salah satu skenario yang paling cocok untuk teknologi ini.

Try Managed Milvus for Free

Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

Get Started

Like the article? Spread the word

Terus Baca