Home
Blog
Memilih basis data vektor untuk pencarian ANN di Reddit

Memilih basis data vektor untuk pencarian ANN di Reddit

Engineering

November 28, 2025

Chris Fournie

Artikel ini ditulis oleh Chris Fournie, Staf Insinyur Perangkat Lunak di Reddit, dan awalnya diterbitkan di Reddit, dan diposting ulang di sini dengan izin.

Pada tahun 2024, tim Reddit menggunakan berbagai solusi untuk melakukan pencarian vektor dengan perkiraan tetangga terdekat (ANN). Mulai dari Vertex AI Vector Search milik Google dan bereksperimen dengan menggunakan pencarian vektor ANN Apache Solr untuk beberapa set data yang lebih besar, hingga perpustakaan FAISS milik Facebook untuk set data yang lebih kecil (di-host di side-cars yang diskalakan secara vertikal). Semakin banyak tim di Reddit yang menginginkan solusi pencarian vektor ANN yang didukung secara luas yang hemat biaya, memiliki fitur pencarian yang mereka inginkan, dan dapat diskalakan ke data seukuran Reddit. Untuk memenuhi kebutuhan ini, pada tahun 2025, kami mencari basis data vektor yang ideal untuk tim Reddit.

Tulisan ini menjelaskan proses yang kami gunakan untuk memilih database vektor terbaik untuk kebutuhan Reddit saat ini. Ini tidak menjelaskan database vektor terbaik secara keseluruhan, atau serangkaian persyaratan fungsional dan non-fungsional yang paling penting untuk semua situasi. Ini menjelaskan apa yang dihargai dan diprioritaskan oleh Reddit dan budaya tekniknya ketika memilih database vektor. Tulisan ini dapat menjadi inspirasi untuk pengumpulan dan evaluasi kebutuhan Anda sendiri, tetapi setiap organisasi memiliki budaya, nilai, dan kebutuhannya sendiri.

Proses evaluasi

Secara keseluruhan, langkah-langkah pemilihannya adalah:

1. Mengumpulkan konteks dari tim

2. Mengevaluasi solusi secara kualitatif

3. Mengevaluasi pesaing utama secara kuantitatif

4. Seleksi akhir

1. Mengumpulkan konteks dari tim

Tiga buah konteks dikumpulkan dari tim yang tertarik untuk melakukan pencarian vektor ANN:

Persyaratan fungsional (misalnya, Pencarian vektor hibrida dan leksikal? Kueri penelusuran rentang? Pemfilteran berdasarkan atribut non-vektor?)
Persyaratan non-fungsional (misalnya, Dapatkah mendukung vektor 1B? Dapatkah mencapai latensi P99 <100ms?)
Tim basis data vektor sudah tertarik pada

Mewawancarai tim untuk mendapatkan persyaratan bukanlah hal yang sepele. Banyak yang akan menjelaskan kebutuhan mereka dalam hal bagaimana mereka saat ini menyelesaikan masalah, dan tantangan Anda adalah memahami dan menghilangkan bias tersebut.

Sebagai contoh, sebuah tim sudah menggunakan FAISS untuk pencarian vektor ANN dan menyatakan bahwa solusi baru harus secara efisien mengembalikan 10 ribu hasil per panggilan pencarian. Setelah berdiskusi lebih lanjut, alasan dari 10K hasil tersebut adalah karena mereka perlu melakukan pemfilteran post-hoc, dan FAISS tidak menawarkan pemfilteran hasil ANN pada waktu kueri. Masalah mereka yang sebenarnya adalah bahwa mereka membutuhkan penyaringan, sehingga solusi apa pun yang menawarkan penyaringan yang efisien sudah cukup, dan mengembalikan hasil 10K hanyalah sebuah solusi yang diperlukan untuk meningkatkan daya ingat mereka. Idealnya, mereka ingin menyaring seluruh koleksi sebelum menemukan tetangga terdekat.

