मैं सिर्फ SQL में "पूर्ण पाठ खोज" का उल्लेख करते हुए एक पोस्ट पढ़ता हूं।
मैं बस सोच रहा था कि FTS और LIKE में क्या अंतर है। मैंने कुछ लेख पढ़े लेकिन कुछ भी ऐसा नहीं मिला जिससे इसे अच्छी तरह समझाया जा सके।
मैं सिर्फ SQL में "पूर्ण पाठ खोज" का उल्लेख करते हुए एक पोस्ट पढ़ता हूं।
मैं बस सोच रहा था कि FTS और LIKE में क्या अंतर है। मैंने कुछ लेख पढ़े लेकिन कुछ भी ऐसा नहीं मिला जिससे इसे अच्छी तरह समझाया जा सके।
जवाबों:
सामान्य तौर पर, "सटीक" और "रिकॉल" के बीच एक व्यापार है। उच्च सटीकता का मतलब है कि कम अप्रासंगिक परिणाम प्रस्तुत किए गए हैं (कोई झूठी सकारात्मक नहीं), जबकि उच्च रिकॉल का मतलब है कि कम प्रासंगिक परिणाम गायब हैं (कोई गलत नकारात्मक नहीं)। LIKE ऑपरेटर का उपयोग करने से आपको रिकॉल के लिए कोई रियायत नहीं मिलने के साथ 100% सटीकता प्राप्त होती है। एक पूर्ण पाठ खोज सुविधा आपको बेहतर रिकॉल के लिए सटीक रूप से ट्यून करने की सुविधा देती है।
अधिकांश पूर्ण पाठ खोज कार्यान्वयन "उल्टे सूचकांक" का उपयोग करते हैं। यह एक इंडेक्स है जहां कुंजियाँ व्यक्तिगत शब्द हैं, और संबंधित मान रिकॉर्ड के सेट हैं जिसमें शब्द शामिल हैं। पूर्ण पाठ खोज को इन रिकॉर्ड सेटों के प्रतिच्छेदन, संघ, आदि की गणना करने के लिए अनुकूलित किया गया है, और आमतौर पर एक रैंकिंग एल्गोरिथ्म प्रदान करता है कि कैसे दिए गए रिकॉर्ड कीवर्ड्स से मेल खाते हैं।
SQL LIKE ऑपरेटर बेहद अक्षम हो सकता है। यदि आप इसे अन-इंडेक्स किए गए कॉलम पर लागू करते हैं, तो मैचों को खोजने के लिए एक पूर्ण स्कैन का उपयोग किया जाएगा (ठीक एक अन-इंडेक्स किए गए फ़ील्ड पर किसी भी क्वेरी की तरह)। यदि स्तंभ अनुक्रमणित किया गया है, तो मिलान अनुक्रमणिका कुंजियों के विरुद्ध किया जा सकता है, लेकिन अधिकांश अनुक्रमणिका लुकअप की तुलना में कम दक्षता के साथ। सबसे खराब स्थिति में, LIKE पैटर्न में अग्रणी वाइल्डकार्ड होंगे जिनकी जांच करने के लिए हर इंडेक्स कुंजी की आवश्यकता होती है। इसके विपरीत, कई सूचना पुनर्प्राप्ति सिस्टम चयनित क्षेत्रों में पूर्व-संकलित प्रत्यय पेड़ों द्वारा अग्रणी वाइल्डकार्ड के लिए समर्थन को सक्षम कर सकते हैं।
पूर्ण-पाठ खोज की अन्य विशेषताएँ विशिष्ट हैं
एफटीएस में पाठ रिकॉर्ड के भीतर अलग-अलग शब्दों को अनुक्रमित करना शामिल है ताकि कई रिकॉर्डों को त्वरित रूप से खोजा जा सके। LIKE का उपयोग करने के बाद भी आपको फ़ील्ड के भीतर एक स्ट्रिंग खोज (रैखिक या इस तरह) करने की आवश्यकता होती है।
MySQL सक्षम फुल-टेक्स्ट सर्च कॉलम के शब्दों से एक इंडेक्स बनाता है और इस इंडेक्स पर खोज करता है। खोज क्वेरी के विरुद्ध मिलान की गई पंक्तियों को निर्धारित करने के लिए MySQL एक परिष्कृत एल्गोरिदम का उपयोग करता है।
इसके अलावा, इस SO उत्तर से :
पूर्ण पाठ खोज में कुछ लाभ हैं।
अनुक्रमण:
कुछ इस तरह:
WHERE Foo LIKE '%Bar';किसी इंडेक्स का लाभ नहीं उठा सकते। इसे हर एक पंक्ति को देखना होगा, और देखना होगा कि क्या यह मेल खाता है। एक फुलटेक्स इंडेक्स, हालांकि, कर सकता है। वास्तव में, फुलटेक्स इंडेक्स मिलान शब्दों के क्रम के संदर्भ में बहुत अधिक लचीलेपन की पेशकश कर सकते हैं, कि वे शब्द एक साथ कितने करीब हैं, आदि।
स्टेमिंग:
एक फुलटैक्स खोज शब्दों को स्टेम कर सकती है। यदि आप रन की खोज करते हैं, तो आप "रन" या "रनिंग" के लिए परिणाम प्राप्त कर सकते हैं। अधिकांश फुलटेक्स्ट इंजन में विभिन्न भाषाओं में स्टेम शब्दकोश होते हैं।
भारित परिणाम:
एक फुलटेक्स्ट इंडेक्स में कई कॉलम शामिल हो सकते हैं। उदाहरण के लिए, आप "पीच पाई" की खोज कर सकते हैं, और सूचकांक में शीर्षक, कीवर्ड और एक निकाय शामिल हो सकते हैं। परिणाम जो शीर्षक से मेल खाते हैं, उन्हें अधिक प्रासंगिक के रूप में उच्च भारित किया जा सकता है, और शीर्ष के पास दिखाने के लिए सॉर्ट किया जा सकता है।
नुकसान:
एक फुलटेक्स्ट इंडेक्स संभावित रूप से बहुत बड़ा हो सकता है, मानक बी-ट्रेइ इंडेक्स से कई गुना बड़ा। इस कारण से, कई होस्ट प्रदाता जो डेटाबेस इंस्टेंस पेश करते हैं, वे इस सुविधा को अक्षम कर देते हैं, या कम से कम इसके लिए अतिरिक्त शुल्क लेते हैं। उदाहरण के लिए, पिछली बार मैंने जाँच की, विंडोज एज़्योर ने फुलटेक्स्ट प्रश्नों का समर्थन नहीं किया।
फुलटेक्स्ट इंडेक्स को भी अपडेट करने में धीमा हो सकता है। यदि डेटा बहुत बदल जाता है, तो मानक अनुक्रमित की तुलना में कुछ अंतराल अपडेट इंडेक्स हो सकते हैं।
वाइल्डकार्ड का उपयोग करता है, और यह सब शक्तिशाली नहीं है।
पूर्ण पाठ बहुत अधिक जटिल खोज की अनुमति देता है, जिसमें And, Or, Not, यहां तक कि समान ध्वनि परिणाम (SOUNDEX) और कई और आइटम शामिल हैं।
मैं SQL CONTAINS () FREETEXT () और संबंधित पूर्ण पाठ खोज आइटम को देखना शुरू कर दूंगा जो कि उपलब्ध है की बेहतर समझ पाने में मदद करता है।
वास्तविक अंतर स्कैनिंग पद्धति है। पूर्ण-पाठ खोज के लिए, शब्द (शब्द) का उपयोग हैश कीज़ के रूप में किया जाता है - जिनमें से प्रत्येक दस्तावेज़ों की एक सरणी से जुड़ा होता है, जिसमें कुंजियाँ (शब्द) दिखाई देती हैं। यह इस तरह है:
Document sets = {d1, d2, d3, d4, ... dn}
Term sets = {t1, t2, t3, .. tn}अब टर्म-डॉक्यूमेंट मैट्रिक्स (किस डॉक्यूमेंट के सदस्य) को इस रूप में दर्शाया जा सकता है:
t1 -> {d1, d5, d9,.. dn}
t2 -> {d11, d50, d2,.. dn}
t3 -> {d23, d67, d34,.. dn}
:
tn -> {d90, d87, d57,.. dn}जब अनुरोध "मुझे शब्द / शब्द t1" वाले सभी दस्तावेज़ प्राप्त करने के लिए आता है - तो दस्तावेज़ सेट {d1, d5, d9,.. dn} वापस कर दिया जाता है।
आप दस्तावेज़ों को संग्रहीत करने के लिए एक डी-सामान्यीकृत टेबल स्कीमा को हैक कर सकते हैं - MySQL तालिका में प्रत्येक पंक्ति को "दस्तावेज़" माना जाएगा और एक पाठ स्तंभ में एक अनुच्छेद आदि हो सकता है। उल्टे सूचकांक में हैश कीज़ और पंक्ति-आईडी के रूप में शब्द होंगे। दस्तावेज़ के रूप में आईडी।
याद रखें कि इस SQL क्वेरी में कम या ज्यादा O (1) प्रदर्शन होगा। क्वेरी स्वतंत्र होगी
उदाहरण के लिए इस SQL को दिए गए शब्द XYZ से मेल खाते सभी पंक्तियों को निकालने के लिए निकाल दिया जा सकता है:
SELECT *
FROM my_table
WHERE MATCH (my_text_column) against ('XYZ' IN boolean mode) ;कैविएट: यदि आप इस क्वेरी में ORDER BY जोड़ते हैं, तो आपके रनटाइम कई मापदंडों के आधार पर अलग-अलग होंगे, जिनमें से एक मिलान पंक्तियों / दस्तावेजों की संख्या है। तो खबरदार।
हालांकि LIKE को इसमें से कुछ भी नहीं मिला है। इसे वाक्य / स्ट्रिंग को रैखिक रूप से स्कैन करने और सभी मिलान शब्द खोजने के लिए मजबूर किया जाता है। वाइल्ड कार्ड जोड़ने से गड़बड़ हो जाती है। यह छोटी लंबाई के तारों के लिए बहुत अच्छा काम करता है, जैसा कि आप कल्पना कर सकते हैं, लेकिन लंबे वाक्यों के लिए बुरी तरह से विफल हो जाएंगे। और निश्चित रूप से एक पैराग्राफ या पाठ के पूरे पृष्ठ आदि होने पर तुलनीय नहीं है।
एफटीएस अधिक कुशल, शक्तिशाली (विशेष रूप से वर्ड ब्रेकर्स और स्टेमिंग फ़ंक्शंस के लिए) है ... लेकिन अपनी आवश्यकताओं की जांच करें क्योंकि कभी-कभी डीबीएस सभी भाषाओं का समर्थन नहीं करते हैं उदाहरण के लिए MSSQL ग्रीक का समर्थन नहीं करता है (इस पृष्ठ पर जांच http: // msdn। microsoft.com/en-us/library/ms176076(v=sql.110).aspx )