हम Postgres में एक पूर्ण-पाठ खोज तैयार कर रहे हैं। भाग 1

युपीडी। भाग २

यह लेख पोस्टग्रेजेक्यू में पूर्ण-पाठ खोज को बेहतर ढंग से कॉन्फ़िगर करने के तरीके पर लेखों की एक छोटी श्रृंखला है। मुझे हाल ही में काम पर इसी तरह की समस्या को हल करना पड़ा - और मुझे इस विषय पर कम से कम कुछ समझदार सामग्री की अनुपस्थिति पर बहुत आश्चर्य हुआ। कट के तहत लड़ने का मेरा अनुभव।

टाई

मैं अपेक्षाकृत बड़ी परियोजना का समर्थन करता हूं जिसमें दस्तावेजों पर एक सार्वजनिक खोज है। डेटाबेस में ~ 3.6 जीबी की कुल मात्रा के साथ ~ 500 हजार दस्तावेज शामिल हैं। खोज का सार यह है: उपयोगकर्ता एक ऐसे फॉर्म को भरता है जिसमें डेटाबेस में विभिन्न प्रकार के फ़ील्ड्स के साथ-साथ एक पूर्ण-पाठ क्वेरी और फ़िल्टरिंग शामिल है, जिसमें शामिल हैं।

स्फिंक्स के माध्यम से खोज कार्य (या बल्कि, काम किया) और बहुत अच्छी तरह से काम नहीं किया। मुख्य समस्याएं इस प्रकार थीं:

1. इंडेक्सिंग ने लगभग 8 जीबी रैम की खपत की। 8 जीबी रैम वाले सर्वर पर, यह एक समस्या है। मेमोरी की अदला-बदली हुई, इसने भयानक प्रदर्शन किया।
2. सूचकांक लगभग 40 मिनट में बनाया गया था। खोज परिणामों की किसी भी स्थिरता का कोई सवाल ही नहीं था, दिन में एक बार अनुक्रमण शुरू किया गया था।
3. खोज ने लंबे समय तक काम किया। विशेष रूप से लंबे समय के लिए अनुरोध किए गए थे, जो बड़ी संख्या में दस्तावेजों के अनुरूप थे: बड़ी संख्या में आईडी-शनीक्स को स्फिंक्स से डेटाबेस में स्थानांतरित किया जाना था, और बैकएंड पर प्रासंगिकता के आधार पर क्रमबद्ध किया गया था।

इन समस्याओं के कारण, कार्य उत्पन्न हुआ - पूर्ण-पाठ खोज को अनुकूलित करने के लिए। इस कार्य के दो समाधान हैं:

1. टाइटेन स्फिंक्स: एक रीयलटाइम इंडेक्स को कॉन्फ़िगर करें, इंडेक्स में फ़िल्टरिंग के लिए स्टोर विशेषताएँ।
2. बिल्ट-इन FTS PostgreSQL का उपयोग करें।

दूसरे समाधान को लागू करने का निर्णय लिया गया था: इस तरह आप मूल रूप से सूचकांक के ऑटो-अपडेट प्रदान कर सकते हैं, दो सेवाओं के बीच लंबे संचार से छुटकारा पा सकते हैं और दो के बजाय एक सेवा की निगरानी कर सकते हैं।

यह एक अच्छा समाधान प्रतीत होगा। लेकिन समस्याएं आगे रहीं।

चलिए शुरू से ही शुरू करते हैं।

हम भोलेपन से पूर्ण-पाठ खोज का उपयोग करते हैं

जैसा कि प्रलेखन कहता है, पूर्ण-पाठ खोजों को tsvector और tsquery के उपयोग की आवश्यकता होती है। पहला एक खोज-अनुकूलित रूप में दस्तावेज़ का पाठ संग्रहीत करता है, दूसरा एक पूर्ण-पाठ क्वेरी संग्रहीत करता है।

PostgreSQL को खोजने के लिए, वहाँ to_tsvector , plainto_tsquery , to_tsquery । परिणामों को रैंक करने के लिए ts_rank । उनका उपयोग सहज है और वे प्रलेखन में अच्छी तरह से वर्णित हैं, इसलिए हम उनके उपयोग के विवरण पर ध्यान नहीं देते हैं।

उनका उपयोग करने वाली एक पारंपरिक खोज क्वेरी इस तरह दिखाई देगी:

 SELECT id, ts_rank(to_tsvector("document_text"), plainto_tsquery('')) FROM documents_document WHERE to_tsvector("document_text") @@ plainto_tsquery('') ORDER BY ts_rank(to_tsvector("document_text"), plainto_tsquery('')) DESC; 

