Elasticsearch
अंतर और प्रकार के बीच अंतर

C# Language Django Java Language MongoDB Node.js PHP Python Language Ruby Language Ruby on Rails symfony2
खोज…


टिप्पणियों

यह एसक्यूएल डेटाबेस में तालिका की तरह type एस को देखना आसान है, जहां index एसक्यूएल डेटाबेस है। हालाँकि, यह एस type दृष्टिकोण के लिए एक अच्छा तरीका नहीं है।

सभी प्रकार के बारे में

वास्तव में, टाइप्स का शाब्दिक अर्थ है केवल एक मेटाडेटा फ़ील्ड जिसे _type द्वारा प्रत्येक दस्तावेज़ में जोड़ा गया है: _type । ऊपर दिए गए उदाहरणों ने दो प्रकार बनाए: my_type और my_other_type । इसका मतलब है कि प्रत्येक प्रकार के साथ जुड़े दस्तावेज़ में एक अतिरिक्त फ़ील्ड है जो स्वचालित रूप से "_type": "my_type" जैसे परिभाषित किया गया है "_type": "my_type" ; यह दस्तावेज़ के साथ अनुक्रमित है, इस प्रकार यह एक खोज योग्य या फ़िल्टर करने योग्य क्षेत्र बना रहा है , लेकिन यह कच्चे दस्तावेज़ को स्वयं प्रभावित नहीं करता है, इसलिए आपके आवेदन को इसके बारे में चिंता करने की आवश्यकता नहीं है।

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

जैसे, केवल एक ही प्रकार को परिभाषित करने के लिए एक सर्वोत्तम अभ्यास है जब तक कि आपको वास्तव में अन्य प्रकार की आवश्यकता न हो। उन परिदृश्यों को देखना आम है जहां कई प्रकार वांछनीय हैं। उदाहरण के लिए, कल्पना कीजिए कि आपके पास कार इंडेक्स था। इसे कई प्रकारों से तोड़ना आपके लिए उपयोगी हो सकता है:

  • बीएमडब्ल्यू
  • आखेट
  • होंडा
  • माजदा
  • मर्सिडीज
  • निसान
  • रेंज रोवर
  • टोयोटा
  • ...

इस तरह आप सभी कारों को खोज सकते हैं या निर्माता द्वारा मांग पर सीमित कर सकते हैं। उन दो खोजों के बीच अंतर उतना ही सरल है: 

GET /cars/_search

तथा 

GET /cars/bmw/_search

एलिस्टिक्स खोज के नए उपयोगकर्ताओं के लिए जो स्पष्ट नहीं है, वह यह है कि दूसरा रूप पहले रूप की विशेषता है। यह सचमुच के लिए फिर से लिखा जाता है: 

GET /cars/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "term" : {
            "_type": "bmw"
          }
        }
      ]
    }
  }
}

यह बस किसी भी दस्तावेज़ को फ़िल्टर करता है जिसे _type फ़ील्ड के साथ अनुक्रमित नहीं किया गया था जिसका मूल्य bmw था। चूंकि प्रत्येक दस्तावेज़ को _type फ़ील्ड के रूप में इसके प्रकार के साथ अनुक्रमित किया जाता है, यह एक बहुत ही सरल फ़िल्टर के रूप में कार्य करता है। यदि कोई वास्तविक खोज या तो उदाहरण में प्रदान की गई थी, तो उपयुक्त के रूप में पूर्ण खोज में फ़िल्टर जोड़ा जाएगा।

जैसे, यदि प्रकार समान हैं, तो एकल प्रकार (जैसे, इस उदाहरण में manufacturer ) की आपूर्ति करना बेहतर है और इसे प्रभावी रूप से अनदेखा करें। फिर, प्रत्येक दस्तावेज़ के भीतर, स्पष्ट रूप से जब भी आप इसे सीमित करना चाहते हैं, तो एक फ़ील्ड make जिसे आप पसंद करते make या जो भी नाम आप पसंद करते हैं और मैन्युअल रूप से उस पर फ़िल्टर करें। यह आपके मैपिंग के आकार को 1/n कम कर देगा जहां n अलग-अलग प्रकार की संख्या है। यह अन्यथा सरल सरलीकृत मानचित्रण के लाभ पर प्रत्येक दस्तावेज़ में एक और फ़ील्ड जोड़ता है।

इलास्टिक्स खोज 1.x और 2.x में, इस तरह के क्षेत्र को परिभाषित किया जाना चाहिए 

PUT /cars
{
  "manufacturer": { <1>
    "properties": {
      "make": { <2>
        "type": "string",
        "index": "not_analyzed"
      }
    }
  }
}
  1. नाम मनमाना है।
  2. नाम मनमाना है और यदि आप इसे चाहते हैं तो यह प्रकार के नाम से मेल खा सकता है।