Meminta database vektor yang sudah digunakan atau diminati oleh tim juga merupakan hal yang berharga. Jika setidaknya satu tim memiliki pandangan positif tentang solusi mereka saat ini, itu adalah tanda bahwa database vektor dapat menjadi solusi yang berguna untuk dibagikan ke seluruh perusahaan. Jika tim hanya memiliki pandangan negatif terhadap suatu solusi, maka kita tidak boleh memasukkannya sebagai pilihan. Menerima solusi yang diminati oleh tim juga merupakan cara untuk memastikan bahwa tim merasa dilibatkan dalam proses dan membantu kami membentuk daftar awal pesaing utama untuk dievaluasi; ada terlalu banyak solusi pencarian vektor ANN di database baru dan yang sudah ada untuk menguji semuanya secara menyeluruh.

2. Mengevaluasi solusi secara kualitatif

Dimulai dengan daftar solusi yang diminati oleh tim, untuk mengevaluasi secara kualitatif solusi pencarian vektor ANN mana yang paling sesuai dengan kebutuhan kami, kami:

Meneliti setiap solusi dan menilai seberapa baik solusi tersebut memenuhi setiap persyaratan vs bobot kepentingan dari persyaratan tersebut
Menghapus solusi berdasarkan kriteria kualitatif dan diskusi
Memilih N solusi teratas untuk diuji secara kuantitatif

Daftar awal solusi pencarian vektor ANN yang kami sertakan:

Milvus
Qdrant
Weviate
Pencarian Terbuka
Pgvector (sudah menggunakan Postgres sebagai RDBMS)
Redis (sudah digunakan sebagai penyimpanan dan cache KV)
Cassandra (sudah digunakan untuk pencarian non-ANN)
Solr (sudah digunakan untuk pencarian leksikal dan bereksperimen dengan pencarian vektor)
Vespa
Pinecone
Vertex AI (sudah digunakan untuk pencarian vektor ANN)

Kami kemudian mengambil setiap persyaratan fungsional dan non-fungsional yang disebutkan oleh tim, ditambah beberapa batasan yang mewakili nilai dan tujuan teknik kami, membuat baris tersebut dalam spreadsheet, dan menimbang seberapa penting persyaratan tersebut (dari 1 hingga 3; ditampilkan dalam tabel ringkasan di bawah).

Untuk setiap solusi yang kami bandingkan, kami mengevaluasi (dalam skala 0 hingga 3) seberapa baik setiap sistem memenuhi persyaratan tersebut (seperti yang ditunjukkan pada tabel di bawah). Penilaian dengan cara ini agak subjektif, jadi kami memilih satu sistem dan memberikan contoh penilaian dengan alasan tertulis dan meminta para peninjau untuk merujuk kembali ke contoh tersebut. Kami juga memberikan panduan berikut untuk memberikan nilai skor: berikan nilai ini jika:

0: Tidak ada dukungan/bukti dukungan persyaratan
1: Dukungan persyaratan dasar atau tidak memadai
2: Dukungan kebutuhan yang cukup memadai
3: Dukungan kebutuhan yang kuat yang melampaui solusi yang sebanding

Kami kemudian membuat skor keseluruhan untuk setiap solusi dengan mengambil jumlah dari hasil kali skor persyaratan solusi dan tingkat kepentingan solusi tersebut (misalnya, Qdrant mendapat skor 3 untuk pemeringkatan ulang/penggabungan skor, yang memiliki tingkat kepentingan 2, jadi 3 x 2 = 6, ulangi untuk semua baris dan jumlahkan). Pada akhirnya, kita akan mendapatkan skor keseluruhan yang dapat digunakan sebagai dasar untuk menentukan peringkat dan mendiskusikan solusi, dan persyaratan mana yang paling penting (perlu diingat bahwa skor ini tidak digunakan untuk membuat keputusan akhir, tetapi sebagai alat diskusi).

Catatan editor: Ulasan ini didasarkan pada Milvus 2.4. Sejak saat itu, kami telah meluncurkan Milvus 2.5, Milvus 2.6, dan Milvus 3.0 sudah dekat, jadi beberapa angka mungkin sudah ketinggalan zaman. Meskipun begitu, perbandingan ini masih menawarkan wawasan yang kuat dan tetap sangat membantu.


