Vector adalah JSON baru bagi PostgreSQL

xguru · 2023-06-28T11:05:01+09:00

Vektor adalah struktur matematika yang telah diteliti dengan baik, sedangkan JSON adalah format pertukaran data Namun di dunia penyimpanan dan pencarian data, kedua cara merepresentasikan data ini telah menjadi bahasa bersama, dan akan segera menjadi elemen penting dalam pengembangan aplikasi modern Jika tren saat ini berlanjut, vektor juga akan menjadi sama pentingnya dengan JSON dalam membangun aplikasi PostgreSQL secara alami menjadi pilihan untuk menyimpan dan melakukan kueri atas hasil dari AI generatif Namun ini bukan pola data yang benar-benar baru. Vektor sebagai konsep matematika telah ada selama ratusan tahun Array, struktur data dasar dari vektor, diajarkan di sebagian besar mata kuliah pengantar ilmu komputer. PostgreSQL juga telah mendukung operasi vektor selama lebih dari 20 tahun Jadi apa yang baru? Yang baru adalah seberapa "mudah diakses" algoritme AI/ML ini, dan seberapa "mudah" struktur tertentu di "dunia nyata" (teks, gambar, video) dapat direpresentasikan sebagai vektor lalu digunakan kemudian dalam aplikasi Selain itu, menyimpan keluaran dari sistem semacam ini ("embedding") di penyimpanan data juga bisa dibilang bukan hal baru, tetapi pola yang baru adalah "aksesibilitas" untuk melakukan kueri dan mengembalikan data ini di hampir semua aplikasi secara nyaris real-time Lalu apa hubungannya dengan PostgreSQL? Pola umum untuk menyimpan dan mengambil tipe data secara efisien sangat menyederhanakan pengembangan aplikasi, serta memungkinkan orang menyimpan data di ruang yang sama dan bekerja dengannya menggunakan alat yang sudah ada Kita telah melihat ini dengan JSON 10 tahun lalu, dan sekarang sedang melihat pola yang sama pada data vektor Sejarah singkat JSON di PostgreSQL (lihat artikel asli) Kebangkitan vektor, "jenis JSON yang baru" Popularitasnya sedang melonjak akhir-akhir ini Kasus penggunaan yang umum adalah membangun model dari data yang tersimpan lalu mengubahnya ke format vektor, kemudian memakainya untuk "pencarian semantik" Dalam kasus ini, input baru yang masuk untuk pencarian diubah ke format vektor, lalu database mencari yang paling mirip Kemiripan diukur menggunakan fungsi jarak seperti Euclidean/cosine, dan hasilnya sering dibatasi pada k-NN (Nearest Neighbors) atau k entitas yang paling mirip Karena pengodean set pelatihan vektor bisa memakan banyak waktu, lebih baik menyimpannya di tempat seperti DB dan menjalankan kueri k-NN di sana Memiliki sekumpulan vektor yang siap dikueri untuk pencarian semantik biasanya memberi pengalaman yang lebih baik bagi pengguna, sehingga kebutuhan akan "database vektor" pun muncul Penyimpanan vektor bukan hal baru di PostgreSQL Sebenarnya, ini sedikit salah penamaan karena PostgreSQL dapat menyimpan data multidimensi (misalnya matrix) Secara bawaan, array di PostgreSQL memang memiliki dukungan terbatas untuk vektor, seperti menghitung "jarak" antara dua array Anda bisa menulis stored procedure, tetapi itu menambah pekerjaan bagi pengembang Untungnya, tipe data cube mengatasi keterbatasan ini cube telah digunakan selama lebih dari 20 tahun, dan dirancang agar bisa melakukan operasi pada vektor berdimensi tinggi cube mencakup sebagian besar fungsi jarak umum yang digunakan untuk pencarian kemiripan vektor, termasuk jarak Euclidean Kueri K-NN yang efisien juga dapat dijalankan menggunakan indeks GiST Namun cube hanya dapat menyimpan vektor hingga 100 dimensi, sementara sistem AI/ML modern membutuhkan dimensi yang lebih tinggi pgvector: ekstensi open source untuk menyimpan dan mencari vektor di PostgreSQL Dengan pgvector, Anda dapat menyimpan vektor dan menjalankan kueri k-NN dengan berbagai metrik jarak (Euclidean, cosine, inner product, dan lainnya) Saat ini pgvector menyediakan satu indeks, ivfflat, yang mengimplementasikan metode IVR FLAT untuk pengindeksan vektor Melakukan kueri terhadap data vektor yang telah diindeks bisa berbeda dari melakukan kueri terhadap data biasa Karena mahalnya biaya pencarian nearest neighbor pada vektor berdimensi tinggi, banyak metode pengindeksan vektor mencari jawaban "aproksimasi" yang "cukup dekat" dengan jawaban sebenarnya Ini mengarah pada bidang pencarian "ANN (Approximate Nearest Neighbor)" Dua dimensi yang biasanya diperhatikan orang dalam kueri ANN adalah keseimbangan antara performa dan "recall" (persentase hasil relevan yang dikembalikan) Mengambil contoh ivfflat, saat membuat indeks ivfflat kita menentukan berapa banyak list yang akan disertakan Setiap list merepresentasikan sebuah "pusat", dan pusat ini dihitung dengan algoritme k-means Setelah semua pusat ditentukan, ivfflat menentukan pusat terdekat untuk tiap vektor lalu menambahkannya ke indeks Saat waktunya melakukan kueri terhadap data vektor, jumlah pusat yang diperiksa ditentukan berdasarkan variabel ivfflat.probes Di sinilah kita melihat tradeoff performa/recall pada ANN. Semakin banyak pusat yang dikunjungi, semakin akurat hasilnya, tetapi performa menurun Langkah berikutnya untuk dukungan vektor yang lebih baik di PostgreSQL Seperti saat PostgreSQL 9.2 mulai secara resmi mendukung tipe JSON, kita masih berada pada tahap awal dalam cara menyimpan data vektor di PostgreSQL PostgreSQL dan pgvector sudah bagus sekarang, tetapi akan menjadi jauh lebih baik pgvector sudah mampu menangani kasus data AI/ML yang umum. Banyak pengguna sudah menerapkannya dalam produksi Langkah berikutnya adalah membantu peningkatan dan perluasan, dan sebagian besar sudah sedang berlangsung Menambahkan lebih banyak paralelisasi Dukungan untuk vektor dengan lebih dari 2.000 dimensi Memanfaatkan akselerasi perangkat keras untuk meningkatkan kecepatan komputasi Ada banyak antusiasme terhadap penggunaan PostgreSQL sebagai "database" vektor Seperti yang bisa dilihat dari sejarah JSON, komunitas PostgreSQL akan menemukan cara untuk mendukungnya dengan pendekatan yang dapat diperluas dan aman