इलास्टिक्स खोज 5.x में, ऊपर अभी भी काम करेगा (यह पदावनत है), लेकिन इसका उपयोग करने का बेहतर तरीका है: 

PUT /cars
{
  "manufacturer": { <1>
    "properties": {
      "make": { <2>
        "type": "keyword"
      }
    }
  }
}
  1. नाम मनमाना है।
  2. नाम मनमाना है और यदि आप इसे चाहते हैं तो यह प्रकार के नाम से मेल खा सकता है।

आपके सूचकांकों के भीतर प्रकारों का संयम से इस्तेमाल किया जाना चाहिए क्योंकि यह इंडेक्स मैपिंग को आमतौर पर बिना अधिक लाभ के उड़ा देता है। आपके पास कम से कम एक होना चाहिए, लेकिन ऐसा कुछ भी नहीं है जो कहता है कि आपके पास एक से अधिक होना चाहिए।

सामान्य प्रश्न

  • क्या होगा यदि मेरे पास दो (या अधिक) प्रकार हैं जो ज्यादातर समान हैं, लेकिन जिनके पास प्रति प्रकार कुछ अद्वितीय फ़ील्ड हैं?

सूचकांक स्तर पर, कुछ प्रकारों के साथ उपयोग किए जा रहे एक प्रकार के बीच कोई अंतर नहीं है जो कि बहुत कम उपयोग किए जाते हैं और कई प्रकारों के बीच जो गैर-विरल फ़ील्डों का एक गुच्छा साझा करते हैं जिनमें कुछ भी साझा नहीं किया गया है (जिसका अर्थ है कि दूसरा प्रकार कभी भी फ़ील्ड का उपयोग नहीं करता है (रों))।

अलग ढंग से कहा: एक दुर्लभ उपयोग किया गया क्षेत्र प्रकारों की परवाह किए बिना सूचकांक में विरल है। स्पार्सिटी का लाभ नहीं होता है - या वास्तव में चोट लगी है - सूचकांक सिर्फ इसलिए कि यह एक अलग प्रकार में परिभाषित किया गया है।

आपको बस इन प्रकारों को संयोजित करना चाहिए और एक अलग प्रकार का क्षेत्र जोड़ना चाहिए।

  • फ़ील्ड को सटीक रूप से परिभाषित करने के लिए अलग-अलग प्रकार की आवश्यकता क्यों है?

क्योंकि प्रत्येक क्षेत्र वास्तव में केवल ल्यूसीन स्तर पर एक बार परिभाषित होता है, भले ही कितने प्रकार के हों। यह तथ्य कि सभी प्रकार मौजूद हैं, एलीटेसर्च की एक विशेषता है और यह केवल एक तार्किक अलगाव है।

  • क्या मैं एक ही क्षेत्र को अलग-अलग प्रकार से परिभाषित कर सकता हूं?

नहीं। यदि आप ES 2.x या बाद में ऐसा करने का तरीका ढूंढते हैं, तो आपको बग रिपोर्ट खोलनी चाहिए । जैसा कि पिछले प्रश्न में उल्लेख किया गया था, ल्यूसीन उन सभी को एक ही क्षेत्र के रूप में देखता है, इसलिए इस काम को उचित तरीके से करने का कोई तरीका नहीं है।

ES 1.x ने इसे एक अंतर्निहित आवश्यकता के रूप में छोड़ दिया, जिसने उपयोगकर्ताओं को ऐसी स्थिति बनाने की अनुमति दी जहां एक सूचकांक में एक शार्क के मैपिंग वास्तव में एक ही सूचकांक में दूसरे शार्क से अलग थे। यह प्रभावी रूप से एक दौड़ की स्थिति थी और यह अप्रत्याशित मुद्दों को जन्म दे सकती थी।

नियम के अपवाद

  • माता-पिता / बच्चे के दस्तावेजों को एक ही सूचकांक के भीतर उपयोग करने के लिए अलग-अलग प्रकार की आवश्यकता होती है ।
    • माता-पिता एक प्रकार से रहते हैं।
    • बच्चा एक अलग प्रकार में रहता है (लेकिन प्रत्येक बच्चा अपने माता-पिता के समान शार्प में रहता है)।
  • अत्यधिक आला उपयोग के मामले जहां सूचकांक बनाना टन अवांछनीय है और विरल क्षेत्रों का प्रभाव विकल्प के लिए बेहतर है।
    • उदाहरण के लिए, इलास्टिक्स खोज निगरानी प्लगइन, मार्वल (1.x और 2.x) या एक्स-पैक मॉनिटरिंग (5.x +), क्लस्टर, नोड्स, सूचकांकों, विशिष्ट सूचकांकों (सूचकांक स्तर) में परिवर्तन के लिए खुद ही इलास्टिसर्च की निगरानी करता है। और यहां तक कि शार्क भी। यह उन दस्तावेजों को अलग करने के लिए प्रत्येक दिन 5+ सूचकांक बना सकता है जिनके पास अद्वितीय मैपिंग है या यह एक इंडेक्स साझा करके क्लस्टर लोड को कम करने के लिए सर्वोत्तम प्रथाओं के खिलाफ जा सकता है (नोट: परिभाषित मैपिंग की संख्या प्रभावी रूप से एक ही है, लेकिन निर्मित सूचक की संख्या n से घटाकर 1) कर दिया गया है।
    • यह एक उन्नत परिदृश्य है, लेकिन आपको सभी प्रकार की साझा फ़ील्ड परिभाषाओं पर विचार करना चाहिए!

