Vector, PostgreSQL का नया JSON है

• Vector एक अच्छी तरह से अध्ययन की गई गणितीय संरचना है, और JSON एक data exchange format है
• लेकिन data storage और retrieval की दुनिया में, डेटा को व्यक्त करने के ये दोनों तरीके एक common language बन चुके हैं, और आधुनिक application development में जल्द ही अनिवार्य तत्व बन सकते हैं
• अगर मौजूदा रुझान जारी रहे, तो application बनाने में Vector भी JSON जितना महत्वपूर्ण हो जाएगा
• generative AI के परिणामों को store और query करने के लिए PostgreSQL एक स्वाभाविक विकल्प बना
• लेकिन यह कोई नया data pattern नहीं है। गणितीय अवधारणा के रूप में vector सैकड़ों वर्षों से मौजूद है
• Vector की बुनियादी data structure, array, ज़्यादातर computer science के शुरुआती पाठ्यक्रमों में पढ़ाई जाती है। PostgreSQL भी 20 से अधिक वर्षों से Vector operations को support करता आया है
• तो नया क्या है? नया है इन AI/ML algorithms की "accessibility" और कुछ "real-world" संरचनाओं (text, image, video) को vector के रूप में दर्शाना, और बाद में उन्हें applications में कितनी "आसानी से" इस्तेमाल किया जा सकता है
• साथ ही, इन systems के output ("embedding") को data store में रखना भी पूरी तरह नया नहीं कहा जा सकता, लेकिन नया pattern यह है कि ऐसे data को लगभग real time में सभी applications से query करके वापस लाने की "accessibility"
• तो इसका PostgreSQL से क्या संबंध है?
  • data types को efficiently store और search करने के common patterns ने app development को काफ़ी सरल बनाया, और लोगों को data को एक ही जगह store करके मौजूदा tools के साथ काम करने में सक्षम किया
  • हमने 10 साल पहले JSON के साथ यह देखा था, और अब वही pattern vector data के साथ देख रहे हैं

PostgreSQL में JSON का संक्षिप्त इतिहास

(मूल लेख देखें)

Vector का उभार: "JSON का एक नया प्रकार"

• इन दिनों इसकी लोकप्रियता तेज़ी से बढ़ रही है
• एक सामान्य use case यह है कि stored data पर model बनाया जाए, उसे vector format में बदला जाए, और फिर उसे "semantic search" के लिए इस्तेमाल किया जाए
  • इस मामले में, search में आने वाले नए input को vector format में बदलकर database में सबसे समान चीज़ खोजी जाती है
  • similarity को Euclidean/Cosine distance जैसी distance functions से मापा जाता है, और परिणाम अक्सर k-NN (Nearest Neighbors) या सबसे समान k objects तक सीमित होते हैं
  • क्योंकि vector के training set को encode करने में बहुत समय लग सकता है, इसलिए उसे DB जैसी जगह में cache करना और वहीं से k-NN query चलाना बेहतर होता है
  • semantic search के लिए query करने को तैयार vectors का एक सेट होना आम तौर पर users को बेहतर अनुभव देता है, इसलिए "vector database" की आवश्यकता उभरी
• Vector storage PostgreSQL के लिए नया नहीं है
  • वास्तव में, यह नाम थोड़ा भ्रामक है, क्योंकि PostgreSQL कई dimensions वाले data (जैसे matrix) को store कर सकता है
  • मूल रूप से PostgreSQL के arrays में vectors के लिए सीमित functionality होती है, जैसे दो arrays के बीच "distance" की गणना
  • stored procedures लिखी जा सकती हैं, लेकिन इससे developers को कुछ अतिरिक्त काम करना पड़ता है
• सौभाग्य से, cube data type इन सीमाओं को पार करता है
  • cube 20 से अधिक वर्षों से इस्तेमाल में है, और इसे high-dimensional vectors पर operations करने के लिए डिज़ाइन किया गया है
  • cube में Euclidean distance सहित vector similarity search में इस्तेमाल होने वाली ज़्यादातर सामान्य distance functions शामिल हैं
  • GiST index का उपयोग करके efficient K-NN queries भी चलाई जा सकती हैं
  • लेकिन cube केवल 100 dimensions तक के vectors store कर सकता है, जबकि आधुनिक AI/ML systems इससे अधिक dimensions की मांग करते हैं

pgvector: PostgreSQL में vectors को store और search करने के लिए open source extension

