pgvector के लिए PostgreSQL ट्यून करें

  • 15 मिनट्स

वेक्टर खोज वर्कलोड पारंपरिक लेन-देन या विश्लेषणात्मक प्रश्नों की तुलना में PostgreSQL पर अलग-अलग मांगें रखते हैं। इन अंतरों को समझने से आपको कॉन्फ़िगरेशन मापदंडों को ट्यून करने में मदद मिलती है ताकि आप एआई अनुप्रयोगों के लिए क्वेरी विलंबता, मेमोरी उपयोग और गणना दक्षता को अनुकूलित कर सकें।

नोट

इस इकाई में कोड उदाहरण PostgreSQL और pgvector के लिए कॉन्फ़िगरेशन पैटर्न प्रदर्शित करते हैं। दिखाए गए पैरामीटर मान ट्यूनिंग के लिए शुरुआती बिंदु हैं। इष्टतम सेटिंग्स आपके विशिष्ट कार्यभार, डेटासेट आकार और हार्डवेयर पर निर्भर करती हैं। हमेशा एक परीक्षण वातावरण में बेंचमार्क परिवर्तनों को उत्पादन में लागू करने से पहले।

Pgvector गणना और मेमोरी आवश्यकताएँ

वेक्टर समानता खोज में एक क्वेरी वेक्टर और संभावित रूप से लाखों संग्रहीत वैक्टर के बीच की दूरी की गणना शामिल है। यह कम्प्यूटेशनल पैटर्न मूल रूप से पारंपरिक डेटाबेस ऑपरेशन से भिन्न होता है जो अनुक्रमित स्तंभों के आधार पर पंक्तियों को फ़िल्टर करता है या प्रमुख मानों पर तालिकाओं में शामिल होता है।

जब आप एक वेक्टर समानता क्वेरी निष्पादित करते हैं, तो pgvector को आपके क्वेरी वेक्टर और उम्मीदवार वैक्टर के बीच की दूरी की गणना करनी चाहिए। 1536-आयामी एम्बेडिंग (OpenAI मॉडल के साथ आम) के लिए, प्रत्येक दूरी गणना में 1,536 फ्लोटिंग-पॉइंट ऑपरेशन शामिल हैं। एक सूचकांक के बिना एक मिलियन वैक्टर की खोज के लिए प्रति क्वेरी 1.5 बिलियन से अधिक फ्लोटिंग-पॉइंट ऑपरेशन की आवश्यकता होती है। तीन दूरी के कार्यों में अलग-अलग कम्प्यूटेशनल लागतें होती हैं जो आपकी डेटा विशेषताओं और प्रदर्शन आवश्यकताओं के आधार पर आपकी पसंद को प्रभावित करती हैं।

  • L2 (यूक्लिडियन) दूरी: ऑपरेटर का <-> उपयोग करता है और वर्ग अंतरों के योग के वर्गमूल की गणना करता है। यह कम्प्यूटेशनल रूप से सबसे महंगा विकल्प है।
  • कोसाइन दूरी: ऑपरेटर का उपयोग करता <=> है और वैक्टर के बीच के कोण को मापता है। यह वैक्टर को आंतरिक रूप से सामान्य करता है, गणना जोड़ता है लेकिन स्केल-अपरिवर्तनीय समानता प्रदान करता है।
  • आंतरिक उत्पाद: ऑपरेटर का <#> उपयोग करता है और डॉट उत्पाद की गणना करता है। यह सबसे तेज़ ऑपरेशन है लेकिन सार्थक समानता तुलना के लिए पूर्व-सामान्यीकृत वैक्टर की आवश्यकता होती है।

अनुशंसा इंजन और सिमेंटिक खोज के लिए, कोसाइन दूरी को अक्सर पसंद किया जाता है क्योंकि यह लगातार अलग-अलग परिमाण के वैक्टर को संभालता है। यदि आपके एम्बेडिंग पहले से ही सामान्यीकृत हैं (कई एम्बेडिंग एपीआई सामान्यीकृत वैक्टर लौटाते हैं), तो आंतरिक उत्पाद कम गणना के साथ समतुल्य परिणाम प्रदान करता है।