Kategori	Kepentingan	Qdrant	Milvus (2.4)	Cassandra	Weviate	Solr	Vertex AI

Jenis Pencarian
Pencarian Hibrida	1	3	2	0	2	2	2
Pencarian Kata Kunci	1	2	2	2	2	3	1
Perkiraan pencarian NN	3	3	3	2	2	2	2
Pencarian Rentang	1	3	3	2	2	0	0
Pemeringkatan ulang/penggabungan skor	2	3	2	0	2	2	1

Metode Pengindeksan
HNSW	3	3	3	2	2	2	0
Mendukung beberapa metode pengindeksan	3	0	3	1	2	1	1
Kuantisasi	1	3	3	0	3	0	0
Pengacakan Sensitif Lokalitas (LSH)	1	0	0Catatan: Milvus 2.6 mendukungnya.	0	0	0	0

Data
Jenis vektor selain float	1	2	2	0	2	2	0
Atribut metadata pada vektor (mendukung banyak atribut, ukuran record yang besar, dll.)	3	3	2	2	2	2	1
Opsi pemfilteran metadata (dapat memfilter metadata, memiliki pemfilteran sebelum/sesudah)	2	3	2	2	2	3	2
Tipe data atribut metadata (skema yang kuat, misalnya bool, int, string, json, array)	1	3	3	2	2	3	1
Batas atribut metadata (kueri rentang, misalnya 10 < x < 15)	1	3	3	2	2	2	1
Keragaman hasil berdasarkan atribut (misalnya, mendapatkan tidak lebih dari N hasil dari setiap subreddit dalam sebuah tanggapan)	1	2	1	2	3	3	0

Skala
Indeks vektor ratusan juta	3	2	3		1	2	3
Indeks vektor miliar	1	2	2		1	2	2
Vektor dukungan minimal 2k	2	2	2	2	2	1	1
Vektor dukungan lebih besar dari 2k	2	2	2	2	1	1	1
P95 Latensi 50-100ms @ X QPS	3	2	2	2	1	1	2
Latensi P99 <= 10ms @ X QPS	3	2	2	2	3	1	2
99,9% pengambilan ketersediaan	2	2	2	3	2	2	2
99,99% pengindeksan/penyimpanan ketersediaan	2	1	1	3	2	2	2

Operasi Penyimpanan
Dapat dihosting di AWS	3	2	2	2	2	3	0
Multi-Wilayah	1	1	2	3	1	2	2
Peningkatan tanpa waktu henti	1	2	2	3	2	2	1
Multi-Awan	1	3	3	3	2	2	0

API/Perpustakaan
gRPC	2	2	2	2	2	0	2
RESTful API	1	3	2	2	2	1	2
Pergi ke Perpustakaan	3	2	2	2	2	1	2
Perpustakaan Java	2	2	2	2	2	2	2
Python	2	2	2	2	2	2	2
Bahasa lain (C++, Ruby, dll)	1	2	2	3	2	2	2

Operasi Runtime
Metrik Prometheus	3	2	2	2	3	2	0
Operasi DB Dasar	3	2	2	2	2	2	2
Upserts	2	2	2	2	1	2	2
Operator Kubernetes	2	2	2	2	2	2	0
Penomoran halaman hasil	2	2	2	2	2	2	0
Menyematkan pencarian berdasarkan ID	2	2	2	2	2	2	2
Kembalikan Embedding dengan ID Kandidat dan nilai kandidat	1	3	2	2	2	2	2
ID yang diberikan pengguna	2	2	2	2	2	2	2
Mampu mencari dalam konteks kumpulan berskala besar	1	2	1	1	2	1	2
Cadangan / Cuplikan: mendukung kemampuan untuk membuat cadangan seluruh basis data	1	2	2	2	3	3	2
Dukungan indeks besar yang efisien (perbedaan penyimpanan dingin vs panas)	1	3	2	2	2	1	2

