11

मेरे पास एक सारणी है जिसे मैंने एक पूर्ण टेक्स्ट कैटलॉग बनाया है। तालिका में सिर्फ 6000 से अधिक पंक्तियां हैं। मैंने इंडेक्स में दो कॉलम जोड़े हैं। पहले को एक प्रकार का अद्वितीय पहचानकर्ता माना जा सकता है और दूसरा उस आइटम के लिए सामग्री माना जा सकता है (मेरी तालिका में 11 अन्य कॉलम हैं जो पूर्ण टेक्स्ट कैटलॉग का हिस्सा नहीं हैं)। यहाँ पंक्तियों की एक जोड़ी का एक उदाहरण है:फुल-टेक्स्ट इंडेक्सिंग सुस्त। विकल्पों की तलाश

TABLE: data_variables 
ROW unique_id label 
1  A100d1  Personal preference of online shopping sites 
2  A100d2  Shopping behaviors for adults in household 

सामने के छोर पर मेरी वेब अनुप्रयोग में, मैं एक पाठ बॉक्स है कि उपयोगकर्ता में टाइप आइटम से मेल खाने वाले वे कर रहे हैं जो कुछ शब्दों की एक सूची प्राप्त करने के लिए कर सकते हैं UNIQUE ID या LABEL कॉलम में खोज रहे हैं। इसलिए, उदाहरण के लिए, यदि उपयोगकर्ता sho या a100 में टाइप किया गया है तो उपरोक्त दोनों पंक्तियों के साथ एक सूची पॉप्युलेट की जाएगी। अगर वे behav में टाइप करते हैं तो एक सूची ऊपर केवल पंक्ति 2 के साथ आबादी होगी।

यह प्रत्येक keyup पर एक अजाक्स अनुरोध के माध्यम से किया जाता है। पीएचपी एसक्यूएल सर्वर है कि लगता है कि पर एक संग्रहीत प्रक्रिया कॉल: (। @search उपयोगकर्ता कि संग्रहित प्रक्रिया में पारित हो जाता से पाठ है)

SELECT TOP 50 dv.id, dv.id + ': ' + dv.label, 
       dv.type_id, dv.grouping, dv.friendly_label 
FROM   data_variables dv 
WHERE   (CONTAINS((dv.unique_id, dv.label), @search)) 

मैंने देखा है कि यह बहुत सुस्त हो जाता है , विशेष रूप से जब मैं क्वेरी में TOP 50 का उपयोग नहीं कर रहा था।

जो मैं खोज रहा हूं वह सीधे एसक्यूएल सर्वर पर या पूर्ण-पाठ अनुक्रमणिकाकरण विचार को छोड़कर और क्लाइंट-साइड पर खोजने योग्य वस्तुओं की एक सरणी के माध्यम से खोजने के लिए jQuery का उपयोग करके इसे गति देने का एक तरीका है। मैंने jQuery स्वत: पूर्ण सामग्री और ऑटोकंपलेट के लिए कुछ अन्य jQuery प्लगइन में थोड़ा सा देखा है, लेकिन अभी तक कुछ भी नकल करने की कोशिश नहीं की है। यह मेरा अगला कदम होगा, लेकिन मैं यह देखने के लिए पहले यहां जांचना चाहता था कि मुझे कौन सी सलाह मिलेगी।

अग्रिम धन्यवाद।

+4

आप पुष्टि कर सकते हैं कि आप एसक्यूएल प्रदर्शन अकेले मापा जाता है और सिर्फ अपने वेब पेज का उपयोग नहीं कर रहे हैं?यदि आप इसका परीक्षण करने के लिए वेब पेज का उपयोग कर रहे हैं, तो कई अन्य चीजें समस्या हो सकती हैं, सुनिश्चित करें कि आप इसे जानते हैं, बस दोबारा जांच करना चाहते हैं। क्या आप अधिक खोज स्ट्रिंग टाइप करते समय तेज़ी से बढ़ते हैं? यदि हां, तो इसका मतलब है कि यह एसक्यूएल – rlb

+0