वेक्टर कॉलम पारंपरिक डेटा प्रकारों की तुलना में पर्याप्त भंडारण का उपभोग करते हैं। एक एकल 1536-आयामी वेक्टर (एकल परिशुद्धता) के रूप में float4 संग्रहीत 6,144 बाइट्स, प्लस ओवरहेड की आवश्यकता होती है। एक मिलियन उत्पाद एम्बेडिंग वाली तालिका को केवल वेक्टर कॉलम के लिए लगभग 6 जीबी की आवश्यकता होती है। जब PostgreSQL वेक्टर क्वेरी को संसाधित करता है, तो यह वेक्टर डेटा को मेमोरी में लोड करता है। उपलब्ध स्मृति और वेक्टर डेटा आकार के बीच संबंध सीधे प्रभावित करता है कि क्वेरीज़ स्मृति में कुशलता से निष्पादित कर सकते हैं या डिस्क से बार-बार पढ़ना चाहिए।

उच्च-आयामी एम्बेडिंग अधिक शब्दार्थ रिज़ॉल्यूशन प्रदान करते हैं लेकिन भंडारण और गणना लागत दोनों को द्विघात रूप से बढ़ाते हैं। एक 3072-आयामी वेक्टर (कुछ नए एम्बेडिंग मॉडल द्वारा उपयोग किया जाता है) को दूरी गणना कार्य से चार गुना और 1536-आयामी वेक्टर के दोगुने भंडारण की आवश्यकता होती है। एम्बेडिंग आयाम चुनते समय अपनी सटीकता आवश्यकताओं पर विचार करें। कई अनुशंसा और खोज अनुप्रयोगों के लिए, 768 या 1,024 आयाम सार्थक रूप से कम संसाधन खपत के साथ पर्याप्त गुणवत्ता प्रदान करते हैं।

वेक्टर वर्कलोड के लिए मेमोरी कॉन्फ़िगरेशन

PostgreSQL के मेमोरी पैरामीटर वेक्टर क्वेरी प्रदर्शन को महत्वपूर्ण रूप से प्रभावित करते हैं। उचित ट्यूनिंग सुनिश्चित करती है कि वेक्टर इंडेक्स और अक्सर एक्सेस किए गए डेटा मेमोरी में रहते हैं, जिससे महंगे डिस्क ऑपरेशन कम हो जाते हैं।

shared_buffers पैरामीटर PostgreSQL के साझा मेमोरी कैश को नियंत्रित करता है, जहां अक्सर एक्सेस किए जाने वाले डेटा पेज रहते हैं। वेक्टर वर्कलोड के लिए, यह कैश आपके वेक्टर इंडेक्स और हॉट डेटा को रखने के लिए काफी बड़ा होना चाहिए। वेक्टर-भारी कार्यभार के लिए 99% से नीचे का कैश हिट अनुपात इंगित करता है कि यह shared_buffers बहुत छोटा हो सकता है। PostgreSQL के लिए Azure डेटाबेस पर, यह पैरामीटर आपके कंप्यूट टियर के आधार पर स्वचालित रूप से ट्यून किया जाता है, लेकिन आप इसे अपने स्तर के लिए अनुमत सीमा के भीतर समायोजित कर सकते हैं। समर्पित वेक्टर खोज वर्कलोड के लिए, अपने वेक्टर इंडेक्स के साथ-साथ अन्य कैश्ड डेटा के लिए मार्जिन रखने के लिए पर्याप्त बड़े लक्ष्य रखें shared_buffers । एक प्रारंभिक बिंदु उपलब्ध मेमोरी का 25% है, जिसमें निगरानी के आधार पर वृद्धि होती है। निम्न क्वेरीज़ आपकी वर्तमान सेटिंग्स और कैश प्रदर्शन की जाँच करने में आपकी मदद करती हैं.

