उपरोक्त दोनों उत्तर महान हैं!
मैं एक इंडेक्स में कई प्रकार का एक उदाहरण जोड़ रहा हूं। मान लीजिए कि आप पुस्तकालय में पुस्तकों की खोज के लिए एक ऐप विकसित कर रहे हैं।
आप स्टोर करने के लिए कितनी पुस्तकें योजना बना रहे हैं: वहाँ लाइब्रेरी मालिक को पूछने के लिए कुछ सवाल,
सवाल कर रहे हैं?
लाइब्रेरी में आप किस प्रकार की किताबें स्टोर करने जा रहे हैं?
आप पुस्तकों की खोज कैसे कर रहे हैं?
उत्तर:
मैं 50 कश्मीर स्टोर करने के लिए योजना बना रहा हूँ - मैं 15 कश्मीर -20 कश्मीर प्रौद्योगिकी से संबंधित किताबें होगा 70 कश्मीर किताबें (लगभग)
लिए (कंप्यूटर साइंस , मैकेनिकल इंजीनियरिंग, रसायन इंजीनियरिंग और इतने पर), ऐतिहासिक किताबों के 15 के, चिकित्सा विज्ञान किताबों के 10 के। 10 कश्मीर की संबंधित भाषा की पुस्तकों (अंग्रेजी, स्पेनिश और इसी तरह)
लेखकों द्वारा खोजें प्रथम नाम, लेखक अंतिम नाम, प्रकाशित की साल, प्रकाशक का नाम। (यह आप क्या जानकारी सूचकांक में संग्रहीत करना चाहिए के बारे में विचार देता है)
ऊपर जवाब से हम कह सकते हैं हमारी सूची में स्कीमा कुछ हद तक इस तरह दिखना चाहिए।
// यह नहीं सटीक मानचित्रण, क्रम से ऊपर हम एक सूचकांक कहा जाता पुस्तकें बना सकते हैं और विभिन्न प्रकार हो सकता है प्राप्त करने के लिए है सिर्फ उदाहरण
"yearOfPublish":{
"type": "integer"
},
"author":{
"type": "object",
"properties": {
"firstName":{
"type": "string"
},
"lastName":{
"type": "string"
}
}
},
"publisherName":{
"type": "string"
}
}
के लिए।
सूचकांक: पुस्तक
प्रकार: विज्ञान, कला
(यदि आप बहुत अधिक पुस्तकें हैं या आप इस तरह के प्रौद्योगिकी, चिकित्सा विज्ञान, हिस्ट्री, भाषा के रूप में कई प्रकार बना सकते हैं,)
महत्वपूर्ण यहां ध्यान देने योग्य बात यह है कि स्कीमा समान है लेकिन डेटा समान नहीं है। और दूसरी महत्वपूर्ण बात यह है कि आप जो डेटा एकत्र कर रहे हैं वह है।
आशा है कि उपर्युक्त सूचकांक में विभिन्न प्रकारों के लिए जाने पर सहायता करता है, यदि आपके पास अलग-अलग स्कीमा हैं तो आपको अलग-अलग इंडेक्स पर विचार करना चाहिए। कम डेटा के लिए लघु सूचकांक। :-)
यह उत्तर http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/mapping.html – AndreKR
से जानकारी के बिना पूरा नहीं हुआ है। धन्यवाद! – Vinay
उत्कृष्ट उत्तर में जोड़ने के लिए, मैं ** ES 5.2 दस्तावेज़ ** से उद्धरण देता हूं जो बताता है कि बड़ी संख्या में शारों को बनाए रखने की सिफारिश क्यों नहीं की जाती है: "डिफ़ॉल्ट रूप से लोचदार खोज से 1000 से अधिक शर्ड्स पूछे जाने वाले खोज अनुरोधों को अस्वीकार कर दिया जाता है। कारण यह है कि इस तरह की बड़ी संख्या में शोर समन्वय नोड का काम बहुत सीपीयू और मेमोरी गहन बनाता है। आमतौर पर डेटा को व्यवस्थित करने का एक बेहतर विचार है कि कम बड़े शर्ड्स हैं। यदि आप इस सीमा को बाईपास करना चाहते हैं, जो कि है निराश, आप action.search.shard_count.limit क्लस्टर सेटिंग को अधिक मूल्य पर अपडेट कर सकते हैं। ' – oblivion