हमने दस्तावेजों के आईडी-एस को काट दिया, जिसमें "क्वेरी" शब्द है, और उन्हें प्रासंगिकता के अवरोही क्रम में क्रमबद्ध किया। सब कुछ ठीक लग रहा है? नहीं।

ऊपर दिए गए दृष्टिकोण के कई नुकसान हैं:

1. हम खोज के लिए सूचकांक का उपयोग नहीं करते हैं।
2. Ts_vector फ़ंक्शन तालिका की प्रत्येक पंक्ति के लिए कहा जाता है।
3. Ts_rank फ़ंक्शन को तालिका की प्रत्येक पंक्ति के लिए कहा जाता है।

यह सब इस तथ्य की ओर जाता है कि खोज वास्तव में लंबा समय लेती है। युद्धक आधार पर परिणाम देखें:

 Gather Merge (actual time=420289.477..420313.969 rows=58742 loops=1) Workers Planned: 2 Workers Launched: 2 -> Sort (actual time=420266.150..420267.935 rows=19581 loops=3) Sort Key: (ts_rank(to_tsvector(document_text), plainto_tsquery(''::text))) DESC Sort Method: quicksort Memory: 2278kB -> Parallel Seq Scan on documents_document (actual time=65.454..420235.446 rows=19581 loops=3) Filter: (to_tsvector(document_text) @@ plainto_tsquery(''::text)) Rows Removed by Filter: 140636 Planning time: 3.706 ms Execution time: 420315.895 ms 

420 सेकंड! एक निवेदन के लिए!

आधार भी प्रपत्र की बहुत सारी vorings उत्पन्न करता है [54000] word is too long to be indexed । चिंता की कोई बात नहीं है। कारण यह है कि मेरे डेटाबेस में WYSIWYG संपादक में बनाए गए दस्तावेज़ हैं। इसमें बहुत सारे   जहां भी संभव हो, और एक पंक्ति में 54 हजार हैं। इस लंबाई के शब्दों को नजरअंदाज कर देता है और एक ऐसी वॉर्डिंग लिखता है जिसे अक्षम नहीं किया जा सकता।

हम नोट किए गए सभी समस्याओं को ठीक करने और खोज को गति देने का प्रयास करेंगे।

हम भोलेपन से खोज को अनुकूलित करते हैं

हम मुकाबला बेस के साथ नहीं खेलेंगे, निश्चित रूप से - हम एक टेस्ट बेस बनाएंगे। इसमें ~ 12 हजार दस्तावेज शामिल हैं। उदाहरण से अनुरोध को वहां निष्पादित किया जाता है ~ 35 सेकंड। अविश्वसनीय रूप से लंबा!

 Sort (actual time=35431.874..35432.208 rows=3593 loops=1) Sort Key: (ts_rank(to_tsvector(document_text), plainto_tsquery(''::text))) DESC Sort Method: quicksort Memory: 377kB -> Seq Scan on documents_document (actual time=8.470..35429.261 rows=3593 loops=1) Filter: (to_tsvector(document_text) @@ plainto_tsquery(''::text)) Rows Removed by Filter: 9190 Planning time: 0.200 ms Execution time: 35432.294 ms 

सूची

सबसे पहले, निश्चित रूप से, आपको एक सूचकांक जोड़ने की आवश्यकता है। सबसे आसान तरीका: एक कार्यात्मक सूचकांक।

 CREATE INDEX idx_gin_document ON documents_document USING gin (to_tsvector('russian', "document_text")); 

इस तरह के सूचकांक को लंबे समय के लिए बनाया जाएगा - यह परीक्षण के आधार पर ~ 26 सेकंड लग गया। उसे डेटाबेस से गुजरने और प्रत्येक रिकॉर्ड के लिए to_tsvector फ़ंक्शन को कॉल करने की आवश्यकता है। यद्यपि यह अभी भी खोज को 12 सेकंड तक गति देता है, फिर भी यह अक्षम्य रूप से लंबा है!

 Sort (actual time=12213.943..12214.327 rows=3593 loops=1) Sort Key: (ts_rank(to_tsvector('russian'::regconfig, document_text), plainto_tsquery(''::text))) DESC Sort Method: quicksort Memory: 377kB -> Bitmap Heap Scan on documents_document (actual time=3.849..12212.248 rows=3593 loops=1) Recheck Cond: (to_tsvector('russian'::regconfig, document_text) @@ plainto_tsquery(''::text)) Heap Blocks: exact=946 -> Bitmap Index Scan on idx_gin_document (actual time=0.427..0.427 rows=3593 loops=1) Index Cond: (to_tsvector('russian'::regconfig, document_text) @@ plainto_tsquery(''::text)) Planning time: 0.109 ms Execution time: 12214.452 ms 