Dukungan/Komunitas
Netralitas vendor	3	3	2	3	2	3	0
Dukungan api yang kuat	3	3	3	2	2	2	2
Dukungan vendor	2	2	2	2	2	2	0
Kecepatan Komunitas	2	3	2	2	2	2	0
Basis Pengguna Produksi	2	3	3	2	2	1	2
Perasaan Komunitas	1	3	2	2	2	2	1
Bintang Github	1	2	2	2	2	2	0

Konfigurasi
Penanganan Rahasia	2	2	2	2	1	2	2

Sumber
Sumber Terbuka	3	3	3	3	2	3	0
Bahasa	2	3	3	2	3	2	0
Rilis	2	3	3	2	2	2	2
Pengujian hulu	1	2	3	3	2	2	2
Ketersediaan dokumentasi	3	3	3	2	1	2	1

Biaya
Biaya Efektif	2	2	2	2	2	2	1

Kinerja
Dukungan untuk menyetel pemanfaatan sumber daya untuk CPU, memori, dan disk	3	2	2	2	2	2	2
Pemecahan multi-simpul (pod)	3	2	2	3	2	2	2
Memiliki kemampuan untuk menyetel sistem untuk menyeimbangkan antara latensi dan throughput	2	2	2	3	2	2	2
Pemartisian yang ditentukan pengguna (menulis)	1	3	2	3	1	2	0
Multi-penyewa	1	3	2	1	3	2	2
Partisi	2	2	2	3	2	2	2
Replikasi	2	2	2	3	2	2	2
Redundansi	1	2	2	3	2	2	2
Failover Otomatis	3	2	0 Catatan: Milvus 2.6 mendukungnya.	3	2	2	2
Penyeimbangan Beban	2	2	2	3	2	2	2
Dukungan GPU	1	0	2	0	0	0	0

		Qdrant	Milvus	Cassandra	Weviate	Solr	Vertex AI
Skor solusi secara keseluruhan		292	281	264	250	242	173

Kami mendiskusikan skor keseluruhan dan persyaratan dari berbagai sistem dan berusaha memahami apakah kami telah memberikan bobot yang tepat terhadap pentingnya persyaratan dan apakah beberapa persyaratan sangat penting sehingga harus dianggap sebagai kendala utama. Salah satu persyaratan yang kami identifikasi adalah apakah solusi tersebut bersifat open-source atau tidak, karena kami menginginkan solusi yang dapat membuat kami terlibat, berkontribusi, dan dengan cepat memperbaiki masalah-masalah kecil jika kami mengalaminya dalam skala kami. Berkontribusi dan menggunakan perangkat lunak sumber terbuka adalah bagian penting dari budaya teknik Reddit. Hal ini menghilangkan solusi yang hanya di-host (Vertex AI, Pinecone) dari pertimbangan kami.

Selama diskusi, kami menemukan bahwa beberapa persyaratan utama lainnya sangat penting bagi kami:

Skala dan keandalan: kami ingin melihat bukti dari perusahaan lain yang menjalankan solusi dengan vektor 100 juta+ atau bahkan 1 miliar
Komunitas: Kami menginginkan solusi dengan komunitas yang sehat dengan banyak momentum di bidang yang sedang berkembang pesat ini
Jenis metadata yang ekspresif dan pemfilteran untuk memungkinkan lebih banyak kasus penggunaan kami (pemfilteran berdasarkan tanggal, boolean, dll.)
Dukungan untuk berbagai jenis indeks (tidak hanya HNSW atau DiskANN) agar lebih sesuai dengan kinerja untuk berbagai kasus penggunaan kami yang unik

Hasil dari diskusi dan penajaman persyaratan utama membuat kami memilih untuk menguji (secara berurutan) secara kuantitatif:

Qdrant
Milvus
Vespa, dan
Weviate

Sayangnya, keputusan seperti ini membutuhkan waktu dan sumber daya, dan tidak ada organisasi yang memiliki keduanya dalam jumlah yang tidak terbatas. Mengingat anggaran kami, kami memutuskan untuk menguji Qdrant dan Milvus, dan membiarkan pengujian Vespa dan Weviate sebagai tujuan jangka panjang.