स्पष्ट रूप से एक प्रकार के साथ एक सूचकांक बनाना

उदाहरण मूल HTTP का उपयोग करता है, जो आसानी से cURL और अन्य HTTP अनुप्रयोगों में अनुवाद करता है। वे सेंस सिंटैक्स से भी मेल खाते हैं, जिसका नाम बदलकर किबाना 5.0 में कंसोल कर दिया जाएगा।

नोट: उदाहरण आवेषण <#> भागों पर ध्यान आकर्षित करने में मदद करने के लिए। यदि आप इसे कॉपी करते हैं तो उन्हें हटा दिया जाना चाहिए! 

PUT /my_index <1>
{
  "mappings": {
    "my_type": { <2>
      "properties": {
        "field1": {
          "type": "long"
        },
        "field2": {
          "type": "integer"
        },
        "object1": {
          "type": "object",
          "properties": {
            "field1" : {
              "type": "float"
            }
          }
        }
      }
    }
  },
  "my_other_type": {
    "properties": {
      "field1": {
        "type": "long" <3>
      },
      "field3": { <4>
        "type": "double"
      }
    }
  }
}
  1. यह पैदा कर रही है index सूचकांक समाप्ति बिंदु बनाने का उपयोग कर।
  2. यह type ।
  3. एक ही index भीतर type एस में साझा किए गए फ़ील्ड को समान परिभाषा साझा करनी चाहिए ! ES 1.x ने इस व्यवहार को कड़ाई से लागू नहीं किया, लेकिन यह एक अंतर्निहित आवश्यकता थी। ES 2.x और ऊपर सख्ती से इस व्यवहार को लागू करता है।
  4. type s के अनूठे क्षेत्र ठीक हैं।

अनुक्रमित (या सूचकांक) प्रकार होते हैं। दस्तावेज़ों को अलग करने के लिए प्रकार एक सुविधाजनक तंत्र हैं, लेकिन उन्हें आपको परिभाषित करने की आवश्यकता है - या तो गतिशील रूप से / स्वचालित रूप से या स्पष्ट रूप से - प्रत्येक प्रकार के लिए एक मानचित्रण जो आप उपयोग करते हैं। यदि आप एक इंडेक्स में 15 प्रकारों को परिभाषित करते हैं, तो आपके पास 15 अद्वितीय मैपिंग हैं।

इस अवधारणा के बारे में अधिक जानकारी के लिए टिप्पणियों को देखें और आप प्रकारों का उपयोग करना चाहते हैं या नहीं कर सकते हैं।

डायनामिक रूप से एक प्रकार के साथ एक सूचकांक बनाना

उदाहरण मूल HTTP का उपयोग करता है, जो आसानी से cURL और अन्य HTTP अनुप्रयोगों में अनुवाद करता है। वे सेंस सिंटैक्स से भी मेल खाते हैं, जिसका नाम बदलकर किबाना 5.0 में कंसोल कर दिया जाएगा।

नोट: उदाहरण आवेषण <#> भागों पर ध्यान आकर्षित करने में मदद करने के लिए। यदि आप इसे कॉपी करते हैं तो उन्हें हटा दिया जाना चाहिए! 

DELETE /my_index <1>