-- Check current setting
SHOW shared_buffers;

-- View buffer cache hit ratio
SELECT
    sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) AS cache_hit_ratio
FROM pg_statio_user_tables;

work_mem पैरामीटर अलग-अलग क्वेरी ऑपरेशन जैसे सॉर्ट और हैश जॉइन के लिए उपलब्ध मेमोरी को नियंत्रित करता है। वेक्टर समानता प्रश्न, विशेष रूप से वेक्टर खोज को फ़िल्टरिंग और ऑर्डरिंग के साथ जोड़ने, पर्याप्त work_memसे लाभान्वित होते हैं। डिफ़ॉल्ट work_mem (आमतौर पर 4 एमबी) अक्सर वेक्टर संचालन के लिए बहुत छोटा होता है जिसे समानता के आधार पर परिणामों को सॉर्ट करना चाहिए। आप उन सत्रों या क्वेरीज़ के लिए इस मान को बढ़ा सकते हैं, जो बड़े परिणाम सेट के साथ वेक्टर खोज करते हैं SET work_mem = '256MB';. वैश्विक वृद्धि work_mem के साथ सावधान रहें क्योंकि सेटिंग प्रति-ऑपरेशन प्रति-कनेक्शन लागू होती है, इसलिए जटिल क्वेरीज़ के साथ 100 समवर्ती कनेक्शन को संभालने वाला सर्वर स्मृति में 100 × work_mem × ऑपरेशन-प्रति-क्वेरी का उपभोग कर सकता है। वेक्टर वर्कलोड के लिए, विश्व स्तर के बजाय विशिष्ट प्रश्नों के लिए सत्र स्तर पर सेट करने work_mem पर विचार करें।

effective_cache_size पैरामीटर क्वेरी प्लानर को बताता है कि कैशिंग के लिए कितनी मेमोरी उपलब्ध है, जिसमें PostgreSQL shared_buffers और ऑपरेटिंग सिस्टम की फ़ाइल कैश दोनों शामिल हैं। यह सेटिंग स्मृति आवंटित नहीं करता है, लेकिन प्रभावित करता है कि क्या योजनाकार अनुक्रमिक स्कैन पर अनुक्रमणिका स्कैन चुनता है। समर्पित डेटाबेस सर्वर पर कुल सिस्टम स्मृति के लगभग 75% पर सेट करें effective_cache_size . उच्च मान योजनाकार को अनुक्रमणिका का उपयोग करने के लिए प्रोत्साहित करते हैं, जो आमतौर पर वेक्टर खोज के लिए फायदेमंद होता है। PostgreSQL के लिए Azure डेटाबेस पर, यह आपके स्तर के आधार पर स्वचालित रूप से कॉन्फ़िगर किया गया है।

PostgreSQL का क्वेरी प्लानर लागत अनुमानों के आधार पर प्रश्नों को निष्पादित करने के तरीके के बारे में निर्णय लेता है। कई पैरामीटर इन अनुमानों को प्रभावित करते हैं, और आधुनिक SSD स्टोरेज के लिए उन्हें ट्यून करने से वेक्टर क्वेरी योजना में सुधार होता है।

random_page_cost पैरामीटर किसी अनुक्रमिक पृष्ठ के सापेक्ष यादृच्छिक डिस्क पृष्ठ को पढ़ने की लागत का अनुमान लगाता है. 4.0 का डिफ़ॉल्ट मान कताई डिस्क विशेषताओं को दर्शाता है जहां यादृच्छिक पहुंच अनुक्रमिक पहुंच की तुलना में काफी धीमी है। PostgreSQL के लिए Azure डेटाबेस SSD स्टोरेज का उपयोग करता है जहां यादृच्छिक और अनुक्रमिक पहुंच का प्रदर्शन समान होता है। 1.1-1.5 तक कम random_page_cost करने से योजनाकार को इंडेक्स स्कैन का अधिक आसानी से उपयोग करने के लिए प्रोत्साहित किया जाता है, जिससे वेक्टर खोजों को लाभ होता है जो बिखरे हुए डेटा पृष्ठों तक पहुंचते हैं। आप इस सेटिंग को समायोजित SET random_page_cost = 1.1;कर सकते हैं।

