Elasticsearch आणि Oracle Indexing कसे वेगवेगळे आहेत

बहुतेक विकासकर्ते सर्व निर्देशांकांना एकत्र करतात — “फक्त काहीतरी जे क्वेरीज जलद करते” — हे समजल्याशिवाय की Elasticsearch आणि Oracle DB पूर्णपणे वेगवेगळ्या समस्यांचे निराकरण करत आहेत. ते समान डेटा पूर्णपणे विरुद्ध मार्गांनी निर्देशांकित करतात, आणि हा फरक त्यांच्या कार्यक्षमतेबद्दल सर्वकाही आकार देतो.

मी तुम्हाला दाखवतो की Oracle वर संपूर्ण-मजकूर शोध का दातांपासून खेचायला वाटते, तर Elasticsearch ते तुच्छ वाटवते.

मूल समस्या: दोन वेगवेगळे वापरकेस

Oracle डेटाबेस असे प्रश्न उत्तर देण्यासाठी तयार केले गेले आहेत: “मला तो पंक्ती दा जेथे user_id = 5” किंवा “जानेवारीच्या 1 ते 31 दरम्यान सर्व ऑर्डर शोधा.” अचूक जुळणी आणि श्रेणी क्वेरीज. डेटा संरचित आहे, स्तंभाने निर्देशांकित आहे, आणि क्वेरीज सामान्यत: अचूक असतात.

Elasticsearch हे यासाठी तयार केले गेले होते: “मला सर्व कागदपत्र शोधा ज्यात ‘microservices’ किंवा ‘distributed systems’ आहे, आणि त्यांना प्रासंगिकतेनुसार क्रमांकित करा.” स्केलवर संपूर्ण-मजकूर शोध. डेटा गोंधळलेला असू शकतो, क्वेरीज अस्पष्ट असतात, आणि वापरकर्ते अपेक्षा करतात परिणाम प्रासंगिकतेनुसार क्रमांकित असावेत, फक्त परत आले नाहीत.

हे फक्त वेगवेगळे वापरकेस नाहीत — ते विरुद्ध वापरकेस आहेत. Oracle एकाला डिझाइन केले असलेले दुसर्‍याला विचारल्यावर तुटते.

Oracle चा B-Tree: अचूकतेसाठी तयार

Oracle B-tree (संतुलित वृक्ष) निर्देशांका वापरतो. ते कसे काम करतात [1]:

B-tree एक क्रमबद्ध, वर्गीकृत संरचना आहे. एक संतुलित वृक्ष उलटा करून कल्पना करा. शीर्षस्थानी शाखा ब्लॉक (अंतर्गत नोड्स) आपल्या शोधाला मार्गदर्शन करतात. तळाशी लीफ ब्लॉक आहेत जे वास्तविक मुख्य मूल्य आणि ROWID (तक्त्यामधील पंक्तीचे भौतिक स्थान) संग्रहीत करतात.

जेव्हा तुम्ही मूल्यासाठी शोध करता, डेटाबेस वृक्षाखाली चालतो: शाखा ब्लॉक → शाखा ब्लॉक → लीफ ब्लॉक → सापडले. वृक्षाची खोली उथळ असते (अगदी लाखो पंक्तींसाठीही सामान्यत: 2-4 स्तर), तर शोध अतिशय जलद असतात — वृक्षाची उंचीइतकी डिस्क वाचने.

प्रत्येक लीफ ब्लॉक पुढील आणि मागील लीफ ब्लॉकला क्रमबद्ध क्रमानुसार निर्देश देतो [1]. हे Oracle ला श्रेणी स्कॅन कुशलतेने करू देते. 100 ते 200 ID असलेल्या सर्व वापरकर्त्यांची गरज आहे? जेव्हा तुम्हाला पहिला सापडतो, तर लीफ ब्लॉकमधून होप करा. कोणतीही उडी नाही.

किंमत? B-trees एकवेळी एका स्तंभासाठी तयार केले आहेत (जोपर्यंत तुम्ही समग्र निर्देशांका वापरत नाही). ते शोधांसाठी अनुकूलित आहेत, “हा शब्द असलेले काहीतरी शोधा” साठी नाही.