Qdrant vs Milvus juga merupakan pengujian yang menarik dari dua arsitektur yang berbeda:

Qdrant: Jenis node homogen yang melakukan semua operasi basis data vektor ANN
Milvus: Jenis node heterogen (Milvus; satu untuk kueri, satu lagi untuk pengindeksan, satu lagi untuk konsumsi data, proksi, dll.)

Mana yang mudah disiapkan (sebuah tes dari dokumentasi mereka)? Mana yang mudah dijalankan (sebuah pengujian terhadap fitur-fitur ketahanan dan polesannya)? Dan mana yang berkinerja paling baik untuk kasus penggunaan dan skala yang kami pedulikan? Pertanyaan-pertanyaan ini kami coba jawab saat kami membandingkan solusi secara kuantitatif.

3. Mengevaluasi pesaing utama secara kuantitatif

Kami ingin lebih memahami seberapa besar skalabilitas setiap solusi, dan dalam prosesnya, merasakan bagaimana rasanya menyiapkan, mengonfigurasi, memelihara, dan menjalankan setiap solusi dalam skala besar. Untuk melakukan hal ini, kami mengumpulkan tiga set data vektor dokumen dan kueri untuk tiga kasus penggunaan yang berbeda, menyiapkan setiap solusi dengan sumber daya yang sama dalam Kubernetes, memuat dokumen ke dalam setiap solusi, dan mengirimkan beban kueri yang sama menggunakan K6 Grafana dengan eksekutor tingkat kedatangan yang meningkat untuk menghangatkan sistem sebelum mencapai target throughput (misalnya, 100 QPS).

Kami menguji throughput, titik puncak dari setiap solusi, hubungan antara throughput dan latensi, dan bagaimana mereka bereaksi terhadap kehilangan node di bawah beban (tingkat kesalahan, dampak latensi, dll.). Yang paling menarik adalah efek penyaringan pada latensi. Kami juga melakukan pengujian sederhana ya/tidak untuk memverifikasi bahwa kemampuan dalam dokumentasi berfungsi seperti yang dijelaskan (misalnya, upserts, delete, get by ID, administrasi pengguna, dll.) dan untuk merasakan ergonomi dari API tersebut.

Pengujian dilakukan pada Milvus v2.4 dan Qdrant v1.12. Karena keterbatasan waktu, kami tidak melakukan tuning atau pengujian secara mendalam terhadap semua jenis pengaturan indeks; pengaturan serupa digunakan pada setiap solusi, dengan bias ke arah recall ANN yang tinggi, dan pengujian difokuskan pada kinerja indeks HNSW. Sumber daya CPU dan memori yang serupa juga diberikan pada setiap solusi.

Dalam percobaan kami, kami menemukan beberapa perbedaan menarik antara kedua solusi tersebut. Dalam percobaan berikut, setiap solusi memiliki sekitar 340 juta vektor postingan Reddit dengan masing-masing 384 dimensi, untuk HNSW, M = 16, dan efConstruction = 100.

Dalam satu percobaan, kami menemukan bahwa untuk throughput kueri yang sama (100 QPS tanpa konsumsi pada waktu yang sama), menambahkan pemfilteran lebih mempengaruhi latensi Milvus daripada Qdrant.

Latensi kueri posting dengan pemfilteran

Di sisi lain, kami menemukan bahwa ada lebih banyak interaksi antara konsumsi dan beban kueri pada Qdrant daripada Milvus (ditunjukkan di bawah ini pada throughput konstan). Hal ini kemungkinan disebabkan oleh arsitektur mereka; Milvus membagi sebagian besar ingestion ke jenis node yang terpisah dari node yang melayani lalu lintas kueri, sedangkan Qdrant melayani lalu lintas ingestion dan kueri dari node yang sama.

Latensi kueri posting @ 100 QPS selama proses ingest

Ketika menguji keragaman hasil berdasarkan atribut (misalnya mendapatkan tidak lebih dari N hasil dari setiap subreddit dalam sebuah respons), kami menemukan bahwa untuk throughput yang sama, Milvus memiliki latensi yang lebih buruk daripada Qdrant (pada 100 QPS).