बार-बार कॉल to_tsvector

इस समस्या को हल करने के लिए, आपको डेटाबेस में tsvector को संग्रहीत करने की आवश्यकता है। दस्तावेजों के साथ एक तालिका में डेटा बदलते समय, निश्चित रूप से, आपको इसे अपडेट करने की आवश्यकता है - डेटाबेस में ट्रिगर के माध्यम से, बैकएंड का उपयोग करके।

ऐसा करने के दो तरीके हैं:

1. दस्तावेज़ों के साथ तालिका में टाइप tsvector का एक स्तंभ जोड़ें।
2. दस्तावेजों की तालिका के साथ एक-से-एक संचार के साथ एक अलग तालिका बनाएं, और वहां वैक्टर स्टोर करें।

पहले दृष्टिकोण के फायदे: खोज में join-s की कमी।
दूसरे दृष्टिकोण के फायदे: दस्तावेजों के साथ तालिका में अतिरिक्त डेटा की कमी, यह पहले की तरह ही आकार रहता है। बैकअप के साथ, आपको tsvector पर समय और स्थान बर्बाद नहीं करना है, जिसे आपको बैकअप करने की आवश्यकता नहीं है।

दोनों यात्राएं इस तथ्य की ओर ले जाती हैं कि डिस्क पर डेटा दोगुना हो जाता है: दस्तावेजों और उनके वैक्टर के ग्रंथ संग्रहीत होते हैं।

मैंने अपने लिए दूसरा दृष्टिकोण चुना, इसके फायदे मेरे लिए अधिक महत्वपूर्ण हैं।

 CREATE INDEX idx_gin_document ON documents_documentvector USING gin ("document_text"); 

 SELECT documents_document.id, ts_rank("text", plainto_tsquery('')) FROM documents_document LEFT JOIN documents_documentvector ON documents_document.id = documents_documentvector.document_id WHERE "text" @@ plainto_tsquery('') ORDER BY ts_rank("text", plainto_tsquery('')) DESC; 

लिंक की गई तालिका में डेटा जोड़ें और एक इंडेक्स बनाएं। डेटा को परीक्षण के आधार पर 24 सेकंड में जोड़ा गया, और एक इंडेक्स बनाने में केवल 2.7 सेकंड का समय लगा । इंडेक्स और डेटा को अपडेट करना, जैसा कि हम देखते हैं, काफी तेजी नहीं आई, लेकिन इंडेक्स को अब बहुत जल्दी अपडेट किया जा सकता है।

और कितनी बार खोज तेज हुई है?

 Sort (actual time=48.147..48.432 rows=3593 loops=1) Sort Key: (ts_rank(documents_documentvector.text, plainto_tsquery(''::text))) DESC Sort Method: quicksort Memory: 377kB -> Hash Join (actual time=2.281..47.389 rows=3593 loops=1) Hash Cond: (documents_document.id = documents_documentvector.document_id) -> Seq Scan on documents_document (actual time=0.003..2.190 rows=12783 loops=1) -> Hash (actual time=2.252..2.252 rows=3593 loops=1) Buckets: 4096 Batches: 1 Memory Usage: 543kB -> Bitmap Heap Scan on documents_documentvector (actual time=0.465..1.641 rows=3593 loops=1) Recheck Cond: (text @@ plainto_tsquery(''::text)) Heap Blocks: exact=577 -> Bitmap Index Scan on idx_gin_document (actual time=0.404..0.404 rows=3593 loops=1) Index Cond: (text @@ plainto_tsquery(''::text)) Planning time: 0.410 ms Execution time: 48.573 ms 

 SELECT id, ts_rank("text", plainto_tsquery('')) AS rank FROM documents_documentvector WHERE "text" @@ plainto_tsquery('') ORDER BY rank; 

  सॉर्ट (वास्तविक समय = 44.339..44.487 पंक्तियाँ = 3593 लूप = 1)
   सॉर्ट की: (ts_rank (टेक्स्ट, plainto_tsquery ('क्वेरी' :: टेक्स्ट)))
   सॉर्ट विधि: Quicksort मेमोरी: 265kB
   -> दस्तावेज़ों पर बिटमैप ही स्कैन करें_निर्देशक (वास्तविक समय = 0.692..43.682 पंक्तियाँ = 3593 लूप = 1)
         Recheck Cond: (टेक्स्ट @@ plainto_tsquery ('क्वेरी' :: टेक्स्ट))
         ढेर ब्लॉक: सटीक = 577
         -> idx_gin_document पर बिटमैप इंडेक्स स्कैन (वास्तविक समय = 0.577..0.577 पंक्तियाँ = 3593 लूप = 1)
               सूचकांक कंडोम: (पाठ @@ plainto_tsquery ('क्वेरी' :: पाठ))
 योजना समय: 0.182 एमएस
 निष्पादन समय: 44.610 एमएस