Elasticsearch चा उलटलेला निर्देशांक: शोधासाठी तयार

Elasticsearch काहीतरी पूर्णपणे भिन्न वापरतो: एक उलटलेला निर्देशांक [2]. आणि येथे मुख्य अंतर्दृष्टी आहे — हा आमच्या डेटाबद्दल सामान्यतः विचार करण्याच्या पद्धतीच्या तुलनेत उलटलेला आहे.

सामान्य मार्ग: कागदपत्र → त्या कागदपत्रातील शब्दांची सूची.
उलटलेला मार्ग: शब्द → त्या शब्द असलेल्या कागदपत्रांची सूची.

येथे एक ठोस उदाहरण आहे. समजा तुमच्याकडे तीन कागदपत्र आहेत:

कागदपत्र 1: “Elasticsearch is fast”
कागदपत्र 2: “Oracle is a database”
कागदपत्र 3: “Elasticsearch and Oracle are databases”

एक उलटलेला निर्देशांक हे असे संग्रहीत करतो:

टर्म	कागदपत्र
elasticsearch	[1, 3]
fast	[1]
oracle	[2, 3]
database	[2, 3]
is	[1, 2, 3]

“elasticsearch” किंवा “oracle” असलेल्या सर्व कागदपत्र शोधण्यासाठी, निर्देशांक फक्त दोन्ही टर्म शोधतो आणि त्यांच्या कागदपत्र सूचियांचे विलीनीकरण करतो. कोणतीही तक्ता स्कॅन नाही. प्रत्येक कागदपत्र तपासू नाही. तत्क्षण.

Oracle हे कुशलतेने करू शकत नाही कारण त्यांनी कागदपत्र कागदपत्र ID ने निर्देशांकित केले, त्यांच्यामधील शब्दांनी नाही. संपूर्ण-मजकूर शोध पूर्ण तक्ता स्कॅन बनतो [3].

Elasticsearch डेटा कसे अचूकपणे निर्देशांकित करतो

Elasticsearch मध्ये निर्देशांकन साधा उलटलेला निर्देशांक पेक्षा अधिक जटिल आहे [4]:

मजकूर टोकनाइজ केला जातो — “Elasticsearch is fast” [“elasticsearch”, “is”, “fast”] बनतो
टोकन सामान्य केले जातात — लोअरकेसिंग, स्टेमिंग (run → runn, runner → runn), स्टॉप शब्द काढून टाकणे (is, a, the)
टोकन उलटलेल्या निर्देशांकात संग्रहीत केले जातात — प्रत्येक अनन्य टोकन कागदपत्र ID ला मॅप करते

टोकनाइজेशन आणि फिल्टरिंग निर्देशांकन दरम्यान होते, शोध दरम्यान नाही. हीच कारण आहे शोध इतका जलद का आहे — भारी उठाव आगावर केले जाते.

Elasticsearch मध्ये प्रत्येक निर्देशांक शार्डमध्ये विभागला जातो [5]. एक शार्ड एक आत्मनिर्भर Lucene निर्देशांक आहे. जर तुमचा निर्देशांक विशाल होतो, Elasticsearch हा अनेक शार्डमध्ये विभागतो, आणि ते शार्ड एका क्लस्टरमध्ये विविध नोड्स (संगणक) वर राहतात. हे क्षैतिज स्केलिंग आहे — अधिक कागदपत्र? अधिक शार्ड जोडा. अधिक शार्ड? अधिक नोड्स जोडा.

प्रतिलिपी शार्डच्या प्रत (नकल) आहेत. नोड A वर प्राथमिक शार्ड, नोड B वर प्रतिलिपी [5]. जर नोड A मरण पावले, नोड B ओव्हरटेक करतो. अधिक प्रतिलिपी म्हणजे अधिक वाचन क्षमता — क्वेरीज कोणत्याही प्रतिलिपीला मारू शकतात.

Oracle असे काम करत नाही. तुम्ही डेटा मॅन्युअली शार्ड कू शकता (विभाजन तक्त्य), परंतु ते निर्देशांक कसे काम करतो यासाठी मूळ नाही.

हेड-टू-हेड: Oracle विरुद्ध Elasticsearch