नहीं है 'यह प्रत्येक कीप पर अजाक्स अनुरोध के माध्यम से किया जाता है' - क्या ऐसा होने से पहले न्यूनतम लंबाई है? यह मेरे पालतू शिखरों में से एक है, इसलिए मैं बहुत ज्यादा नहीं रुकूंगा, लेकिन जब पृष्ठ मेरे पहले कुछ कीस्ट्रोक निगलता है तो मुझे इससे नफरत है। कुंजीपटल पर पूर्ण पाठ खोज लागू होने से पहले यह कम से कम तीन या चार वर्णों की प्रतीक्षा करने के लिए प्रदर्शन कोण से बेहतर होगा। पहले कुछ पुनर्प्राप्ति वापस बोतलबंद लाते हैं। भले ही आप इनकार करने से पहले कुछ पात्रों की प्रतीक्षा करें, मैं उम्मीद नहीं करूँगा कि यह बहुत अच्छी तरह से स्केल करे। और मुझे पता है कि क्लाउड लेटेंसी के कारण बादल में डीबी पर बहुत अच्छा काम नहीं करेगा। – Tim

+0

टिम: हाँ - यह 2 कीस्ट्रोक के बाद ट्रिगर करता है। मैं इसे और अधिक नहीं बना सकता क्योंकि अद्वितीय आईडी हैं जो केवल दो वर्ण लंबी हैं। – tptcat

उत्तर

5

इस तथ्य के आधार पर कई सुझाव हैं कि आपके पास केवल 6000 पंक्तियां हैं, इसलिए डेटाबेस को यह जीवित खाना चाहिए।

ए। ऑपरेटर की तरह प्रयोग करने का प्रयास करें, बस अगर यह मदद करता है। यह भी उम्मीद नहीं है, लेकिन कोशिश करने के लिए बहुत तुच्छ है। इस छोटे से वॉल्यूम को देखते हुए यह पता लगाने के लिए यहां पर कुछ और चल रहा है।

बी क्या आप पहले से ही प्रश्नों को कैश कर सकते हैं? 6000 पंक्तियों के साथ, शायद 2 वर्ण क्वेरी के केवल 36 * 36 संयोजन होते हैं, जिन्हें लगभग कोई स्मृति नहीं लेनी चाहिए और डेटाबेस को किसी भी काम को सहेजना चाहिए।

सी क्लाइंट को चयन को स्थानांतरित करना एक अच्छा विचार है, यह निर्भर करता है कि 6000 पंक्तियां कितनी बड़ी हैं, व्यक्तिगत लुकअप के लिए नेटवर्क विलंबता बनाम।

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

+0

मैं आपको अपनी मूल पोस्ट पर आपकी टिप्पणी के लिए बक्षीस, रिब, पुरस्कार देने जा रहा हूं। मैंने अपने प्रश्नों का कुछ और पूर्ण माप किया और असली मुद्दा मेरा फ्रंट एंड है। मैं अनुकूलित करने पर काम करने जा रहा हूं क्योंकि ऐसा लगता है कि वास्तविक मंदी कहाँ है। सभी के सुझावों के लिए धन्यवाद। व्यक्तिगत अनुभव solr विकल्प से – tptcat

2

यदि आप डेटा की मात्रा बढ़ाने की योजना बनाते हैं तो यह पूर्ण-पाठ खोज के लिए रिवर्स इंडेक्स का उपयोग करने का सबसे अच्छा तरीका होगा।

Apache Solr पर देखें - इस समय सर्वश्रेष्ठ पूर्ण टेक्स्ट खोज इंजन।

आप समय-समय पर अपने डेटाबेस डेटा को इंडेक्स कर सकते हैं और खोज इंजन के रूप में सोलर का उपयोग कर सकते हैं, यह सरल AJAX एपीआई प्रदान करता है और सीधे फ्रंटेंड से पूछताछ की जा सकती है।

+0

अच्छा है यदि डेटा को केवल पढ़ने के लिए ही डेटा पुनर्प्राप्ति नौकरियां ही पढ़नी हों, लेकिन यदि डेटा को बार-बार बढ़ाया जाना है तो सोलर इंडेक्स को अद्यतन/रखरखाव महंगा/व्यस्त कार्य हो सकता है इस उपयोग-मामले के लिए – Rafay

+0