Latensi kueri pos dengan keragaman hasil

Kami juga ingin melihat seberapa efektif setiap solusi berskala ketika lebih banyak replika data ditambahkan (yaitu faktor replikasi, RF, ditingkatkan dari 1 menjadi 2). Pada awalnya, dengan melihat RF=1, Qdrant mampu memberikan latensi yang memuaskan untuk throughput yang lebih tinggi daripada Milvus (QPS yang lebih tinggi tidak ditampilkan karena pengujian tidak selesai tanpa kesalahan).

Qdrant mencatatkan latensi RF = 1 untuk berbagai macam throughput

Milvus memposting latensi RF = 1 untuk throughput yang bervariasi

Namun, ketika meningkatkan faktor replikasi, latensi p99 Qdrant meningkat, tetapi Milvus mampu mempertahankan throughput yang lebih tinggi daripada Qdrant, dengan latensi yang dapat diterima (Qdrant 400 QPS tidak ditampilkan karena pengujian tidak selesai karena latensi dan kesalahan yang tinggi).

Milvus memposting latensi RF=2 untuk throughput yang bervariasi

Qdrant memasang latensi RF=2 untuk berbagai macam throughput

Karena keterbatasan waktu, kami tidak memiliki cukup waktu untuk membandingkan recall ANN antara solusi pada dataset kami, tetapi kami mempertimbangkan pengukuran recall ANN untuk solusi yang disediakan oleh https://ann-benchmarks.com/ pada dataset yang tersedia untuk umum.

4. Seleksi akhir

Darisegi performa, tanpa banyak tuning dan hanya menggunakan HNSW, Qdrant tampaknya memiliki latensi mentah yang lebih baik dalam banyak pengujian daripada Milvus. Namun, Milvus tampak lebih baik dalam hal skala dengan peningkatan replikasi, dan memiliki isolasi yang lebih baik antara konsumsi dan beban kueri karena arsitektur tipe multi-simpulnya.

Darisisi operasi, terlepas dari kompleksitas arsitektur Milvus (beberapa tipe node, bergantung pada log write-ahead eksternal seperti Kafka dan penyimpanan metadata seperti etcd), kami lebih mudah men-debug dan memperbaiki Milvus daripada Qdrant ketika salah satu dari kedua solusi tersebut mengalami masalah. Milvus juga memiliki penyeimbangan ulang otomatis ketika meningkatkan faktor replikasi dari sebuah koleksi, sedangkan pada Qdrant yang bersumber terbuka, pembuatan manual atau pembuangan pecahan diperlukan untuk meningkatkan faktor replikasi (fitur yang harus kami buat sendiri atau menggunakan versi non sumber terbuka).

Milvus adalah teknologi yang lebih "berbentuk Reddit" daripada Qdrant; Milvus memiliki lebih banyak kesamaan dengan tumpukan teknologi kami yang lain. Milvus ditulis dalam Golang, bahasa pemrograman backend pilihan kami, dan dengan demikian lebih mudah bagi kami untuk berkontribusi daripada Qdrant, yang ditulis dalam Rust. Milvus memiliki kecepatan proyek yang sangat baik untuk penawaran sumber terbuka dibandingkan dengan Qdrant, dan Milvus memenuhi lebih banyak persyaratan utama kami.

Pada akhirnya, kedua solusi tersebut memenuhi sebagian besar persyaratan kami, dan dalam beberapa kasus, Qdrant memiliki keunggulan dalam hal kinerja, tetapi kami merasa bahwa kami dapat meningkatkan skala Milvus lebih jauh, merasa lebih nyaman menjalankannya, dan Milvus lebih cocok untuk organisasi kami daripada Qdrant. Kami berharap kami memiliki lebih banyak waktu untuk menguji Vespa dan Weaviate, tetapi mereka juga mungkin dipilih karena kecocokan organisasi (Vespa berbasis Java) dan arsitektur (Weaviate adalah tipe node tunggal seperti Qdrant).

Hal-hal penting yang bisa diambil