पहलू	Oracle B-Tree	Elasticsearch Inverted Index
यासाठी सर्वोत्तम	अचूक जुळणी, श्रेणी क्वेरीज (WHERE id = 5, WHERE date BETWEEN X AND Y)	संपूर्ण-मजकूर शोध, प्रासंगिकता क्रमांकन, अस्पष्ट क्वेरीज
शोध प्रकार	बिंदू शोध	टर्म शोध
“शब्द X असलेले सर्व कागदपत्र शोधा” वर कार्यक्षमता	पूर्ण तक्ता स्कॅन (स्केलवर दर्दनाक)	उलटलेल्या निर्देशांकात हॅश शोध (नॅनोसेकंड)
डेटा संरचना	क्रमबद्ध वृक्ष, प्रति निर्देशांक एक स्तंभ	सपाट उलटलेला नकाशा, टर्म → कागदपत्र
स्केलिंग	उर्ध्व (मोठा सर्व्हर) किंवा मॅन्युअल शार्डिंग	क्षैतिज (अधिक नोड्स, अधिक शार्ड)
परिणाम प्रासंगिकतेनुसार क्रमांकित करा	नाही. जुळणी परत करतो, क्रमांकित नाही.	होय. डिफॉल्टनुसार TF-IDF आणि BM25 ने स्कोर करतो.
अपडेट खर्च	वृक्ष नोड्स पुन्हा संतुलन करा (O(log N))	प्रभावित पोस्टिंग सूचीचे पुनर्लेखन
संरचित डेटासाठी योग्य	होय, हे त्याच्यासाठी इष्ट आहे.	इष्ट नाही. अर्ध-संरचित / मजकूरसाठी चांगले.

हे का महत्त्वाचे आहे

मी संपूर्ण-मजकूर शोध Oracle ला ट्रिगर आणि कस्टम तक्त्यांच्या साथ जोडण्याचा प्रयत्न करणारी संघे पाहिली आहेत. हे काम करते, क्षीणपणे. किंवा ते Oracle चा संपूर्ण-मजकूर निर्देशांकन (CTXSYS) वापरतात, जो हिरावा आणि महाग आहे [1].

त्यानंतर त्यांना समान कार्यभार Elasticsearch ला हलविल्याचा आश्चर्य होतो की ते 100x जलद का आहे. हे जादू नाही. कारण Elasticsearch चे डेटा संरचना समस्येसाठी डिझाइन केले आहे.

उलट, जर तुम्ही ACID व्यवहार आणि सामान्य डेटावर जटिल जुळणी करत असाल, तर Elasticsearch चा गलत साधन आहे. हे Oracle च्या पद्धतीने सुसंगतता हमी देत नाही. हे अंतिम-सुसंगत आहे. कोणतेही व्यवहार नाही. कोणत्याही परदेशी की नाही.

प्रत्येक कधी वापर करायचा

Oracle (किंवा Postgres, MySQL, SQL Server) वापरा जेव्हा:

डेटा संरचित आणि संबंधित आहे
तुम्हाला ACID हमी आवश्यक आहे
क्वेरीज अचूक आहेत (अचूक जुळणी, श्रेणी)
तुमच्याकडे < 1TB तप्त डेटा आहे

Elasticsearch वापरा जेव्हा:

तुम्ही मजकूर किंवा लॉग निर्देशांकित करत आहात
वापरकर्ते अचूक मूल्यांशिवाय मुख्यशब्दांसह शोध करतात
तुम्हाला प्रासंगिकता क्रमांकन आवश्यक आहे
तुम्हाला अरब कागदपत्रांमध्ये क्षैतिजपणे मापन करायचे आहे

बरेच प्रकल्प दोन्ही वापरतात. व्यवहारिक डेटासाठी Oracle, शोध स्तरावर Elasticsearch.

गोंधळ या वस्तुस्थितीतून आहे की त्यांना दोन्हीला “निर्देशांक” असे म्हणतात. ते समान नाहीत. एक वृक्ष जो मूल्य क्रमबद्ध करतो. दुसरा एक उलटलेला नकाशा जो कागदपत्र मुख्यशब्दांनी गटबद्ध करतो. भिन्न समस्या, भिन्न समाधान.

समाप्त