Fitur AISearch di PolarDB for MySQL mengintegrasikan similarity search vektor ke dalam kernel database. Selain menyimpan dan memproses data terstruktur, Anda juga dapat melakukan similarity search yang efisien pada vektor yang dihasilkan dari data tidak terstruktur, seperti teks, gambar, dan audio. Anda dapat membangun aplikasi AI—seperti pencarian semantik, rekomendasi cerdas, dan image search—dalam kluster PolarDB tanpa perlu membangun dan mengelola database vektor terpisah atau pipeline data synchronization yang kompleks. PolarDB menyediakan dua protokol pencarian vektor untuk menyesuaikan berbagai tumpukan teknologi dan skenario bisnis: protokol yang sepenuhnya kompatibel dengan MySQL serta protokol OpenSearch (PolarSearch) yang kompatibel dengan ekosistem pencarian utama.
Konsep inti
Vector embedding: Teknik yang mengubah data tidak terstruktur, seperti teks dan gambar, menjadi array numerik (vektor) menggunakan model embedding yang telah dipre-train. Vektor ini menangkap informasi semantik mendalam dari data, sehingga mesin dapat memahami dan membandingkan kemiripannya.
Similarity search (k-NN): Juga dikenal sebagai pencarian k-nearest neighbor. Tujuan utamanya adalah menemukan k vektor dalam dataset besar yang paling "dekat" dengan vektor kueri tertentu. Dalam konteks ini, "jarak" dihitung menggunakan berbagai rumus matematis dan merepresentasikan kemiripan semantik antar titik data.
Vector index: Vector index dibuat untuk menghindari pemindaian penuh pada dataset besar. Indeks merupakan struktur data yang dioptimalkan untuk kueri efisien. Indeks ini mempersempit ruang pencarian berdasarkan distribusi vektor, sehingga mengurangi latency pencarian dari hitungan detik menjadi milidetik sekaligus memastikan recall rate yang tinggi.
Perbandingan algoritma vector index: PolarDB mendukung beberapa algoritma vector index utama. Dua yang paling umum adalah HNSW dan IVF, masing-masing memiliki pertimbangan antara performa, konsumsi sumber daya, dan skenario penggunaan.
HNSW (Hierarchical Navigable Small World): Indeks berbasis graf yang memberikan performa tinggi dan recall rate tinggi, tetapi memiliki overhead memori yang signifikan. Cocok untuk skenario yang memerlukan latency kueri sangat rendah dan presisi tinggi, dengan asumsi dataset muat dalam memori yang tersedia.
IVF (Inverted File): inverted index berbasis kluster dengan konsumsi memori lebih rendah, sehingga cocok untuk dataset sangat besar dalam kondisi memori terbatas. Namun, presisi pencariannya biasanya sedikit lebih rendah dibandingkan HNSW.
Keunggulan utama
PolarDB vector engine menggabungkan kesederhanaan database relasional dengan performa tinggi database vektor khusus, memberikan keunggulan signifikan dibandingkan opsi teknologi lainnya.
Fitur | Database relasional tradisional | Dedicated vector database | PolarDB vector engine |
SQL support | Didukung | Tidak didukung | Didukung |
Vector search | Performa buruk | Performa tinggi | Performa tinggi |
Learning curve | Rendah | Tinggi | Rendah |
Ecosystem compatibility | Kaya | Terbatas | Dual-ecosystem |
Scalability | Terbatas | Baik | Sangat baik |
Operational complexity | Sederhana | Kompleks | Sederhana |
Selain itu, fitur ini juga menawarkan keunggulan inti berikut:
Solusi all-in-one: Proses data bisnis dan data vektor dalam PolarDB tanpa perlu database vektor terpisah. Hal ini menyederhanakan arsitektur sistem dan mengurangi biaya operasional.
Keandalan tingkat enterprise: Mendukung penuh ACID transactions untuk memastikan konsistensi data. Arsitektur terdistribusinya menyediakan high availability dan automatic switchover guna menjamin kelangsungan bisnis.
Integrasi erat dengan LLM: Kemampuan inferensi bawaan untuk Qwen large language model (LLM) menyederhanakan pipeline pengembangan aplikasi AI.
Kemampuan inti dan metrik performa
Performa pencarian
Latency: P99 (99% permintaan) < 10 ms, P95 (95% permintaan) < 5 ms.
Throughput: > 10.000 QPS per node.
Akurasi: recall rate > 99%.
Skalabilitas
Skala data: Mendukung data vektor dalam skala petabyte dan similarity search pada miliaran vektor.
Konkurensi: Menangani puluhan ribu kueri konkuren.
Skala kluster: Mendukung scale-out dinamis hingga ratusan node dengan strategi data sharding cerdas.
Efisiensi sumber daya
Kompresi penyimpanan: Rasio kompresi data vektor > 50%.
Penggunaan memori: Secara efektif mendukung indeks graf skala terabyte melalui teknologi caching berlapis.
Pemanfaatan CPU: CPU utilization > 80% dengan optimisasi parallel computing multi-core.
Kasus penggunaan
PolarDB menyediakan desain dual-protokol. Anda dapat memilih protokol yang paling sesuai dengan tumpukan teknologi tim, kebutuhan bisnis, dan ekspektasi performa Anda.
Perbandingan | Protokol MySQL | Protokol OpenSearch |
Metode akses | Standard SQL | RESTful API (kompatibel dengan Elasticsearch/OpenSearch) |
Keunggulan utama | Terintegrasi dengan data bisnis, mendukung penambahan kolom vektor ke tabel yang sudah ada, mendukung ACID transactions, dan memiliki learning curve rendah. | Menawarkan kemampuan hybrid search yang mendukung kueri gabungan antara vektor, full-text, dan data skalar dalam ekosistem yang matang. |
Ketergantungan dasar | Mengandalkan In-Memory Column Index (IMCI). Pencarian vektor dijalankan pada IMCI read-only node untuk mengisolasi beban kerja analitikal dan transaksional. | Berjalan pada search node (PolarSearch) khusus, menyediakan layanan seperti mesin pencari. |
Data synchronization | Tidak diperlukan. Data yang ditulis ke node primary secara otomatis terlihat oleh IMCI read-only node. | Tidak diperlukan. Data yang ditulis ke node primary secara otomatis terlihat oleh search node. |
Q&A cerdas dan bot layanan pelanggan
Permasalahan bisnis: Pencocokan kata kunci tradisional sering gagal memahami maksud pengguna, sehingga menghasilkan jawaban yang tidak akurat.
Solusi: Ubah pasangan pertanyaan-jawaban dari basis pengetahuan Anda menjadi vektor dan simpan. Saat pengguna mengajukan pertanyaan, ubah menjadi vektor kueri dan gunakan similarity search untuk menemukan poin pengetahuan paling relevan serta memberikan jawaban yang lebih akurat.
Rekomendasi protokol:
Protokol MySQL: Jika Anda hanya memerlukan pencocokan semantik dasar dan ingin mengintegrasikannya dengan cepat ke aplikasi MySQL yang sudah ada, protokol ini merupakan pilihan yang praktis.
Protokol OpenSearch: Jika Anda perlu menggabungkan kata kunci, label kategori, atau kriteria lain untuk filtering kompleks, kemampuan hybrid search protokol ini sangat ideal.
Sistem rekomendasi personalisasi
Permasalahan bisnis: Merekomendasikan produk atau konten yang relevan berdasarkan perilaku historis pengguna, seperti tayangan, klik, dan pembelian.
Solusi: Representasikan pengguna dan item (seperti produk, artikel, dan video) sebagai vektor. Dengan menghitung kemiripan antara vektor pengguna dan vektor item, Anda dapat mengambil set kandidat item yang mungkin diminati pengguna. Set ini kemudian dapat disempurnakan menggunakan strategi peringkat lainnya.
Rekomendasi protokol:
Protokol OpenSearch: Lapisan pengambilan (retrieval) sistem rekomendasi sering kali menangani volume data sangat besar dan sensitif terhadap performa serta biaya. Indeks IVF dan teknologi Product Quantization (PQ) yang disediakan oleh protokol OpenSearch sangat cocok untuk menangani dataset besar sekaligus mengontrol biaya memori.
Pencarian gambar dan pengambilan multimodal
Permasalahan bisnis: Menemukan gambar serupa dengan mengunggah contoh gambar, atau mencari gambar menggunakan deskripsi teks.
Solusi: Ubah gambar dan teks menjadi vektor dan simpan dalam PolarDB. Baik input berupa gambar maupun teks, keduanya diubah menjadi vektor kueri untuk melakukan similarity search di database.
Rekomendasi protokol:
Protokol MySQL: Untuk skenario yang memerlukan konsistensi kuat antara vektor fitur gambar dan data bisnis seperti ID produk dan harga, kemampuan transaksional protokol MySQL menjadi perlindungan penting.