PUT /my_index/my_type/abc123 <2>
{
  "field1" : 1234, <3>
  "field2" : 456,
  "object1" : {
    "field1" : 7.8 <4>
  }
}
  1. यदि यह पहले से मौजूद है (पहले के उदाहरण के कारण), तो सूचकांक को हटा दें।
  2. सूचकांक सूचकांक में एक दस्तावेज़ my_index , प्रकार, साथ my_type , और आईडी abc123 (अंकीय हो सकता है, लेकिन यह हमेशा एक स्ट्रिंग है)।
    • डिफ़ॉल्ट रूप से, डायनामिक इंडेक्स निर्माण केवल एक दस्तावेज़ को अनुक्रमित करने से सक्षम होता है। यह विकास के वातावरण के लिए बहुत अच्छा है, लेकिन यह जरूरी नहीं है कि उत्पादन वातावरण के लिए अच्छा हो।
  3. यह फ़ील्ड पूर्णांक संख्या है, इसलिए पहली बार यह देखा जाता है कि इसे मैप किया जाना चाहिए। एलियस्टैसर्च हमेशा किसी भी आने वाले प्रकार के लिए सबसे व्यापक प्रकार को मानता है, इसलिए यह integer या short बजाय long मैप किया जाएगा (जिसमें दोनों में 1234 और 456 हो सकते हैं)।
  4. इस क्षेत्र के लिए भी यही सच है। यह float बजाय double रूप में मैप किया जाएगा जैसा कि आप चाहते हैं।

यह गतिशील रूप से बनाया गया सूचकांक और प्रकार मोटे तौर पर पहले उदाहरण में परिभाषित मानचित्रण से मेल खाता है। हालाँकि, यह समझना महत्वपूर्ण है कि <3> और <4> स्वचालित रूप से परिभाषित मैपिंग को कैसे प्रभावित करते हैं।

आप एक ही सूचकांक में गतिशील रूप से एक और प्रकार जोड़कर इसका अनुसरण कर सकते हैं: 

PUT /my_index/my_other_type/abc123 <1>
{
  "field1": 91, <2>
  "field3": 4.567
}
  1. उपरोक्त दस्तावेज़ से प्रकार केवल अंतर है। आईडी एक ही है और यह ठीक है! इसका अन्य abc123 से कोई अन्य संबंध नहीं है, क्योंकि यह उसी सूचकांक में होता है।
  2. field1 को पहले से ही, सूचकांक में मौजूद है तो यह क्षेत्र के एक ही प्रकार के रूप में अन्य प्रकार के रूप में परिभाषित किया जाना चाहिए। एक मान जमा करना जो एक स्ट्रिंग था या नहीं एक पूर्णांक विफल होगा (जैसे, "field1": "this is some text" या "field1": 123.0 )।

यह गतिशील रूप से my_other_type के लिए समान अनुक्रमणिका, my_index लिए मैपिंग my_index ।

नोट: यह हमेशा तेजी से मैपिंग को परिभाषित करने के बजाय तेजी से परिभाषित करने के बजाय एलिस्टिक्स खोज गतिशील रूप से इसे सूचकांक समय पर करता है।

दोनों दस्तावेजों को अनुक्रमित करने का अंतिम परिणाम पहले उदाहरण के समान होगा, लेकिन क्षेत्र के प्रकार अलग होंगे और इसलिए थोड़ा व्यर्थ होगा: 

GET /my_index/_mappings <1>
{
  "mappings": {
    "my_type": { <2>
      "properties": {
        "field1": {
          "type": "long"
        },
        "field2": {
          "type": "long" <3>
        },
        "object1": {
          "type": "object",
          "properties": {
            "field1" : {
              "type": "double" <4>
            }
          }
        }
      }
    }
  },
  "my_other_type": { <5>
    "properties": {
      "field1": {
        "type": "long"
      },
      "field3": {
        "type": "double"
      }
    }
  }
}
  1. यह हमारे द्वारा बनाए गए अनुक्रमणिका से मैपिंग प्राप्त करने के लिए _mappings समापन बिंदु का उपयोग करता है।
  2. हमने इस उदाहरण के पहले चरण में गतिशील रूप से my_type बनाया है।
  3. field2 अब integer बजाय एक long क्योंकि हमने इसे अग्रिम रूप से परिभाषित नहीं किया है। यह साबित डिस्क भंडारण में बेकार हो सकता है।
  4. object1.field1 अब # 3 के समान object1.field1 साथ # 3 के समान कारण के लिए एक double ।
    • तकनीकी रूप से, बहुत से मामलों में long संपीड़ित किया जा सकता है। हालाँकि, फ़्लोटिंग पॉइंट संख्या होने के कारण एक double को संपीड़ित नहीं किया जा सकता है।
  5. हमने इस उदाहरण के दूसरे चरण में गतिशील रूप से my_other_type बनाया है। इसकी मैपिंग समान होती है क्योंकि हम पहले से ही long और double उपयोग कर रहे थे।
    • याद रखें कि field1 से परिभाषा से मेल खाना चाहिए my_type (और यह करता है)।
    • field3 इस प्रकार के लिए अद्वितीय है, इसलिए इसमें ऐसा कोई प्रतिबंध नहीं है।


Modified text is an extract of the original Stack Overflow Documentation
के तहत लाइसेंस प्राप्त है CC BY-SA 3.0
से संबद्ध नहीं है Stack Overflow