Apa yang Diajarkan Pengguna Milvus kepada Kami di Tahun 2024

Gambaran Umum

Ketika Milvus berkembang pesat pada tahun 2024 dengan rilis-rilis besar dan ekosistem open-source yang berkembang pesat, sebuah harta karun tersembunyi berupa wawasan pengguna diam-diam terbentuk dalam komunitas kami di Discord. Kompilasi diskusi komunitas ini memberikan kesempatan unik untuk memahami tantangan pengguna kami secara langsung. Karena penasaran dengan sumber daya yang belum dimanfaatkan ini, saya memulai analisis komprehensif terhadap setiap utas diskusi dari tahun tersebut, mencari pola yang dapat membantu kami menyusun sumber daya pertanyaan umum untuk pengguna Milvus.

Analisis saya mengungkapkan tiga area utama di mana pengguna secara konsisten mencari panduan: Optimalisasi Kinerja, Strategi Penerapan, dan Manajemen Data. Para pengguna sering mendiskusikan cara menyempurnakan Milvus untuk lingkungan produksi dan melacak metrik kinerja secara efektif. Dalam hal penerapan, komunitas bergulat dengan pemilihan penerapan yang sesuai, memilih indeks pencarian yang optimal, dan menyelesaikan masalah dalam pengaturan terdistribusi. Pembicaraan manajemen data berpusat pada strategi migrasi data dari layanan ke layanan dan pemilihan model penyematan.

Mari kita bahas masing-masing area ini secara lebih rinci.

Penerapan

Milvus menyediakan mode penerapan yang fleksibel agar sesuai dengan berbagai kasus penggunaan. Namun, beberapa pengguna merasa kesulitan untuk menemukan pilihan yang tepat, dan ingin merasa nyaman bahwa mereka melakukannya dengan "benar".

Jenis penerapan mana yang harus saya pilih?

Pertanyaan yang sangat sering muncul adalah deployment mana yang harus dipilih dari Milvus Lite, Standalone, dan Distributed. Jawabannya terutama tergantung pada seberapa besar database vektor Anda dan berapa banyak lalu lintas yang akan dilayani:

Milvus Lite

Ketika membuat prototipe pada sistem lokal Anda dengan hingga beberapa juta vektor, atau mencari db vektor tertanam untuk pengujian unit dan CI/CD, Anda dapat menggunakan Milvus Lite. Harap dicatat bahwa beberapa fitur yang lebih canggih seperti pencarian teks lengkap belum tersedia di Milvus Lite, tetapi akan segera hadir.

Milvus Standalone

Jika sistem Anda perlu melayani lalu lintas produksi dan/atau Anda perlu menyimpan antara beberapa juta hingga seratus juta vektor, Anda harus menggunakan Milvus Standalone, yang mengemas semua komponen Milvus ke dalam satu citra Docker. Ada variasi yang hanya mengambil ketergantungan penyimpanan persisten (minio) dan penyimpanan metadata (etcd) sebagai citra terpisah.

Milvus Didistribusikan

Untuk penerapan skala yang lebih besar yang melayani lalu lintas produksi, seperti melayani miliaran vektor pada ribuan QPS, Anda harus menggunakan Milvus Distributed. Beberapa pengguna mungkin ingin melakukan pemrosesan batch offline dalam skala besar, misalnya, untuk deduplikasi data atau penautan rekaman, dan versi Milvus 3.0 yang akan datang akan menyediakan cara yang lebih efisien untuk melakukan hal ini melalui apa yang kami sebut sebagai danau vektor.

Layanan yang Dikelola Sepenuhnya

Bagi para pengembang yang ingin fokus pada pengembangan aplikasi tanpa mengkhawatirkan DevOps, Zilliz Cloud adalah Milvus yang dikelola sepenuhnya yang menawarkan tingkat gratis.

Lihat "Gambaran Umum Penerapan Milvus" untuk informasi lebih lanjut.

Berapa banyak memori, penyimpanan, dan komputasi yang saya perlukan?

Pertanyaan ini sering muncul, tidak hanya untuk pengguna Milvus yang sudah ada tetapi juga mereka yang sedang mempertimbangkan apakah Milvus sesuai untuk aplikasi mereka. Kombinasi yang tepat dari berapa banyak memori, penyimpanan, dan komputasi yang dibutuhkan oleh sebuah penerapan bergantung pada interaksi yang kompleks dari berbagai faktor.

