Memperkenalkan AISAQ di Milvus: Pencarian Vektor Berskala Miliaran Baru Saja Menjadi 3.200× Lebih Murah untuk Memori
Basis data vektor telah menjadi infrastruktur inti untuk sistem AI yang sangat penting, dan volume datanya tumbuh secara eksponensial-sering kali mencapai miliaran vektor. Pada skala tersebut, semuanya menjadi lebih sulit: mempertahankan latensi rendah, menjaga akurasi, memastikan keandalan, dan beroperasi di berbagai replika dan wilayah. Namun, satu tantangan cenderung muncul lebih awal dan mendominasi keputusanarsitektur-BIAYA.
Untuk menghadirkan pencarian cepat, sebagian besar basis data vektor menyimpan struktur pengindeksan kunci dalam DRAM (Dynamic Random Access Memory), tingkat memori tercepat dan termahal. Desain ini efektif untuk kinerja, tetapi penskalaannya buruk. Penggunaan DRAM berskala dengan ukuran data, bukan lalu lintas kueri, dan bahkan dengan kompresi atau pembongkaran sebagian SSD, sebagian besar indeks harus tetap berada di memori. Seiring dengan bertambahnya kumpulan data, biaya memori dengan cepat menjadi faktor pembatas.
Milvus telah mendukung DISKANN, sebuah pendekatan ANN berbasis disk yang mengurangi tekanan memori dengan memindahkan sebagian besar indeks ke SSD. Namun, DISKANN masih mengandalkan DRAM untuk representasi terkompresi yang digunakan selama pencarian. Milvus 2.6 mengambil langkah lebih jauh dengan AISAQ, indeks vektor berbasis disk yang terinspirasi oleh DISKANN. Dikembangkan oleh KIOXIA, arsitektur AiSAQ dirancang dengan "Zero-DRAM-Footprint Architecture", yang menyimpan semua data yang sangat penting untuk pencarian pada disk dan mengoptimalkan penempatan data untuk meminimalisir operasi I/O. Dalam beban kerja miliaran vektor, hal ini mengurangi penggunaan memori dari 32 GB menjadi sekitar 10 MB-pengurangan 3.200×-sekaligusmempertahankan kinerja praktis.
Pada bagian selanjutnya, kami akan menjelaskan cara kerja pencarian vektor berbasis grafik, di mana biaya memori berasal, dan bagaimana AISAQ membentuk ulang kurva biaya untuk pencarian vektor skala miliar.
Cara Kerja Pencarian Vektor Berbasis Grafik Konvensional
Pencarian vektor adalah proses menemukan titik data yang representasi numeriknya paling dekat dengan kueri dalam ruang berdimensi tinggi. "Terdekat" berarti jarak terkecil menurut fungsi jarak, seperti jarak kosinus atau jarak L2. Dalam skala kecil, ini sangat mudah: hitung jarak antara kueri dan setiap vektor, lalu kembalikan yang terdekat. Namun, pada skala besar, katakanlah skala miliaran, pendekatan ini dengan cepat menjadi terlalu lambat untuk menjadi praktis.
Untuk menghindari perbandingan yang melelahkan, sistem pencarian tetangga terdekat (ANNS) modern mengandalkan indeks berbasis grafik. Alih-alih membandingkan kueri dengan setiap vektor, indeks mengatur vektor ke dalam sebuah grafik. Setiap simpul mewakili sebuah vektor, dan sisi-sisi menghubungkan vektor-vektor yang secara numerik berdekatan. Struktur ini memungkinkan sistem mempersempit ruang pencarian secara dramatis.
Grafik dibangun terlebih dahulu, hanya berdasarkan hubungan antar vektor. Ini tidak bergantung pada kueri. Ketika sebuah kueri tiba, tugas sistem adalah menavigasi grafik secara efisien dan mengidentifikasi vektor-vektor dengan jarak terkecil ke kueri-tanpa memindai seluruh kumpulan data.
Pencarian dimulai dari titik awal yang telah ditentukan dalam grafik. Titik awal ini mungkin jauh dari kueri, tetapi algoritme meningkatkan posisinya selangkah demi selangkah dengan bergerak ke arah vektor yang tampak lebih dekat dengan kueri. Selama proses ini, pencarian mempertahankan dua struktur data internal yang bekerja bersama: daftar kandidat dan daftar hasil.
Dan dua langkah terpenting selama proses ini adalah memperluas daftar kandidat dan memperbarui daftar hasil.
Memperluas Daftar Kandidat
Daftar kandidat menunjukkan ke mana pencarian dapat dilanjutkan. Ini adalah sekumpulan node graf yang diprioritaskan yang terlihat menjanjikan berdasarkan jaraknya ke kueri.
Pada setiap iterasi, algoritme:
Memilih kandidat terdekat yang ditemukan sejauh ini. Dari daftar kandidat, memilih vektor dengan jarak terkecil ke kueri.
Mengambil tetangga-tetangga vektor tersebut dari graf. Tetangga-tetangga ini adalah vektor-vektor yang diidentifikasi selama pembangunan indeks sebagai vektor yang dekat dengan vektor saat ini.
Mengevaluasi tetangga yang belum dikunjungi dan menambahkannya ke dalam daftar kandidat. Untuk setiap tetangga yang belum dieksplorasi, algoritme menghitung jaraknya ke kueri. Tetangga yang telah dikunjungi sebelumnya dilewati, sementara tetangga baru dimasukkan ke dalam daftar kandidat jika terlihat menjanjikan.
Dengan berulang kali memperluas daftar kandidat, pencarian akan menjelajahi wilayah yang semakin relevan dari grafik. Hal ini memungkinkan algoritme untuk terus bergerak ke arah jawaban yang lebih baik dengan hanya memeriksa sebagian kecil dari semua vektor.
Memperbarui Daftar Hasil
Pada saat yang sama, algoritma mempertahankan daftar hasil, yang mencatat kandidat terbaik yang ditemukan sejauh ini untuk hasil akhir. Saat pencarian berlangsung, algoritme ini:
Melacak vektor terdekat yang ditemui selama penelusuran. Ini termasuk vektor yang dipilih untuk perluasan serta vektor lain yang dievaluasi di sepanjang jalan.
Menyimpan jarak mereka ke kueri. Hal ini memungkinkan untuk mengurutkan kandidat dan mempertahankan K tetangga terdekat saat ini.
Seiring waktu, dengan semakin banyaknya kandidat yang dievaluasi dan semakin sedikitnya perbaikan yang ditemukan, daftar hasil akan menjadi stabil. Ketika eksplorasi graf lebih lanjut tidak mungkin menghasilkan vektor yang lebih dekat, pencarian dihentikan dan mengembalikan daftar hasil sebagai jawaban akhir.
Secara sederhana, daftar kandidat mengontrol eksplorasi, sementara daftar hasil menangkap jawaban terbaik yang ditemukan sejauh ini.
Pertukaran dalam Pencarian Vektor Berbasis Graf
Pendekatan berbasis grafik inilah yang membuat pencarian vektor berskala besar menjadi praktis. Dengan menavigasi grafik alih-alih memindai setiap vektor, sistem dapat menemukan hasil berkualitas tinggi dengan hanya menyentuh sebagian kecil dataset.
Namun, efisiensi ini tidak gratis. Pencarian berbasis grafik memperlihatkan pertukaran mendasar antara akurasi dan biaya.
Menjelajahi lebih banyak tetangga akan meningkatkan akurasi dengan mencakup porsi yang lebih besar dari grafik dan mengurangi kemungkinan kehilangan tetangga terdekat yang sebenarnya.
Pada saat yang sama, setiap perluasan tambahan akan menambah pekerjaan: lebih banyak perhitungan jarak, lebih banyak akses ke struktur graf, dan lebih banyak pembacaan data vektor. Ketika pencarian menjelajah lebih dalam atau lebih luas, biaya-biaya ini akan terakumulasi. Tergantung pada bagaimana indeks dirancang, biaya-biaya ini muncul sebagai penggunaan CPU yang lebih tinggi, peningkatan tekanan memori, atau I/O disk tambahan.
Menyeimbangkan kekuatan yang berlawanan ini - daya ingat yang tinggi versus penggunaan sumber daya yang efisien - adalah inti dari desain pencarian berbasis grafik.
Baik DISKANN maupun AISAQ dibangun berdasarkan ketegangan yang sama, tetapi mereka membuat pilihan arsitektur yang berbeda tentang bagaimana dan di mana biaya-biaya ini dibayarkan.
Bagaimana DISKANN Mengoptimalkan Pencarian Vektor Berbasis Disk
DISKANN adalah solusi ANN berbasis disk yang paling berpengaruh hingga saat ini dan berfungsi sebagai dasar resmi untuk kompetisi NeurIPS Big ANN, sebuah tolok ukur global untuk pencarian vektor berskala miliaran. Signifikansi DISKANN tidak hanya terletak pada performa, tetapi juga pada apa yang telah dibuktikannya: pencarian ANN berbasis grafik tidak harus disimpan di dalam memori untuk dapat bekerja dengan cepat.
Dengan menggabungkan penyimpanan berbasis SSD dengan struktur memori yang dipilih dengan cermat, DISKANN menunjukkan bahwa pencarian vektor berskala besar dapat mencapai akurasi yang kuat dan latensi rendah pada perangkat keras komoditas-tanpa memerlukan jejak DRAM yang besar. Hal ini dilakukan dengan memikirkan kembali bagian mana dari pencarian yang harus cepat dan bagian mana yang dapat mentolerir akses yang lebih lambat.
Pada tingkat yang tinggi, DISKANN menyimpan data yang paling sering diakses dalam memori, sementara memindahkan struktur yang lebih besar dan lebih jarang diakses ke disk. Keseimbangan ini dicapai melalui beberapa pilihan desain utama.
1. Menggunakan Jarak PQ untuk Memperluas Daftar Kandidat
Memperluas daftar kandidat adalah operasi yang paling sering dilakukan dalam pencarian berbasis grafik. Setiap perluasan membutuhkan estimasi jarak antara vektor kueri dan tetangga dari simpul kandidat. Melakukan perhitungan ini menggunakan vektor dimensi tinggi yang lengkap akan membutuhkan pembacaan acak yang sering dari disk - sebuah operasi yang mahal baik secara komputasi maupun dalam hal I/O.
DISKANN menghindari biaya ini dengan mengompresi vektor ke dalam kode Product Quantization (PQ) dan menyimpannya di dalam memori. Kode PQ jauh lebih kecil daripada vektor penuh, tetapi masih menyimpan informasi yang cukup untuk memperkirakan jarak.
Selama perluasan kandidat, DISKANN menghitung jarak menggunakan kode PQ dalam memori ini alih-alih membaca vektor penuh dari SSD. Hal ini secara dramatis mengurangi I/O disk selama penelusuran grafik, sehingga pencarian dapat memperluas kandidat dengan cepat dan efisien sekaligus menjaga sebagian besar lalu lintas SSD di luar jalur kritis.
2. Menempatkan Vektor Penuh dan Daftar Tetangga secara Bersama pada Disk
Tidak semua data dapat dikompresi atau diakses secara kira-kira. Setelah kandidat yang menjanjikan diidentifikasi, pencarian masih membutuhkan akses ke dua jenis data untuk mendapatkan hasil yang akurat:
Daftar tetangga, untuk melanjutkan penelusuran graf
Vektor penuh (tidak terkompresi), untuk pemeringkatan akhir
Struktur-struktur ini lebih jarang diakses dibandingkan kode PQ, sehingga DISKANN menyimpannya di SSD. Untuk meminimalkan overhead disk, DISKANN menempatkan daftar tetangga setiap node dan vektor penuhnya di wilayah fisik yang sama pada disk. Hal ini memastikan bahwa satu kali pembacaan SSD dapat mengambil keduanya.
Dengan menempatkan data terkait secara bersamaan, DISKANN mengurangi jumlah akses disk acak yang diperlukan selama pencarian. Pengoptimalan ini meningkatkan efisiensi ekspansi dan pemeringkatan, terutama pada skala besar.
3. Perluasan Node Paralel untuk Pemanfaatan SSD yang Lebih Baik
Pencarian ANN berbasis grafik adalah proses yang berulang. Jika setiap iterasi hanya memperluas satu node kandidat, sistem hanya mengeluarkan satu disk yang dibaca dalam satu waktu, sehingga sebagian besar bandwidth paralel SSD tidak terpakai. Untuk menghindari ketidakefisienan ini, DISKANN memperluas beberapa kandidat dalam setiap iterasi dan mengirimkan permintaan baca paralel ke SSD. Pendekatan ini memanfaatkan bandwidth yang tersedia dengan lebih baik dan mengurangi jumlah iterasi yang diperlukan.
Parameter beam_width_ratio mengontrol berapa banyak kandidat yang diperluas secara paralel: Lebar berkas = jumlah inti CPU × rasio beam_width_ratio. Rasio yang lebih tinggi akan memperluas pencarian - berpotensi meningkatkan akurasi - tetapi juga meningkatkan komputasi dan I/O disk.
Untuk mengimbangi hal ini, DISKANN memperkenalkan search_cache_budget_gb_ratio yang mencadangkan memori untuk menyimpan data yang sering diakses, sehingga mengurangi pembacaan SSD yang berulang. Bersama-sama, mekanisme ini membantu DISKANN menyeimbangkan akurasi, latensi, dan efisiensi I/O.
Mengapa Hal Ini Penting - dan Di Mana Batasannya Muncul
Desain DISKANN merupakan langkah maju yang besar untuk pencarian vektor berbasis disk. Dengan menyimpan kode PQ dalam memori dan mendorong struktur yang lebih besar ke SSD, hal ini secara signifikan mengurangi jejak memori dibandingkan dengan indeks grafik yang sepenuhnya berada dalam memori.
Pada saat yang sama, arsitektur ini masih bergantung pada DRAM yang selalu aktif untuk data yang sangat penting untuk pencarian. Kode PQ, cache, dan struktur kontrol harus tetap berada di dalam memori untuk menjaga efisiensi penelusuran. Ketika dataset berkembang menjadi miliaran vektor dan penyebaran menambahkan replika atau wilayah, kebutuhan memori masih dapat menjadi faktor pembatas.
Ini adalah celah yang dirancang untuk diatasi oleh AISAQ.
Bagaimana AISAQ Bekerja dan Mengapa Ini Penting
AISAQ dibangun langsung di atas ide inti di balik DISKANN, tetapi memperkenalkan perubahan penting: AISAQ menghilangkan kebutuhan untuk menyimpan data PQ dalam DRAM. Alih-alih memperlakukan vektor yang dikompresi sebagai struktur yang sangat penting untuk pencarian dan selalu ada di memori, AISAQ memindahkannya ke SSD dan mendesain ulang bagaimana data grafik ditata di disk untuk mempertahankan penjelajahan yang efisien.
Untuk melakukan hal ini, AISAQ mengatur ulang penyimpanan node sehingga data yang dibutuhkan selama pencarian grafik - vektor penuh, daftar tetangga, dan informasi PQ - disusun pada disk dalam pola yang dioptimalkan untuk lokalitas akses. Tujuannya bukan hanya untuk mendorong lebih banyak data ke disk yang lebih ekonomis, tetapi juga melakukannya tanpa merusak proses pencarian yang telah dijelaskan sebelumnya.
Untuk memenuhi kebutuhan aplikasi yang berbeda, AISAQ menyediakan dua mode penyimpanan berbasis disk: Performa dan Skala. Dari perspektif teknis, mode-mode ini berbeda terutama dalam hal bagaimana data yang dikompresi PQ disimpan dan diakses selama pencarian. Dari perspektif aplikasi, mode-mode ini menangani dua jenis kebutuhan yang berbeda: kebutuhan latensi rendah, tipikal pencarian semantik online dan sistem rekomendasi, dan kebutuhan skala sangat tinggi, tipikal RAG.
Kinerja AISAQ: Dioptimalkan untuk Kecepatan
Performa AISAQ menyimpan semua data di disk sambil mempertahankan overhead I/O yang rendah melalui kolokasi data.
Dalam mode ini:
Vektor lengkap setiap node, daftar edge, dan kode PQ tetangganya disimpan bersama pada disk.
Mengunjungi sebuah node hanya membutuhkan satu pembacaan SSD, karena semua data yang diperlukan untuk ekspansi dan evaluasi kandidat berada dalam satu lokasi.
Dari perspektif algoritma pencarian, hal ini sangat mirip dengan pola akses DISKANN. Perluasan kandidat tetap efisien, dan kinerja runtime sebanding, meskipun semua data yang sangat penting untuk pencarian sekarang berada di disk.
Pengorbanannya adalah biaya penyimpanan. Karena data PQ tetangga dapat muncul di beberapa halaman disk beberapa node, tata letak ini memperkenalkan redundansi dan secara signifikan meningkatkan ukuran indeks secara keseluruhan.
Oleh karena itu, mode AISAQ-Performance memprioritaskan latensi I/O yang rendah daripada efisiensi disk. Dari perspektif aplikasi, mode AiSAQ-Performance dapat menghasilkan latensi dalam kisaran 10 mSec, seperti yang diperlukan untuk pencarian semantik online.
Skala AISAQ: Dioptimalkan untuk Efisiensi Penyimpanan
AISAQ-Scale mengambil pendekatan yang berlawanan. Mode ini dirancang untuk meminimalkan penggunaan disk sambil tetap menyimpan semua data pada SSD.
Dalam mode ini:
Data PQ disimpan pada disk secara terpisah, tanpa redundansi.
Hal ini menghilangkan redundansi dan secara dramatis mengurangi ukuran indeks.
Kompensasinya adalah bahwa mengakses node dan kode PQ tetangganya mungkin memerlukan beberapa pembacaan SSD, sehingga meningkatkan operasi I/O selama perluasan kandidat. Jika tidak dioptimalkan, hal ini akan memperlambat pencarian secara signifikan.
Untuk mengendalikan overhead ini, mode AISAQ-Scale memperkenalkan dua pengoptimalan tambahan:
Penataanulang data PQ, yang mengurutkan vektor PQ berdasarkan prioritas akses untuk meningkatkan lokalitas dan mengurangi pembacaan secara acak.
Cache PQ dalam DRAM (
pq_read_page_cache_size), yang menyimpan data PQ yang sering diakses dan menghindari pembacaan disk berulang kali untuk entri yang panas.
Dengan pengoptimalan ini, mode AISAQ-Scale mencapai efisiensi penyimpanan yang jauh lebih baik daripada AISAQ-Performance, dengan tetap mempertahankan kinerja pencarian yang praktis. Performa tersebut tetap lebih rendah daripada DISKANN, tetapi tidak ada overhead penyimpanan (ukuran indeks serupa dengan DISKANN) dan jejak memori secara dramatis lebih kecil. Dari perspektif aplikasi, AiSAQ menyediakan sarana untuk memenuhi persyaratan RAG pada skala sangat tinggi.
Keuntungan Utama dari AISAQ
Dengan memindahkan semua data yang sangat penting untuk pencarian ke disk dan mendesain ulang bagaimana data tersebut diakses, AISAQ secara fundamental mengubah profil biaya dan skalabilitas pencarian vektor berbasis grafik. Desainnya memberikan tiga keuntungan yang signifikan.
1. Penggunaan DRAM Lebih Rendah Hingga 3.200× Lebih Rendah
Kuantisasi Produk secara signifikan mengurangi ukuran vektor dimensi tinggi, tetapi pada skala miliaran, jejak memori masih cukup besar. Bahkan setelah kompresi, kode PQ harus disimpan dalam memori selama pencarian dalam desain konvensional.
Sebagai contoh, pada SIFT1B, sebuah benchmark dengan satu miliar vektor 128 dimensi, kode PQ saja membutuhkan sekitar 30-120 GB DRAM, tergantung konfigurasi. Menyimpan seluruh vektor yang belum dikompresi akan membutuhkan tambahan ~480 GB. Meskipun PQ mengurangi penggunaan memori sebesar 4-16×, jejak yang tersisa masih cukup besar untuk mendominasi biaya infrastruktur.
AISAQ menghilangkan persyaratan ini sepenuhnya. Dengan menyimpan kode PQ pada SSD dan bukannya DRAM, memori tidak lagi dikonsumsi oleh data indeks yang persisten. DRAM hanya digunakan untuk struktur yang ringan dan bersifat sementara seperti daftar kandidat dan metadata kontrol. Pada praktiknya, hal ini mengurangi penggunaan memori dari puluhan gigabyte menjadi sekitar 10 MB. Dalam konfigurasi skala miliaran, DRAM turun dari 32 GB menjadi 10 MB, sebuah pengurangan 3.200 kali lipat.
Mengingat biaya penyimpanan SSD kira-kira 1/30 harga per unit kapasitas dibandingkan dengan DRAM, pergeseran ini memiliki dampak langsung dan dramatis pada total biaya sistem.
2. Tidak Ada Overhead I/O Tambahan
Memindahkan kode PQ dari memori ke disk biasanya akan meningkatkan jumlah operasi I/O selama pencarian. AISAQ menghindari hal ini dengan mengontrol tata letak data dan pola akses secara hati-hati. Daripada menyebarkan data terkait ke seluruh disk, AISAQ menempatkan kode PQ, vektor penuh, dan daftar tetangga secara bersamaan sehingga dapat diambil bersama-sama. Hal ini memastikan bahwa perluasan kandidat tidak menimbulkan pembacaan acak tambahan.
Untuk memberikan kontrol kepada pengguna atas pertukaran antara ukuran indeks dan efisiensi I/O, AISAQ memperkenalkan parameter inline_pq, yang menentukan berapa banyak data PQ yang disimpan sejajar dengan setiap node:
Inline_pq yang lebih rendah: ukuran indeks yang lebih kecil, tetapi mungkin memerlukan I / O tambahan
Inline_pq yang lebih tinggi: ukuran indeks yang lebih besar, tetapi mempertahankan akses sekali baca
Ketika dikonfigurasi dengan inline_pq = max_degree, AISAQ membaca vektor penuh node, daftar tetangga, dan semua kode PQ dalam satu operasi disk, sesuai dengan pola I/O DISKANN sambil menyimpan semua data pada SSD.
3. Akses PQ Berurutan Meningkatkan Efisiensi Komputasi
Dalam DISKANN, memperluas node kandidat membutuhkan R akses memori acak untuk mengambil kode PQ dari R tetangganya. AISAQ menghilangkan keacakan ini dengan mengambil semua kode PQ dalam satu I/O dan menyimpannya secara berurutan pada disk.
Tata letak berurutan memberikan dua manfaat penting:
Pembacaan SSD berurutan jauh lebih cepat daripada pembacaan acak yang tersebar.
Data yang bersebelahan lebih ramah terhadap cache, sehingga memungkinkan CPU menghitung jarak PQ dengan lebih efisien.
Hal ini meningkatkan kecepatan dan prediktabilitas penghitungan jarak PQ serta membantu mengimbangi biaya performa penyimpanan kode PQ pada SSD daripada DRAM.
AISAQ vs DISKANN: Evaluasi Performa
Setelah memahami perbedaan AISAQ secara arsitektur dengan DISKANN, pertanyaan selanjutnya adalah: bagaimana pilihan desain ini memengaruhi performa dan penggunaan sumber daya dalam praktiknya? Evaluasi ini membandingkan AISAQ dan DISKANN dalam tiga dimensi yang paling penting dalam skala miliaran: kinerja pencarian, konsumsi memori, dan penggunaan disk.
Secara khusus, kami memeriksa bagaimana AISAQ berperilaku ketika jumlah data PQ yang di-inline-kan (INLINE_PQ) berubah. Parameter ini secara langsung mengontrol pertukaran antara ukuran indeks, I/O disk, dan efisiensi runtime. Kami juga mengevaluasi kedua pendekatan pada beban kerja vektor berdimensi rendah dan tinggi, karena dimensi sangat mempengaruhi biaya komputasi jarak dan kebutuhan penyimpanan.
Pengaturan
Semua eksperimen dilakukan pada sistem node tunggal untuk mengisolasi perilaku indeks dan menghindari gangguan dari jaringan atau efek sistem terdistribusi.
Konfigurasi perangkat keras:
CPU: Intel® Xeon® Platinum 8375C CPU @ 2.90GHz
Memori: Kecepatan: 3200 MT/s, Tipe: DDR4, Ukuran: 32 GB
Disk: SSD NVMe 500 GB
Parameter Pembuatan Indeks
{
"max_degree": 48,
"search_list_size": 100,
"inline_pq": 0/12/24/48, // AiSAQ only
"pq_code_budget_gb_ratio": 0.125,
"search_cache_budget_gb_ratio": 0.0,
"build_dram_budget_gb": 32.0
}
Parameter Kueri
{
"k": 100,
"search_list_size": 100,
"beamwidth": 8
}
Metode Pembandingan
Baik DISKANN maupun AISAQ diuji menggunakan Knowhere, mesin pencari vektor sumber terbuka yang digunakan di Milvus. Dua set data digunakan dalam evaluasi ini:
SIFT128D (vektor 1M): tolok ukur 128 dimensi yang terkenal yang biasa digunakan untuk pencarian deskriptor gambar. (Ukuran dataset mentah ≈ 488 MB)
Cohere768D (1M vektor): set penyematan 768 dimensi yang khas untuk pencarian semantik berbasis transformator. (Ukuran set data mentah ≈ 2930 MB)
Kumpulan data ini mencerminkan dua skenario dunia nyata yang berbeda: fitur penglihatan yang ringkas dan penyematan semantik yang besar.
Hasil
Sift128D1M (Vektor Penuh ~ 488MB)
Cohere768D1M (Vektor Penuh ~ 2930MB)
Analisis
Kumpulan Data SIFT128D
Pada dataset SIFT128D, AISAQ dapat menyamai performa DISKANN ketika semua data PQ dibuat sebaris sehingga data yang dibutuhkan setiap node dapat dimasukkan seluruhnya ke dalam satu halaman SSD 4 KB (INLINE_PQ = 48). Dengan konfigurasi ini, setiap informasi yang dibutuhkan selama pencarian akan ditempatkan secara berurutan:
Vektor penuh: 512B
Daftar tetangga: 48 × 4 + 4 = 196B
Kode PQ tetangga: 48 × (512B × 0.125) ≈ 3072B
Total: 3780B
Karena seluruh node muat dalam satu halaman, hanya satu I/O yang diperlukan per akses, dan AISAQ menghindari pembacaan data PQ eksternal secara acak.
Namun, ketika hanya sebagian dari data PQ yang diisikan, kode PQ yang tersisa harus diambil dari tempat lain pada disk. Hal ini memperkenalkan operasi I / O acak tambahan, yang secara tajam meningkatkan permintaan IOPS dan menyebabkan penurunan kinerja yang signifikan.
Kumpulan Data Cohere768D
Pada dataset Cohere768D, AISAQ berkinerja lebih buruk daripada DISKANN. Alasannya adalah vektor 768 dimensi tidak muat dalam satu halaman SSD 4 KB:
Vektor penuh: 3072B
Daftar tetangga: 48 × 4 + 4 = 196B
Kode PQ tetangga: 48 × (3072B × 0,125) ≈ 18432B
Total: 21.700 B (≈ 6 halaman)
Dalam kasus ini, meskipun semua kode PQ sebaris, setiap simpul mencakup beberapa halaman. Meskipun jumlah operasi I/O tetap konsisten, namun setiap I/O harus mentransfer lebih banyak data, sehingga menghabiskan bandwidth SSD lebih cepat. Setelah bandwidth menjadi faktor pembatas, AISAQ tidak dapat mengimbangi DISKANN-terutama pada beban kerja berdimensi tinggi di mana jejak data per node tumbuh dengan cepat.
Catatan:
Tata letak penyimpanan AISAQ biasanya meningkatkan ukuran indeks pada disk sebesar 4× hingga 6×. Hal ini merupakan pertukaran yang disengaja: vektor penuh, daftar tetangga, dan kode PQ ditempatkan di disk untuk memungkinkan akses satu halaman yang efisien selama pencarian. Meskipun hal ini meningkatkan penggunaan SSD, kapasitas disk secara signifikan lebih murah daripada DRAM dan lebih mudah diukur pada volume data yang besar.
Pada praktiknya, pengguna dapat menyesuaikan keseimbangan ini dengan menyesuaikan rasio kompresi INLINE_PQ dan PQ. Parameter ini memungkinkan untuk menyeimbangkan kinerja pencarian, jejak disk, dan biaya sistem secara keseluruhan berdasarkan kebutuhan beban kerja, daripada dibatasi oleh batas memori tetap.
Kesimpulan
Ekonomi perangkat keras modern sedang berubah. Harga DRAM tetap tinggi, sementara performa SSD telah berkembang pesat - drive PCIe 5.0 sekarang memberikan bandwidth melebihi 14 GB/s. Hasilnya, arsitektur yang mengalihkan data penting untuk pencarian dari DRAM yang mahal ke penyimpanan SSD yang jauh lebih terjangkau menjadi semakin menarik. Dengan kapasitas SSD yang harganya kurang dari 30 kali lipat per gigabyte dibandingkan dengan DRAM, perbedaan ini tidak lagi bersifat marjinal - perbedaan ini sangat berpengaruh pada desain sistem.
AISAQ mencerminkan pergeseran ini. Dengan menghilangkan kebutuhan akan alokasi memori yang besar dan selalu aktif, AISAQ memungkinkan sistem pencarian vektor untuk menskalakan berdasarkan ukuran data dan kebutuhan beban kerja, bukan batas DRAM. Pendekatan ini selaras dengan tren yang lebih luas terhadap arsitektur "all-in-storage", di mana SSD cepat memainkan peran utama tidak hanya dalam persistensi, tetapi juga dalam komputasi dan pencarian aktif. Dengan menawarkan dua mode operasi - Performa dan Skala - AiSAQ memenuhi persyaratan pencarian semantik (yang membutuhkan latensi terendah) dan RAG (yang membutuhkan skala yang sangat tinggi, tetapi latensi sedang).
Pergeseran ini sepertinya tidak akan terbatas pada database vektor. Pola desain yang serupa sudah muncul dalam pemrosesan grafik, analitik deret waktu, dan bahkan bagian dari sistem relasional tradisional, karena para pengembang memikirkan kembali asumsi lama tentang di mana data harus berada untuk mencapai kinerja yang dapat diterima. Karena ekonomi perangkat keras terus berkembang, arsitektur sistem akan mengikuti.
Untuk detail lebih lanjut tentang desain yang dibahas di sini, lihat dokumentasinya:
Ada pertanyaan atau ingin mendalami fitur-fitur Milvus terbaru? 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.
Pelajari Lebih Lanjut tentang Fitur Milvus 2.6
Memperkenalkan Milvus 2.6: Pencarian Vektor yang Terjangkau dalam Skala Miliaran
Penghancuran JSON di Milvus: Pemfilteran JSON 88,9x Lebih Cepat dengan Fleksibilitas
MinHash LSH di Milvus: Senjata Rahasia untuk Memerangi Duplikat dalam Data Pelatihan LLM
Kami Mengganti Kafka/Pulsar dengan Burung Pelatuk untuk Milvus
Pencarian Vektor di Dunia Nyata: Cara Memfilter Secara Efisien Tanpa Membunuh Recall
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word