Tantang persyaratan yang Anda berikan dan cobalah untuk menghilangkan bias solusi yang ada.
Beri nilai pada kandidat solusi, dan gunakan itu untuk menginformasikan diskusi tentang persyaratan penting, bukan sebagai solusi yang paling tepat.
Evaluasi solusi secara kuantitatif, namun di sepanjang prosesnya, catatlah bagaimana rasanya bekerja dengan solusi tersebut.
Pilih solusi yang paling sesuai dengan organisasi Anda dari segi pemeliharaan, biaya, kegunaan, dan kinerja, bukan hanya karena solusi tersebut memiliki kinerja terbaik.

Ucapan Terima Kasih

Pekerjaan evaluasi ini dilakukan oleh Ben Kochie, Charles Njoroge, Amit Kumar, dan saya. Terima kasih juga kepada pihak-pihak lain yang telah berkontribusi dalam pekerjaan ini, termasuk Annie Yang, Konrad Reiche, Sabrina Kong, dan Andrew Johnson, untuk penelitian solusi kualitatif.

Catatan Editor

Kami ingin mengucapkan terima kasih yang sebesar-besarnya kepada tim teknisi Reddit - tidak hanya karena memilih Milvus untuk beban kerja pencarian vektor mereka, tetapi juga karena telah meluangkan waktu untuk mempublikasikan evaluasi yang sangat rinci dan adil. Jarang sekali kita melihat tingkat transparansi seperti ini dalam cara tim teknik membandingkan database, dan tulisan mereka akan sangat membantu siapa pun di komunitas Milvus (dan di luarnya) yang mencoba memahami lanskap database vektor yang sedang berkembang.

Seperti yang Chris sebutkan dalam tulisan tersebut, tidak ada satu pun database vektor yang "terbaik". Yang penting adalah apakah sebuah sistem sesuai dengan beban kerja, batasan, dan filosofi operasional Anda. Perbandingan Reddit mencerminkan kenyataan itu dengan baik. Milvus tidak menduduki peringkat teratas di setiap kategori, dan itu benar-benar diharapkan mengingat adanya pertukaran di berbagai model data dan tujuan kinerja.

Satu hal yang perlu diklarifikasi: Evaluasi Reddit menggunakan Milvus 2.4, yang merupakan rilis stabil pada saat itu. Beberapa fitur - seperti LSH dan beberapa pengoptimalan indeks - belum ada atau belum matang di 2.4, jadi beberapa skor secara alami mencerminkan garis dasar yang lebih tua. Sejak saat itu, kami telah merilis Milvus 2.5 dan kemudian Milvus 2.6, dan ini adalah sistem yang sangat berbeda dalam hal kinerja, efisiensi, dan fleksibilitas. Tanggapan komunitas sangat kuat, dan banyak tim yang telah melakukan upgrade.

Berikut ini sekilas tentang apa saja yang baru di Milvus 2.6:

Penggunaan memori hingga 72% lebih rendah dan kueri 4× lebih cepat dengan kuantisasi RaBitQ 1-bit
Pengurangan biaya 50% dengan penyimpanan berjenjang yang cerdas
Pencarian teks lengkap BM25 4 kali lebih cepat dibandingkan dengan Elasticsearch
Pemfilteran JSON 100x lebih cepat dengan Path Index baru
Arsitektur tanpa disk baru untuk pencarian yang lebih segar dengan biaya yang lebih rendah
Alur kerja "data masuk, data keluar" yang lebih sederhana untuk menyematkan pipeline
Dukungan untuk 100 ribu+ koleksi untuk menangani lingkungan multi-penyewa yang besar

Jika Anda ingin rincian lengkapnya, berikut adalah beberapa tindak lanjut yang bagus:

Ada pertanyaan atau ingin mendalami fitur apa pun? Bergabunglah dengan saluran Discord kami atau ajukan pertanyaan di GitHub. Anda juga dapat memesan sesi tatap muka selama 20 menit untuk mendapatkan wawasan, panduan, dan jawaban atas pertanyaan Anda melalui Milvus Office Hours.