effective_io_concurrency पैरामीटर PostgreSQL बताता है कि स्टोरेज सिस्टम कितने समवर्ती डिस्क I/O ऑपरेशन को संभाल सकता है। उच्च मान बिटमैप हीप स्कैन को समानांतर में अधिक पृष्ठों को प्रीफ़ेच करने में सक्षम बनाते हैं। SSD स्टोरेज समवर्ती I/O को अच्छी तरह से संभालता है, इसलिए PostgreSQL इंस्टेंस के लिए SSD-आधारित Azure डेटाबेस के लिए 200 पर सेट effective_io_concurrency करें। यह क्वेरीज़ के लिए प्रदर्शन में सुधार करता है जो मेटाडेटा फ़िल्टरिंग के साथ वेक्टर समानता को संयोजित करते हैं।

parallel_tuple_cost और पैरामीटर parallel_setup_cost नियंत्रित करते हैं जब PostgreSQL समानांतर क्वेरी निष्पादन का उपयोग करता है। वेक्टर ऑपरेशन समानता से लाभान्वित हो सकते हैं, विशेष रूप से बड़ी तालिकाओं पर अनुक्रमिक स्कैन के लिए। (डिफ़ॉल्ट 0.1) और (parallel_tuple_costडिफ़ॉल्ट 1000) के लिए कम parallel_setup_cost मान समानांतर निष्पादन को प्रोत्साहित करते हैं। बड़ी तालिकाओं वाले वेक्टर वर्कलोड के लिए, समानता सक्षम करने से क्वेरी समय को काफी कम किया जा सकता है जब अनुक्रमणिका का उपयोग नहीं किया जा रहा हो. आप , , SHOW parallel_tuple_cost;और का SHOW parallel_setup_cost;उपयोग करके SHOW max_parallel_workers_per_gather;अपनी वर्तमान समानांतर सेटिंग्स की जांच कर सकते हैं।

pgvector-विशिष्ट पैरामीटर कॉन्फ़िगर करें

pgvector एक्सटेंशन कॉन्फ़िगरेशन पैरामीटर प्रदान करता है जो अनुक्रमणिका-आधारित खोजों के लिए सटीकता-गति ट्रेड-ऑफ को नियंत्रित करता है। ये पैरामीटर वेक्टर क्वेरी प्रदर्शन को ट्यून करने के लिए महत्वपूर्ण हैं।

IVFFlat अनुक्रमणिका का उपयोग करते समय, ivfflat.probes पैरामीटर नियंत्रित करता है कि प्रत्येक क्वेरी के लिए कितने अनुक्रमणिका विभाजन (सूचियाँ) खोजे जाते हैं। उच्च मूल्य याद को बढ़ाते हैं (सच्चे निकटतम पड़ोसियों में से अधिक खोजना) लेकिन धीमी क्वेरी। यह ट्रेड-ऑफ IVFFlat प्रदर्शन ट्यूनिंग के लिए केंद्रीय है। आप अधिक विभाजन खोजने की लागत के खिलाफ अच्छे मैचों के छूटने के जोखिम को संतुलित कर रहे हैं। 1 का डिफ़ॉल्ट मान केवल सबसे आशाजनक विभाजन की खोज करता है, जो तेज़ है लेकिन आसन्न विभाजन में संग्रहीत प्रासंगिक परिणामों को याद कर सकता है। अनुशंसा इंजनों के लिए जहां एक अच्छा मिलान याद करने से उपयोगकर्ता अनुभव कम हो जाता है, अपने पैरामीटर के ivfflat.probes 5-10% पर सेट के साथ lists शुरू करें और मापा याद के आधार पर समायोजित करें।