इंडेक्स को विभाजित किया जा सकता है। – Nik

5

मुझे एक ही समस्या थी और LIKE समाधान के लिए चला गया। मुझे यह भी पता चला कि ऑपरेटर बहुत कर लगाने और क्वेरी को दो यूनियनों के साथ विभाजित करने के लिए विभाजित करता है (सबसे तेज़, और मेरे परिदृश्य में इंडेक्स कॉलम और डेटा में एक ही टेक्स्ट ढूंढना असंभव था)।

आपके जैसे

SELECT TOP 50 from (
select dv.id, dv.id + ': ' + dv.label, 
       dv.type_id, dv.grouping, dv.friendly_label 
FROM   data_variables dv 
WHERE   dv.unique_id like '%'[email protected]+'%' 
UNION ALL 
select dv.id, dv.id + ': ' + dv.label, 
       dv.type_id, dv.grouping, dv.friendly_label 
FROM   data_variables dv 
WHERE   dv.label like '%'[email protected]+'%' 
) 

ओह हो जाएगा !! और एसक्यूएल सर्वर में प्रदर्शन का परीक्षण करें, वेब पर नहीं!

6

मैं एक LIKE के खिलाफ सलाह दूंगा, जब तक कि आप एक रैखिक अनुक्रमणिका (बाएं से दाएं) का उपयोग नहीं कर रहे हों और आप LIKE 'work%' जैसे प्रश्न कर रहे हैं। यदि आप LIKE '%word%' जैसे कुछ कर रहे हैं तो एक नियमित अनुक्रमणिका आपकी सहायता नहीं करेगी। जब आप अनुच्छेद के अंदर शब्दों की खोज करना चाहते हैं तो आप आमतौर पर एक पूर्ण-पाठ अनुक्रमणिका का उपयोग करना चाहते हैं।

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

कुछ विकल्प Sphinx, Solr, और elasticsearch, बस कुछ नाम देने के लिए हैं। मैं यह नहीं कहूंगा कि इनमें से कोई भी विकल्प दूसरे की तुलना में बेहतर है। निश्चित रूप से विचार करने के लिए पेशेवर और विपक्ष हैं:

  • आपके पास किस प्रकार का डेटा है?
  • इन समाधानों का कौन सा भाषा समर्थन है?
  • इन समाधानों का कौन सा डेटाबेस इंजन समर्थन करता है?

सबसे अच्छी बात यह है कि आप अपने मौजूदा डेटा के खिलाफ इन समाधानों को बेंचमार्क कर सकते हैं। प्रत्येक व्यक्तिगत घटक (इकाई परीक्षण) का परीक्षण करने से आप वास्तविक समस्याओं की पहचान कर सकते हैं और आपको अच्छे समाधान खोजने में मदद कर सकते हैं।

0

यदि आपको वास्तव में प्रदर्शन की आवश्यकता है .. आप देखना चाहते हैं; FTS3 और FTS4 ...

स्निप ... एक और मंच से ...

उदाहरण के लिए, "एनरॉन ई-मेल डेटासेट" में 517,430 से प्रत्येक दस्तावेज़ दोनों एक FTS तालिका में डाला जाता है, तो और निम्न SQL स्क्रिप्ट का उपयोग करके बनाई गई एक सामान्य SQLite तालिका:

कोड: VIRTUAL तालिका ENRondata1 बनाएं fts3 (सामग्री टेक्स्ट) का उपयोग करना;/* एफटीएस 3 तालिका / तालिका enrondata2 (सामग्री पाठ) बनाएं;/ साधारण तालिका */ फिर नीचे दिए गए दो प्रश्नों में से किसी एक डेटाबेस में दस्तावेज़ों की संख्या को खोजने के लिए निष्पादित किया जा सकता है जिसमें "लिनक्स" शब्द (351) शब्द होता है। एक डेस्कटॉप पीसी हार्डवेयर कॉन्फ़िगरेशन का उपयोग करके, FTS3 तालिका पर क्वेरी सामान्य तालिका पूछताछ के लिए लगभग 0.03 सेकंड में होती है, बनाम 22.5 बनाम।

देखें ...

http://www.sqlite.org/fts3.html

संबंधित मुद्दे