(jkatz05.com)

26 poin oleh xguru 2023-06-28 | 7 komentar | Bagikan ke WhatsApp

Vektor adalah struktur matematika yang telah diteliti dengan baik, sedangkan JSON adalah format pertukaran data
Namun di dunia penyimpanan dan pencarian data, kedua cara merepresentasikan data ini telah menjadi bahasa bersama, dan akan segera menjadi elemen penting dalam pengembangan aplikasi modern
Jika tren saat ini berlanjut, vektor juga akan menjadi sama pentingnya dengan JSON dalam membangun aplikasi
PostgreSQL secara alami menjadi pilihan untuk menyimpan dan melakukan kueri atas hasil dari AI generatif
Namun ini bukan pola data yang benar-benar baru. Vektor sebagai konsep matematika telah ada selama ratusan tahun
Array, struktur data dasar dari vektor, diajarkan di sebagian besar mata kuliah pengantar ilmu komputer. PostgreSQL juga telah mendukung operasi vektor selama lebih dari 20 tahun
Jadi apa yang baru? Yang baru adalah seberapa "mudah diakses" algoritme AI/ML ini, dan seberapa "mudah" struktur tertentu di "dunia nyata" (teks, gambar, video) dapat direpresentasikan sebagai vektor lalu digunakan kemudian dalam aplikasi
Selain itu, menyimpan keluaran dari sistem semacam ini ("embedding") di penyimpanan data juga bisa dibilang bukan hal baru, tetapi pola yang baru adalah "aksesibilitas" untuk melakukan kueri dan mengembalikan data ini di hampir semua aplikasi secara nyaris real-time
Lalu apa hubungannya dengan PostgreSQL?
- Pola umum untuk menyimpan dan mengambil tipe data secara efisien sangat menyederhanakan pengembangan aplikasi, serta memungkinkan orang menyimpan data di ruang yang sama dan bekerja dengannya menggunakan alat yang sudah ada
- Kita telah melihat ini dengan JSON 10 tahun lalu, dan sekarang sedang melihat pola yang sama pada data vektor