-- Configure IVFFlat search depth
SET ivfflat.probes = 10;

-- Execute vector search
SELECT id, name, embedding <=> $1 AS distance
FROM products
ORDER BY embedding <=> $1
LIMIT 10;

HNSW अनुक्रमणिका के लिए, पैरामीटर खोज के hnsw.ef_search दौरान गतिशील उम्मीदवार सूची के आकार को नियंत्रित करता है। बड़े मान ग्राफ के अधिक अन्वेषण करते हैं, गति की लागत पर याद में सुधार करते हैं। IVFFlat के असतत विभाजन के विपरीत, HNSW की ग्राफ़ संरचना का मतलब है कि यह पैरामीटर प्रभावित करता है कि एल्गोरिदम परिणाम लौटाने से पहले पड़ोसी कनेक्शन की कितनी अच्छी तरह से खोज करता है। 40 का डिफ़ॉल्ट मान कई कार्यभार के लिए उचित संतुलन प्रदान करता है। उच्च-सटीकता आवश्यकताओं (जैसे कि वास्तविक शीर्ष -10 मैचों को ढूंढना) के लिए, 100-200 तक बढ़ाएं। विलंबता-महत्वपूर्ण अनुप्रयोगों के लिए जहां अनुमानित परिणाम स्वीकार्य हैं, 20 के रूप में कम मान काम कर सकते हैं। अपनी वेक्टर खोज निष्पादित करने से पहले कॉन्फ़िगर hnsw.ef_search करेंSET hnsw.ef_search = 100;। इष्टतम मूल्य आपकी सटीकता आवश्यकताओं और विलंबता बजट पर निर्भर करता है। अपने आवेदन के लिए सही संतुलन खोजने के लिए प्रतिनिधि प्रश्नों के साथ बेंचमार्क।

प्रदर्शन की निगरानी और माप करें

माप के बिना ट्यूनिंग अनुमान है। क्वेरी व्यवहार को समझने और कॉन्फ़िगरेशन परिवर्तनों को मान्य करने के लिए PostgreSQL के अंतर्निहित टूल और Azure मॉनिटर का उपयोग करें।

EXPLAIN ANALYZE कमांड दिखाता है कि कैसे PostgreSQL एक क्वेरी निष्पादित करता है और वास्तविक समय की जानकारी प्रदान करता है। वेक्टर प्रश्नों के लिए, इससे पता चलता है कि क्या अनुक्रमणिका का उपयोग किया जा रहा है और जहां समय व्यतीत किया जाता है। निष्पादन योजना को समझने से आपको यह पहचानने में मदद मिलती है कि क्या खराब प्रदर्शन अनुपलब्ध अनुक्रमणिकाओं, उप-इष्टतम पैरामीटर सेटिंग्स या डेटा वितरण समस्याओं से उत्पन्न होता है। निष्पादन योजना देखने के लिए अपनी वेक्टर क्वेरी से पहले दौड़ें EXPLAIN ANALYZE । [index_name] (इंगित करता है कि वेक्टर इंडेक्स का उपयोग किया जा रहा है), Seq स्कैन (एक अनुक्रमिक स्कैन को इंगित करता है, जो बड़ी तालिकाओं के लिए धीमा है), वास्तविक समय मान (दिखाएं कि निष्पादन समय कहाँ खर्च किया जाता है), और पंक्तियों की गणना (यह पहचानने में मदद करें कि फ़िल्टरिंग कुशलता से काम कर रही है या नहीं) का उपयोग करके इंडेक्स स्कैन देखें। यदि आप अनुक्रमणिका उपयोग की अपेक्षा करते समय अनुक्रमिक स्कैन देखते हैं, तो जांचें कि क्वेरी का दूरी ऑपरेटर अनुक्रमणिका के ऑपरेटर वर्ग से मेल खाता है (उदाहरण के लिए, इसका उपयोग करके बनाई <=>गई अनुक्रमणिका के साथ उपयोग करनाvector_cosine_ops)।