यकीन नहीं होता! और यह शामिल होने और ts_rank बावजूद है। पहले से ही काफी स्वीकार्य परिणाम है, अधिकांश समय खोज द्वारा नहीं, बल्कि प्रत्येक ts_rank लिए ts_rank की गणना द्वारा ts_rank जाएगा।

ts_rank एकाधिक कॉल

ऐसा लगता है कि हमने अपनी समस्याओं को सफलतापूर्वक हल कर लिया है, सिवाय इसके। 44 मिलीसेकंड एक सभ्य नेतृत्व समय है। सुखद अंत करीब लगता है? वहाँ यह था!

ts_rank बिना एक ही क्वेरी चलाएँ और परिणामों की तुलना करें।

 SELECT document_id, 1 AS rank FROM documents_documentvector WHERE "text" @@ plainto_tsquery('') ORDER BY rank; 

 Bitmap Heap Scan on documents_documentvector (actual time=0.503..1.609 rows=3593 loops=1) Recheck Cond: (text @@ plainto_tsquery(''::text)) Heap Blocks: exact=577 -> Bitmap Index Scan on idx_gin_document (actual time=0.439..0.439 rows=3593 loops=1) Index Cond: (text @@ plainto_tsquery(''::text)) Planning time: 0.147 ms Execution time: 1.715 ms 

1.7 एमएस! तीस गुना तेज! एक मुकाबला आधार के लिए, परिणाम ~ 150 एमएस और 1.5 सेकंड हैं। किसी भी मामले में अंतर परिमाण का एक क्रम है, और 1.5 सेकंड वह समय नहीं है जो आप आधार से उत्तर की प्रतीक्षा करना चाहते हैं। क्या करें?

आप प्रासंगिकता के आधार पर छंटनी बंद नहीं कर सकते; आप गिनती के लिए लाइनों की संख्या को कम नहीं कर सकते हैं (डेटाबेस को सभी ts_rank दस्तावेजों के लिए ts_rank गणना करनी चाहिए, अन्यथा उन्हें सॉर्ट नहीं किया जा सकता है)।

इंटरनेट पर कुछ स्थानों पर, सबसे लगातार अनुरोधों को कैश करने की सिफारिश की जाती है (और, तदनुसार, कॉल ts_rank)। लेकिन मैं इस दृष्टिकोण को पसंद नहीं करता: सही प्रश्नों का सही चयन करना काफी कठिन है, और गलत प्रश्नों पर खोज अभी भी धीमी होगी।

मुझे बहुत पसंद है कि सूचकांक के माध्यम से जाने के बाद डेटा पहले से ही क्रमबद्ध रूप में आया, जैसा कि स्फिंक्स करता है। दुर्भाग्य से, PostgreSQL में बॉक्स से कुछ भी नहीं किया जा सकता है।

लेकिन हम भाग्यशाली थे - आरयूएम इंडेक्स ऐसा कर सकता है। इसके बारे में विवरण पाया जा सकता है, उदाहरण के लिए, इसके लेखकों की प्रस्तुति में । यह अनुरोध के बारे में अतिरिक्त जानकारी संग्रहीत करता है, जो आपको सीधे तथाकथित का मूल्यांकन करने की अनुमति देता है। tsvector और tsquery बीच "दूरी" और सूचकांक को स्कैन करने के तुरंत बाद एक हल किया हुआ परिणाम।

लेकिन एक जीआईएन फेंकना और आरयूएम स्थापित करना अभी इसके लायक नहीं है। इसमें आवेदन के minuses, pluses और सीमाएं हैं - मैं इसके बारे में अगले लेख में लिखूंगा।