Sejarah singkat JSON di PostgreSQL

(lihat artikel asli)

Kebangkitan vektor, "jenis JSON yang baru"

Popularitasnya sedang melonjak akhir-akhir ini
Kasus penggunaan yang umum adalah membangun model dari data yang tersimpan lalu mengubahnya ke format vektor, kemudian memakainya untuk "pencarian semantik"
- Dalam kasus ini, input baru yang masuk untuk pencarian diubah ke format vektor, lalu database mencari yang paling mirip
- Kemiripan diukur menggunakan fungsi jarak seperti Euclidean/cosine, dan hasilnya sering dibatasi pada k-NN (Nearest Neighbors) atau k entitas yang paling mirip
- Karena pengodean set pelatihan vektor bisa memakan banyak waktu, lebih baik menyimpannya di tempat seperti DB dan menjalankan kueri k-NN di sana
- Memiliki sekumpulan vektor yang siap dikueri untuk pencarian semantik biasanya memberi pengalaman yang lebih baik bagi pengguna, sehingga kebutuhan akan "database vektor" pun muncul
Penyimpanan vektor bukan hal baru di PostgreSQL
- Sebenarnya, ini sedikit salah penamaan karena PostgreSQL dapat menyimpan data multidimensi (misalnya matrix)
- Secara bawaan, array di PostgreSQL memang memiliki dukungan terbatas untuk vektor, seperti menghitung "jarak" antara dua array
- Anda bisa menulis stored procedure, tetapi itu menambah pekerjaan bagi pengembang
Untungnya, tipe data cube mengatasi keterbatasan ini
- cube telah digunakan selama lebih dari 20 tahun, dan dirancang agar bisa melakukan operasi pada vektor berdimensi tinggi
- cube mencakup sebagian besar fungsi jarak umum yang digunakan untuk pencarian kemiripan vektor, termasuk jarak Euclidean
- Kueri K-NN yang efisien juga dapat dijalankan menggunakan indeks GiST
- Namun cube hanya dapat menyimpan vektor hingga 100 dimensi, sementara sistem AI/ML modern membutuhkan dimensi yang lebih tinggi

pgvector: ekstensi open source untuk menyimpan dan mencari vektor di PostgreSQL