• pgvector का उपयोग करके vectors को store किया जा सकता है और विभिन्न distance metrics (Euclidean, Cosine, inner product आदि) के साथ k-NN queries चलाई जा सकती हैं
• वर्तमान में pgvector vector indexing के IVR FLAT method को implement करने वाले एक index ivfflat के साथ आता है
• indexed vector data को query करना सामान्य data को query करने से अलग हो सकता है
• high-dimensional vectors में nearest neighbor search की लागत के कारण, कई vector indexing methods exact answer के बजाय "काफ़ी करीब" का "approximate" answer ढूंढते हैं
• इससे "ANN (Approximate Nearest Neighbor)" search का क्षेत्र विकसित हुआ
• ANN queries के बारे में लोग आम तौर पर दो आयामों को देखते हैं: performance और "recall" (वापस आने वाले relevant results का प्रतिशत) के बीच संतुलन
  • ivfflat के उदाहरण में, ivfflat index बनाते समय यह तय किया जाता है कि उसमें कितनी lists शामिल होंगी
  • हर list एक "center" का प्रतिनिधित्व करती है, और ये centers k-means algorithm से निकाले जाते हैं
  • सभी centers तय हो जाने पर, ivfflat यह निर्धारित करता है कि हर vector किस center के सबसे करीब है और उसे index में जोड़ देता है
  • जब vector data को query करने का समय आता है, तो ivfflat.probes variable के आधार पर यह तय होता है कि कितने centers को check करना है
  • यहीं ANN का performance/recall trade-off दिखाई देता है। जितने अधिक centers पर जाया जाएगा, परिणाम उतने अधिक सटीक होंगे, लेकिन performance घटेगी

PostgreSQL में vectors के बेहतर समर्थन के लिए अगले कदम

• जैसे PostgreSQL 9.2 के समय JSON type के आधिकारिक समर्थन की शुरुआत हुई थी, वैसे ही हम अभी PostgreSQL में vector data store करने के शुरुआती चरण में हैं
• PostgreSQL और pgvector पहले से ही अच्छे हैं, लेकिन वे और भी बेहतर होंगे
• pgvector पहले से सामान्य AI/ML data use cases को संभाल सकता है। कई users इसे पहले ही deploy करके इस्तेमाल कर रहे हैं
• अगला कदम इसे बेहतर और विस्तारित करने में मदद करना है, और उसका ज़्यादातर काम पहले से चल रहा है
  • और अधिक parallelization जोड़ना
  • 2,000 से अधिक dimensions वाले vectors के लिए support
  • computation speed बढ़ाने के लिए hardware acceleration का उपयोग
• PostgreSQL को vector "database" के रूप में उपयोग करने को लेकर काफ़ी उम्मीदें हैं
• जैसा कि JSON के इतिहास से दिखता है, PostgreSQL community इसे scalable और safe तरीके से support करने का रास्ता खोज लेगी

[atempest]

बहुउपयोगिता तो ज़्यादा होगी, लेकिन आखिरकार असली बात स्पीड की ही नहीं होगी क्या?
लगता है कि यह शुद्ध vector DBs की तुलना में काफ़ी धीमा होगा, शायद इतना कि देखना भी मुश्किल लगे....

[nicewook]

Pinecone जैसे vector database मौजूद होने पर PostgreSQL को लेकर इतनी उम्मीद क्यों है, यह जानने की उत्सुकता है. @@

[tkwlsrl]

मेरे अनुभव में PostgreSQL सबसे ज़्यादा सुलभ था.

Pinecone, ChromaDB या Weaviate जैसी चीज़ें इस्तेमाल करते समय हर database को इस्तेमाल करने लायक कोई standardized तरीका नहीं था.

यानी हर database के लिए अलग SDK इस्तेमाल करना पड़ता था, and उनका इस्तेमाल करने का तरीका भी अलग था, इसलिए हर database के लिए कोड फिर से लिखना पड़ता था. साथ ही, official SDK जिन भाषाओं को support करते थे वे भी सीमित थीं, इसलिए कभी-कभी भाषा भी बदलनी पड़ती थी.

बेशक PostgreSQL में vector इस्तेमाल करने पर भी स्थिति कुछ ऐसी ही होती है, लेकिन कम से कम मौजूदा SQL syntax में थोड़ा-सा अतिरिक्त ज्ञान जोड़ना ही काफी था, इसलिए शुरुआत करना आसान था.

अभी vector databases की speed की तुलना करें तो PostgreSQL काफ़ी धीमे पक्ष में है. उम्मीद है जल्द थोड़ा upgrade हो जाए. haha

[xguru]

शायद बात इतनी ही है कि “अगर सब कुछ support करने वाला सिर्फ़ एक DB install/manage करना पड़े तो सुविधाजनक होता है” + “दूसरे features के साथ integration भी आसान होता है।”
इंस्टेंस बढ़ते जाते हैं तो यह धीरे-धीरे काफ़ी झंझट भरा हो जाता है..

[nicewook]

आह, समझ गया।
Redis भी तरह-तरह की चीजें जोड़ता है, शायद उसी वजह से। हाँ, सही है।

[iolothebard]

शुरू, बीच, अंत...टेंसर...

[xguru]

लेखक Jonathan Katz, PostgreSQL Core Team के सदस्य हैं।