Penyematan vektor berbeda dalam hal dimensi karena model yang digunakan. Dan beberapa indeks pencarian vektor disimpan sepenuhnya di memori, sedangkan yang lain menyimpan data ke disk. Selain itu, banyak indeks pencarian yang dapat menyimpan salinan terkompresi (terkuantisasi) dari embedding dan membutuhkan memori tambahan untuk struktur data grafik. Ini hanyalah beberapa faktor yang mempengaruhi memori dan penyimpanan.

Alat Pengukur Ukuran Sumber Daya Milvus

Untungnya, Zilliz (tim yang mengelola Milvus) telah membuat alat ukuran sumber daya yang melakukan pekerjaan yang luar biasa untuk menjawab pertanyaan ini. Masukkan dimensi vektor Anda, jenis indeks, opsi penerapan, dan seterusnya dan alat ini akan memperkirakan CPU, memori, dan penyimpanan yang dibutuhkan di berbagai jenis node Milvus dan ketergantungannya. Jarak tempuh Anda mungkin berbeda-beda, jadi pengujian beban nyata dengan data dan lalu lintas sampel selalu merupakan ide yang bagus.

Indeks vektor atau metrik jarak mana yang harus saya pilih?

Banyak pengguna yang tidak yakin indeks mana yang harus mereka pilih dan bagaimana cara mengatur hiperparameter. Pertama, Anda selalu dapat menyerahkan pilihan jenis indeks kepada Milvus dengan memilih AUTOINDEX. Namun, jika Anda ingin memilih jenis indeks tertentu, beberapa aturan praktis dapat menjadi titik awal.

Indeks Dalam Memori

Apakah Anda ingin membayar biaya untuk memasukkan indeks Anda sepenuhnya ke dalam memori? Indeks dalam memori biasanya merupakan yang tercepat tetapi juga mahal. Lihat "Indeks dalam memori" untuk daftar indeks yang didukung oleh Milvus dan pengorbanannya dalam hal latensi, memori, dan pemanggilan.

Perlu diingat bahwa ukuran indeks Anda bukan hanya jumlah vektor dikalikan dengan dimensi dan ukuran floating point. Sebagian besar indeks mengkuantifikasi vektor untuk mengurangi penggunaan memori, tetapi membutuhkan memori untuk struktur data tambahan. Data non-vektor lainnya (skalar) dan indeksnya juga membutuhkan ruang memori.

Indeks Pada Disk

Ketika indeks Anda tidak muat dalam memori, Anda dapat menggunakan salah satu dari "Indeks pada disk" yang disediakan oleh Milvus. Dua pilihan dengan latensi/sumber daya yang sangat berbeda adalah DiskANN dan MMap.

DiskANN menyimpan salinan vektor yang sangat terkompresi dalam memori, dan vektor yang tidak terkompresi dan struktur pencarian grafik pada disk. DiskANN menggunakan beberapa ide cerdas untuk mencari ruang vektor sambil meminimalkan pembacaan disk dan memanfaatkan kecepatan akses acak yang cepat dari SSD. Untuk latensi minimum, SSD harus dihubungkan melalui NVMe, bukan SATA untuk performa I/O terbaik.

Secara teknis, MMap bukanlah jenis indeks, tetapi mengacu pada penggunaan memori virtual dengan indeks dalam memori. Dengan memori virtual, halaman dapat ditukar antara disk dan RAM sesuai kebutuhan, yang memungkinkan indeks yang jauh lebih besar digunakan secara efisien jika pola akses sedemikian rupa sehingga hanya sebagian kecil data yang digunakan pada satu waktu.

DiskANN memiliki latensi yang sangat baik dan konsisten. MMap memiliki latensi yang lebih baik lagi ketika mengakses halaman dalam memori, tetapi penukaran halaman yang sering dilakukan akan menyebabkan lonjakan latensi. Dengan demikian, MMap dapat memiliki variabilitas latensi yang lebih tinggi, tergantung pada pola akses memori.

Indeks GPU

Opsi ketiga adalah membangun indeks menggunakan memori GPU dan menghitung. Dukungan GPU Milvus dikontribusikan oleh tim Nvidia RAPIDS. Pencarian vektor GPU mungkin memiliki latensi yang lebih rendah daripada pencarian CPU yang sesuai, meskipun biasanya dibutuhkan ratusan atau ribuan QPS pencarian untuk sepenuhnya mengeksploitasi paralelisme GPU. Selain itu, GPU biasanya memiliki memori yang lebih sedikit daripada RAM CPU dan lebih mahal untuk dijalankan.

Metrik Jarak