Dengan pgvector, Anda dapat menyimpan vektor dan menjalankan kueri k-NN dengan berbagai metrik jarak (Euclidean, cosine, inner product, dan lainnya)
Saat ini pgvector menyediakan satu indeks, ivfflat, yang mengimplementasikan metode IVR FLAT untuk pengindeksan vektor
Melakukan kueri terhadap data vektor yang telah diindeks bisa berbeda dari melakukan kueri terhadap data biasa
Karena mahalnya biaya pencarian nearest neighbor pada vektor berdimensi tinggi, banyak metode pengindeksan vektor mencari jawaban "aproksimasi" yang "cukup dekat" dengan jawaban sebenarnya
Ini mengarah pada bidang pencarian "ANN (Approximate Nearest Neighbor)"
Dua dimensi yang biasanya diperhatikan orang dalam kueri ANN adalah keseimbangan antara performa dan "recall" (persentase hasil relevan yang dikembalikan)
- Mengambil contoh ivfflat, saat membuat indeks ivfflat kita menentukan berapa banyak list yang akan disertakan
- Setiap list merepresentasikan sebuah "pusat", dan pusat ini dihitung dengan algoritme k-means
- Setelah semua pusat ditentukan, ivfflat menentukan pusat terdekat untuk tiap vektor lalu menambahkannya ke indeks
- Saat waktunya melakukan kueri terhadap data vektor, jumlah pusat yang diperiksa ditentukan berdasarkan variabel ivfflat.probes
- Di sinilah kita melihat tradeoff performa/recall pada ANN. Semakin banyak pusat yang dikunjungi, semakin akurat hasilnya, tetapi performa menurun

Langkah berikutnya untuk dukungan vektor yang lebih baik di PostgreSQL

Seperti saat PostgreSQL 9.2 mulai secara resmi mendukung tipe JSON, kita masih berada pada tahap awal dalam cara menyimpan data vektor di PostgreSQL
PostgreSQL dan pgvector sudah bagus sekarang, tetapi akan menjadi jauh lebih baik
pgvector sudah mampu menangani kasus data AI/ML yang umum. Banyak pengguna sudah menerapkannya dalam produksi
Langkah berikutnya adalah membantu peningkatan dan perluasan, dan sebagian besar sudah sedang berlangsung
- Menambahkan lebih banyak paralelisasi
- Dukungan untuk vektor dengan lebih dari 2.000 dimensi
- Memanfaatkan akselerasi perangkat keras untuk meningkatkan kecepatan komputasi
Ada banyak antusiasme terhadap penggunaan PostgreSQL sebagai "database" vektor
Seperti yang bisa dilihat dari sejarah JSON, komunitas PostgreSQL akan menemukan cara untuk mendukungnya dengan pendekatan yang dapat diperluas dan aman

7 komentar

atempest 2025-05-07

Meskipun fleksibilitasnya tinggi, pada akhirnya bukankah yang jadi penentu adalah kecepatannya?
Dibandingkan vector DB murni, sepertinya bakal lambat sampai-sampai sulit ditoleransi....

nicewook 2023-06-28

Saya penasaran mengapa ada ekspektasi terhadap PostgreSQL ketika sudah ada database vektor seperti Pinecone. @@

tkwlsrl 2023-06-28

Menurut pengalaman saya, PostgreSQL adalah yang paling mudah diakses.

Saat menggunakan Pinecone, ChromaDB, atau Weaviate, tidak ada standardisasi agar tiap database bisa digunakan dengan cara yang sama.

Artinya, saya harus memakai SDK yang berbeda untuk tiap database, dan cara penggunaannya juga berbeda, jadi kodenya harus dibuat ulang untuk masing-masing database. Selain itu, bahasa yang didukung oleh SDK resmi juga terbatas, sehingga kadang saya harus mengganti bahasa pemrograman.

Tentu saja, saat mencoba menggunakan vektor di PostgreSQL, situasinya agak mirip, tetapi setidaknya cukup menambah sedikit pengetahuan di atas sintaks SQL yang sudah ada, jadi lebih mudah untuk mulai menggunakannya.

Saat ini, kalau membandingkan kecepatan vector database, PostgreSQL termasuk yang cukup lambat. Semoga bisa segera di-upgrade. haha

xguru 2023-06-28

Mungkin intinya adalah, "lebih praktis kalau cukup memasang/mengelola satu DB yang semuanya didukung" + "lebih mudah diintegrasikan dengan fitur lain".
Kalau jumlah instance bertambah, lama-lama memang jadi makin merepotkan..

nicewook 2023-06-28

Aha, saya mengerti.
Jadi itu juga alasan Redis menempelkan ini-itu. angguk-angguk

iolothebard 2023-06-28

Dari awal sampai akhir... tensor...