कभी-कभी PostgreSQL उपलब्ध इंडेक्स का उपयोग नहीं करने का विकल्प चुनता है। वेक्टर क्वेरीज़ के सामान्य कारणों में वे क्वेरीज़ शामिल हैं जो तालिका के एक बड़े हिस्से को लौटाती हैं (अनुक्रमणिका ओवरहेड अनुक्रमिक स्कैन से अधिक है), महत्वपूर्ण डेटा परिवर्तनों के बाद पुराने आँकड़े, या एक दूरी ऑपरेटर जो अनुक्रमणिका के ऑपरेटर वर्ग से मेल नहीं खाता है। सटीक योजना के लिए आँकड़ों को अद्यतन करने के लिए दौड़ें ANALYZE products; । आप इंडेक्स की जानकारी देख सकते हैं SELECT indexname, indexdef FROM pg_indexes WHERE tablename = 'products';।

PostgreSQL के लिए Azure डेटाबेस Azure मॉनिटर के माध्यम से मेट्रिक्स को उजागर करता है जो प्रदर्शन बाधाओं की पहचान करने में मदद करता है। मॉनिटर CPU प्रतिशत (उच्च निरंतर CPU कंप्यूट-बाउंड वेक्टर कार्रवाई को इंगित करता है), मेमोरी प्रतिशत (निकट आने की सीमा गणना टियर बढ़ाने या क्वेरीज़ को अनुकूलित करने का सुझाव देती है), संग्रहण IO प्रतिशत (उच्च मान इंगित करते हैं कि डेटा कैश में फिट नहीं हो रहा है), और सक्रिय कनेक्शन (निकट आने की सीमा इंगित करती है कि कनेक्शन पूलिंग मदद कर सकता है)। उपयोगकर्ताओं को प्रभावित करने से पहले प्रदर्शन में गिरावट को पकड़ने के लिए इन मीट्रिक के लिए अलर्ट सेट करें।

pgvector ट्यूनिंग के लिए सर्वोत्तम अभ्यास

प्रभावी ट्यूनिंग यादृच्छिक पैरामीटर परिवर्तनों के बजाय एक व्यवस्थित दृष्टिकोण का अनुसरण करती है।

  • पहले आधार रेखा स्थापित करें: परिवर्तन करने से पहले क्वेरी विलंबता और संसाधन उपयोग को मापें. बेसलाइन के बिना, आप यह निर्धारित नहीं कर सकते कि परिवर्तन मदद करते हैं या चोट पहुँचाते हैं।
  • एक समय में एक पैरामीटर बदलें: एक साथ कई परिवर्तन विशिष्ट सेटिंग्स के लिए सुधार या प्रतिगमन का श्रेय देना असंभव बनाते हैं।
  • उत्पादन जैसे डेटा के साथ परीक्षण करें: क्वेरी का प्रदर्शन डेटा आकार और वितरण के साथ नाटकीय रूप से भिन्न होता है। छोटे परीक्षण डेटासेट पर ट्यूनिंग अक्सर ऐसी सेटिंग्स उत्पन्न करती है जो बड़े पैमाने पर विफल हो जाती हैं।
  • प्रतिगमन के लिए मॉनिटर: वेक्टर खोज को बेहतर बनाने वाले पैरामीटर अन्य कार्यभार को नकारात्मक रूप से प्रभावित कर सकते हैं. परिवर्तनों के बाद समग्र सिस्टम स्वास्थ्य की निगरानी करें।
  • अपनी सेटिंग का दस्तावेजीकरण करें: रिकॉर्ड करें कि आपने क्या बदला, क्यों और इसका क्या प्रभाव पड़ा। भविष्य की समस्याओं का निवारण करते समय यह दस्तावेज़ अमूल्य है।

अतिरिक्त संसाधन