Pertanyaan yang lebih mudah untuk dijawab adalah metrik jarak mana yang sebaiknya Anda pilih untuk mengukur kesamaan antar vektor. Disarankan untuk memilih metrik jarak yang sama dengan yang digunakan untuk melatih model embedding Anda, yang biasanya berupa COSINE (atau IP ketika input dinormalisasi). Sumber model Anda (misalnya, halaman model di HuggingFace) akan memberikan klarifikasi tentang metrik jarak yang digunakan. Zilliz juga menyusun tabel yang mudah untuk mencari tahu.

Sebagai rangkuman, saya pikir banyak ketidakpastian di sekitar pilihan indeks berkisar pada ketidakpastian tentang bagaimana pilihan-pilihan ini memengaruhi latensi/penggunaan sumber daya/pemanggilan kembali dari penerapan Anda. Saya sarankan untuk menggunakan aturan praktis di atas untuk memutuskan antara indeks in-memory, on-disk, atau GPU, dan kemudian menggunakan panduan tradeoff yang diberikan dalam dokumentasi Milvus untuk memilih salah satunya.

Dapatkah Anda memperbaiki penerapan Milvus Distributed saya yang rusak?

Banyak pertanyaan berkisar pada masalah dalam menyiapkan dan menjalankan penerapan Milvus Distributed, dengan pertanyaan yang berkaitan dengan konfigurasi, peralatan, dan log debugging. Sulit untuk memberikan solusi tunggal karena setiap pertanyaan tampaknya berbeda dari yang lain, meskipun untungnya Milvus memiliki Discord yang dinamis di mana Anda dapat mencari bantuan, dan kami juga menawarkan jam kerja 1-on-1 dengan seorang ahli.

Bagaimana cara menggunakan Milvus di Windows?

Sebuah pertanyaan yang muncul beberapa kali adalah bagaimana cara menggunakan Milvus pada mesin Windows. Berdasarkan masukan dari Anda, kami telah menulis ulang dokumentasi untuk hal ini: lihat Menjalankan Milvus di Docker (Windows) untuk mengetahui bagaimana cara melakukannya, menggunakan Windows Subsystem for Linux 2 (WSL2).

Kinerja dan Pembuatan Profil

Setelah memilih jenis deployment dan menjalankannya, pengguna ingin merasa nyaman bahwa mereka telah membuat keputusan yang optimal dan ingin membuat profil kinerja dan status deployment mereka. Banyak pertanyaan yang berkaitan dengan cara membuat profil kinerja, mengamati status, dan mendapatkan wawasan tentang apa dan mengapa.

Bagaimana cara mengukur kinerja?

Pengguna ingin memeriksa metrik yang terkait dengan kinerja penerapan mereka sehingga mereka dapat memahami dan memperbaiki kemacetan. Metrik yang disebutkan termasuk latensi kueri rata-rata, distribusi latensi, volume kueri, penggunaan memori, penyimpanan disk, dan sebagainya. Metrik-metrik ini dapat diamati dari sistem pemantauan. Selain itu, Milvus 2.5 memperkenalkan alat baru yang disebut WebUI (umpan balik selamat datang!), yang memungkinkan Anda untuk mengakses lebih banyak informasi internal sistem seperti status pemadatan segmen, dari antarmuka web yang mudah digunakan.

Apa yang sedang terjadi di dalam Milvus saat ini (misalnya, status pengamatan)?

Terkait hal ini, pengguna ingin mengamati status internal dari penerapan mereka. Isu-isu yang diangkat termasuk memahami mengapa indeks pencarian membutuhkan waktu yang lama untuk dibuat, bagaimana menentukan apakah cluster itu sehat, dan memahami bagaimana kueri dieksekusi di seluruh node. Banyak dari pertanyaan-pertanyaan ini dapat dijawab dengan WebUI baru yang memberikan transparansi terhadap apa yang dilakukan sistem secara internal.

Bagaimana cara kerja beberapa aspek (kompleks) internal?

Pengguna tingkat lanjut sering kali menginginkan pemahaman tentang internal Milvus, misalnya, memiliki pemahaman tentang penyegelan segmen atau manajemen memori. Tujuan utamanya adalah untuk meningkatkan kinerja dan terkadang untuk men-debug masalah. Dokumentasi, terutama di bawah bagian "Konsep" dan "Panduan Administrasi" sangat membantu di sini, sebagai contoh lihat halaman "Gambaran Umum Arsitektur Milvus" dan "Pemadatan Clustering". Kami akan terus meningkatkan dokumentasi internal Milvus, membuatnya lebih mudah dipahami, dan menerima umpan balik atau permintaan apa pun melalui Discord.

Model embedding mana yang harus saya pilih?

Sebuah pertanyaan yang berkaitan dengan kinerja yang telah muncul beberapa kali dalam pertemuan, jam kerja, dan di Discord adalah bagaimana memilih model embedding. Ini adalah pertanyaan yang sulit untuk memberikan jawaban yang pasti meskipun kami merekomendasikan untuk memulai dengan model default seperti all-MiniLM-L6-v2.

Sama halnya dengan pilihan indeks pencarian, ada tradeoff antara komputasi, penyimpanan, dan pemanggilan. Model penyematan dengan dimensi keluaran yang lebih besar akan membutuhkan lebih banyak penyimpanan, semua hal lain dianggap sama, meskipun mungkin menghasilkan penarikan kembali yang lebih tinggi dari item yang relevan. Model penyematan yang lebih besar, untuk dimensi yang tetap, biasanya mengungguli model yang lebih kecil dalam hal penarikan kembali, meskipun dengan biaya komputasi dan waktu yang lebih tinggi. Papan peringkat yang memberi peringkat kinerja model embedding seperti MTEB didasarkan pada tolok ukur yang mungkin tidak sesuai dengan data dan tugas spesifik Anda.

Jadi, tidak masuk akal untuk memikirkan model penyematan yang "terbaik". Mulailah dengan model yang memiliki daya ingat yang dapat diterima dan memenuhi anggaran komputasi dan waktu Anda untuk menghitung penyematan. Pengoptimalan lebih lanjut seperti menyempurnakan data Anda atau mengeksplorasi komputasi/pemanggilan kembali secara empiris dapat ditunda setelah Anda memiliki sistem yang berfungsi dalam produksi.

Manajemen Data

Cara memindahkan data ke dalam dan keluar dari penerapan Milvus adalah tema utama lain dalam diskusi Discord, yang tidak mengherankan mengingat betapa pentingnya tugas ini untuk menempatkan aplikasi ke dalam produksi.

Bagaimana cara memindahkan data dari X ke Milvus? Bagaimana cara memigrasikan data dari Standalone ke Distributed? Bagaimana cara memigrasi dari 2.4.x ke 2.5.x?

Pengguna baru biasanya ingin memasukkan data yang sudah ada ke dalam Milvus dari platform lain, termasuk mesin pencari tradisional seperti Elasticsearch dan basis data vektor lainnya seperti Pinecone atau Qdrant. Pengguna yang sudah ada mungkin juga ingin memigrasikan data mereka dari satu penerapan Milvus ke yang lain, atau dari Milvus yang dihosting sendiri ke Zilliz Cloud yang dikelola sepenuhnya.

Layanan Vector Transport Service (VTS ) dan layanan Migrasi terkelola di Zilliz Cloud dirancang untuk tujuan ini.

Bagaimana cara menyimpan dan memuat cadangan data? Bagaimana cara mengekspor data dari Milvus?

Milvus memiliki alat khusus, milvus-backup, untuk mengambil snapshot pada penyimpanan permanen dan memulihkannya.

Langkah selanjutnya

Saya harap ini telah memberi Anda beberapa petunjuk tentang cara mengatasi tantangan umum yang dihadapi ketika membangun dengan database vektor. Hal ini tentunya membantu kami untuk melihat kembali dokumentasi dan peta jalan fitur kami untuk terus mengerjakan hal-hal yang dapat membantu komunitas kami agar dapat sukses dengan Milvus. Satu hal penting yang ingin saya tekankan adalah bahwa pilihan Anda menempatkan Anda pada titik-titik yang berbeda dalam ruang tradeoff antara komputasi, penyimpanan, latensi, dan pemanggilan. Anda tidak dapat memaksimalkan semua kriteria kinerja ini secara bersamaan - tidak ada penerapan yang "optimal". Namun, dengan memahami lebih lanjut tentang cara kerja pencarian vektor dan sistem basis data terdistribusi, Anda dapat membuat keputusan yang tepat.

Setelah menelusuri sejumlah besar postingan dari tahun 2024, saya berpikir: mengapa manusia harus melakukan ini? Bukankah AI Generatif telah berjanji untuk menyelesaikan tugas seperti itu, yaitu mengurai teks dalam jumlah besar dan mengekstraksi wawasan? Bergabunglah dengan saya di bagian kedua dari artikel blog ini (segera hadir), di mana saya menyelidiki desain dan implementasi sistem multi-agen untuk mengekstraksi wawasan dari forum diskusi.

Sekali lagi terima kasih dan semoga kita bisa bertemu di komunitas Discord dan pertemuan Unstructured Data berikutnya. Untuk bantuan yang lebih praktis, kami mempersilakan Anda untuk memesan jam kerja 1-on-1. Masukan Anda sangat penting untuk meningkatkan Milvus!