शब्दकोश वेबसाइट के लिए MySQL का उपयोग एक बुरा विचार क्यों है?

Question

मैं शब्दकोश प्रविष्टियों (आमतौर पर एकल शब्द) और उनके अर्थ को किसी अन्य भाषा में संग्रहीत करने के लिए डेटाबेस को डिज़ाइन और सेट करने की योजना बना रहा हूं। इसलिए, उदाहरण के लिए, तालिका शब्दावली में प्रविष्टि और परिभाषा होनी चाहिए और प्रत्येक तालिका रिकॉर्ड में संग्रहीत रिकॉर्ड की आईडी का संदर्भ होता है Tag(प्रत्येक प्रविष्टि में एक टैग या श्रेणी होनी चाहिए)।

चूंकि मेरे डेटा में एक संरचना है, मैंने सोचा कि एक SQL डेटाबेस (जैसे MySQL) का उपयोग करना एक बुरा विचार नहीं है; लेकिन लोग कहते हैं कि प्रदर्शन के लिए MongoDB ज्यादा बेहतर है।

क्लाइंट की ओर से, एप्लिकेशन को स्वतः पूर्ण के साथ एक खोज बॉक्स प्रदान करने में सक्षम होना चाहिए जो बैकएंड द्वारा प्रदान की गई REST API का उपभोग करता है। क्या ऐसे परिदृश्य में MySQL के साथ जाना सुरक्षित है? या मुझे इसके लिए किसी अन्य समाधान के MongoDB या लोचदार खोज का उपयोग करना चाहिए? इस तरह से सौ-हज़ार रिकॉर्ड संग्रहीत और एक्सेस किए जाने चाहिए।

Comments

आपको बताने वाले लोगों ने इस पर ज्यादा शोध नहीं किया है। अंग्रेजी की सबसे बड़ी शब्दावली वाली भाषा में एक लाख से भी कम शब्द हैं। यह एक संबंधपरक DB की प्रदर्शन क्षमताओं के दायरे में अच्छी तरह से है।

— कैटरवर्जर

मैं यहाँ कुछ भी नहीं देख रहा हूँ जो मुझे लगता है कि MySQL उस के लिए ठीक काम नहीं करेगा। एक साधारण लुकअप पर प्रदर्शन एक मुद्दा नहीं होगा, और यदि आपको उस मार्ग पर जाने की आवश्यकता है तो इसकी पूर्ण पाठ खोज है।

— ग्रैंडमास्टरबी

"MongoDB प्रदर्शन के लिए बहुत बेहतर है" - एक बिना किसी गुंजाइश के स्पष्टीकरण के साथ एक असंसदीय कथन है, यह रैंक बकवास है। एक उदाहरण के लिए, देखें कि कमांड-लाइन टूल्स आपके Hadoop क्लस्टर की तुलना में 235x तेज़ हो सकते हैं (जो कि मैं वेबसाइट मोटापा संकट में एक लिंक से आया था )।

— वाइल्डकार्ड

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

— ब्रैंडन

@Brandon दुखद बात यह है कि पूरे "NoSQL बहुत तेज है" दावे आमतौर पर कुछ सैद्धांतिक स्पष्टीकरण के लिए उबालते हैं कि उन्हें इतना बेहतर क्यों होना चाहिए, लेकिन व्यवहार में जो कई वास्तविक दुनिया परिदृश्यों के लिए भी लागू नहीं होता है। जैसे देखें यहाँ । उनका इस्तेमाल किया बेंचमार्क सूट खुला स्रोत है और जीथब पर भी उपलब्ध है। नर्क सर्न उनके PB के डेटा को OracleDB के साथ ठीक करता है।

— वू

Answer 1

मैं आपको यह नहीं बता सकता कि यह एक बुरा विचार क्यों है। मैं आपको कारणों का एक गुच्छा बता सकता हूं कि क्यों एक संबंधपरक डेटाबेस एक अच्छा विचार है।

1. याद रखें कि हर कोई एक परिभाषा के लिए एक शब्दकोश नहीं देता है। अधिक बार नहीं, सही वर्तनी खोजने के लिए एक शब्दकोश का उपयोग किया जाता है। इसका मतलब है कि आप केवल एक घास का मैदान में सुई नहीं ढूंढ रहे हैं, आप उन सुइयों की खोज कर रहे हैं जो उपयोगकर्ता द्वारा वर्णित एक के समान हैं (यदि मैं एक मुहावरे का उपयोग कर सकता हूं)।

   आप केवल प्राथमिक कुंजी लुक-अप नहीं करेंगे। आप कीवर्ड खोज कर रहे हैं

2. शब्द संबंधित हो सकते हैं, या तो अर्थ या वर्तनी में हो सकते हैं ( पढ़ें, पढ़ें , लाल और रीड )

   जब भी आप शब्द "संबंधित" सोचते हैं "संबंधपरक डेटाबेस"

3. यदि आपको गति की आवश्यकता है, तो आपको अपने रिलेशनल डेटाबेस के शीर्ष पर कैशिंग की आवश्यकता है, न कि टूटे हुए रिलेशनल डेटा मॉडल की

4. एक सामान्य रूप से सामान्यीकृत डेटाबेस प्राथमिक कुंजी लुक-अप और खोजों को गति देता है क्योंकि वहाँ से गुजरने के लिए बस कम बिट्स हैं।

5. जो लोग सामान्यीकृत डेटाबेस कहते हैं वे धीमे हैं वे 0.1% मामलों का उल्लेख करते हैं जहां यह सच है। अन्य 99.9% मामलों में उन्होंने वास्तव में प्रदर्शन को पहले हाथ से देखने के लिए वास्तव में सामान्यीकृत डेटाबेस के साथ काम नहीं किया है, इसलिए उन्हें अनदेखा करें। मैंने एक सामान्यीकृत डेटाबेस के साथ काम किया है। इसे प्यार करना। वापस जाना नहीं चाहता। और मैं एक डेटाबेस आदमी नहीं हूँ। मैं C # / JavaScript / HTML / Ruby लड़का हूं।

6. शब्दों की एक उत्पत्ति होती है। वास्तव में, एक ही भाषा के कई शब्दों की एक ही उत्पत्ति हो सकती है, जो कि एक अलग भाषा में एक और शब्द है। उदाहरण के लिए, रिज्यूम (जिस चीज को हम रिक्रूटर्स वेबसाइट पर अपलोड करते हैं, ताकि हम लगातार 7 साल तक लगातार फोन कॉल और ई-मेल प्राप्त कर सकें) एक फ्रांसीसी शब्द है।

7. एक शब्दकोश यह भी परिभाषित करता है कि यह किस तरह का शब्द है (संज्ञा, क्रिया, विशेषण ect)। यह केवल पाठ का एक टुकड़ा नहीं है: "संज्ञा" इसका अर्थ भी है। इसके अलावा एक संबंधपरक डेटाबेस के साथ आप "अंग्रेजी भाषा के लिए मुझे सभी संज्ञाएं" जैसी चीजें कह सकते हैं और चूंकि एक सामान्यीकृत डेटाबेस विदेशी कुंजी का उपयोग कर रहा होगा, और विदेशी कुंजी में (या होना चाहिए) अनुक्रमित हैं, लुकअप एक स्नैप होगा।

8. सोचें कि शब्दों का उच्चारण कैसे किया जाता है। विशेष रूप से अंग्रेजी में, बहुत सारे शब्दों का एक ही उच्चारण है (ऊपर पढ़ें और रीड के साथ मेरा उदाहरण देखें, या पढ़ें और लाल)।

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

9. और अब शब्दों के बहुवचन और एकवचन संस्करणों के बारे में बात करते हैं। :) "नाव" और "नावों" पर विचार करें। या बहुत तथ्य यह है कि एक शब्द "एकवचन" या "बहुवचन" है।

10. ओह! और अब बात करते हैं भूत काल, वर्तमान काल, भविष्य काल और वर्तमान कृदंत (ईमानदार होने के लिए, मुझे नहीं पता कि बकवास "वर्तमान कृदंत" क्या है। मुझे लगता है कि इसका "इग" में समाप्त होने वाले शब्दों से कुछ लेना देना है। अंग्रेजी या कुछ)।

    "रन" देखें और आपको अन्य काल को देखना चाहिए: दौड़ा हुआ, दौड़ता हुआ, दौड़ता हुआ

    वास्तव में, "तनाव" स्वयं एक और संबंध है।

11. अंग्रेजी ऐसा नहीं करती है, लेकिन लिंग एक और चीज है जो एक शब्द को परिभाषित करता है। स्पेनिश जैसी भाषाओं ने परिभाषित किया है कि क्या संज्ञा का विषय पुरुष या महिला है। यदि आपको एक वाक्य के लिए रिक्त स्थान भरने की आवश्यकता है, तो कई भाषाओं में लिंग अत्यंत महत्वपूर्ण है।

    चूंकि आप हमेशा लिंग निर्धारण के लिए भाषा सम्मेलनों पर भरोसा नहीं कर सकते हैं (स्पेनिश में, "ओ" में समाप्त होने वाले शब्द पुल्लिंग / पुरुष हैं, लेकिन यह सभी शब्दों के लिए सच नहीं है), आपको एक पहचान मूल्य की आवश्यकता है: पुरुष या महिला। यह एक और संबंध है जो एक सामान्यीकृत डेटाबेस लाखों रिकॉर्ड पर भी इनायत से संभालता है।

शब्दों, और यहां तक ​​कि विभिन्न भाषाओं के बीच सभी मुड़ नियमों और संबंधों के साथ, मेरे लिए इस डेटा स्टोर को "दस्तावेज़ स्टोर" के रूप में कल्पना करना मुश्किल है जैसे कि कोई नो-एसक्यूएल समाधान प्रदान नहीं करता है। शब्दों और उनके घटकों के बीच इतने सारे और इतने बड़े संबंध हैं कि एक संबंधपरक डेटाबेस एकमात्र समझदार समाधान है।

Comments

# 1 के लिए, अनुक्रमण अक्सर गैर-संबंधपरक प्रसाद की ताकत में से एक है, न कि कमजोरी।

— जिम्मीजम्स

@ जिमीजम्स एक मिनट के लिए नहीं सोचते हैं कि रिलेशनल सिस्टम एक ही तरह के इंडेक्स का उपयोग नहीं कर रहे हैं। उन तकनीकों में से कई उस दुनिया में अग्रणी थीं।

— ब्लर

"जब भी आप" संबंधित "सोचें" संबंधित डेटाबेस "शब्द देखें। मैं सहमत नहीं हूँ। "रिलेशनल डेटाबेस" में "रिलेशनल" खुद को टुपल्स को संदर्भित करता है। इस कथन के लिए किसी भी पानी को धारण करने के लिए संबंधित शब्द बहुत व्यापक है

— गार्डेनहुड

ग्राफ डेटाबेस भी हैं (Neo4j दिमाग में आता है) जो स्पष्ट रूप से पारंपरिक जुड़ाव प्रदर्शन करने के बजाय रिश्तों पर ध्यान केंद्रित करते हैं। यह लाभप्रद हो सकता है कि कई शब्दकोश वास्तव में शब्दों के जाल हैं; उदाहरण के लिए, WordNet प्रोजेक्ट एक पारंपरिक RDMS के बजाय अपने स्वयं के ग्राफ़ जैसे प्रारूप का उपयोग करता है।

— ट्यूक्सी

मैंने इस उत्तर को केवल "जब भी आप 'संबंधित' विचार 'संबंधपरक डेटाबेस' देखते हैं, के लिए अस्वीकृत कर दिया ।" यह हास्यास्पद है । मुझे रिलेशनल डेटाबेस पसंद हैं, लेकिन रिलेशनल मॉडल सभी प्रकार के रिश्तों के लिए उपयुक्त नहीं है । सामान्यीकृत डेटा के बारे में आपका दृष्टिकोण भी पूरी तरह से गलत है। डेटा को सामान्य करने से संपादन का अनुकूलन होता है , क्योंकि डेटा को डुप्लिकेट नहीं किया जाता है, खोज नहीं। (यही कारण है कि DBs की रिपोर्टिंग सामान्य नहीं है। वे आयामी मॉडलिंग तकनीकों और स्टार स्कीमा का उपयोग करते हैं।) मुझे नहीं लगता कि आप जानते हैं कि आप किस बारे में बात कर रहे हैं। 80 upvotes इस साइट पर सलाह के बारे में मेरी सभी चिंताओं की पुष्टि करते हैं।

— jpmc26

Answer 2

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

यदि आप एक रिलेशनल डेटाबेस के साथ शुरू करते हैं, तो आप अपने एप्लिकेशन के डिज़ाइन, कोड के माध्यम से काम कर सकते हैं, और इसे अपने एप्लिकेशन के लिए प्राकृतिक डेटा मॉडल पर अधिक ध्यान केंद्रित करने की कोशिश कर सकते हैं, बजाय इसके कि-वैल्यू फॉर्म में जूता-बूट करने पर।

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

यदि यह पता चलता है कि कुंजी-मूल्य वास्तव में आपके आवेदन की आवश्यकता है, तो आप संबंधपरक मॉडल में महत्वपूर्ण निवेश को बर्बाद किए बिना स्विच कर सकते हैं, जबकि आपके आस-पास का दूसरा तरीका संभवतः कुंजी-मूल्य मॉडल बनाने वाले समय बर्बाद कर सकता है जो कि हैं संबंधपरक मॉडल में तुच्छ।

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

जब आपके पास लाखों उपयोगकर्ता होते हैं, तो आपको लगभग निश्चित रूप से डिज़ाइन को फिर से बनाने की आवश्यकता होगी, भले ही आपने शुरू करने के लिए कुंजी-मूल्य चुना हो।

Comments

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

— डेरेक एल्किंस

सारा का MongoDB लेख ठीक वैसा ही है जैसा हमने 1.0 उत्पाद के साथ गुजारा था जिसे हमने इस्तेमाल करके बनाया था; 1.1 तक हम पोस्टग्रैज का उपयोग कर रहे थे।

— जो

@DerekElkins, सुपर संदर्भ, thx!

— एरिक एदट

"लेकिन फिर यह बताता है कि आवश्यकताओं में एक अपेक्षाकृत मामूली बदलाव कैसे आरडीबीएमएस में लागू करने के लिए तुच्छ होगा" ज़रूर, लेकिन विपरीत सच है। हम कार्यस्थल पर RDBMS का उपयोग करते हैं और उन मुद्दों का सामना करते हैं जो MongoDB में हल करने के लिए तुच्छ होंगे। अजीब तरह से, सॉफ़्टवेयर आवश्यकताएँ हमेशा हमारे द्वारा उपयोग किए जाने वाले टूल की क्षमताओं के लिए पूरी तरह से मैप नहीं होती हैं।

— NPSF3000 4

@ NPSF3000, यह भयानक होगा यदि आप एक संदर्भ का हवाला दे सकते हैं, जैसे एक ब्लॉग या कुछ पाठ जो उस पर विस्तृत है!

— एरिक इद्दत

Answer 3

एक डेटाबेस के लिए यह छोटा है, यह संभवतः प्रदर्शन के लिए बहुत अधिक अंतर नहीं करेगा। एक मानक RDBMS यहाँ एक भयानक विचार नहीं है क्योंकि संभवतः, किसी दिए गए प्रविष्टि के लिखने की तुलना में कहीं अधिक पढ़ना चाहिए। प्रदर्शन इसके लिए एक प्राथमिक चालक नहीं लगता है। एप्लिकेशन परत में कैशिंग भी इस तरह की चिंताओं को कम करता है।

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

Comments

कैप एक सामान्य सामान्य वेब ऐप पर कैसे लागू होता है? आपकी किट के आधार पर यह संभावना है कि आप हजारों इनबाउंड कनेक्शन बनाए रख सकते हैं और एक पृष्ठ कैशिंग परत मैग्नेटुइड के एक आदेश से बढ़ सकती है। कैप केवल कुछ बनना शुरू करता है जिस पर आपको विचार करने की आवश्यकता है जब वितरित सिस्टम आपके उद्देश्य को प्राप्त करने का एकमात्र तरीका है।

— बेन

@Ben Resiliency अपने आप में एक उद्देश्य है। यदि विफलता का एक भी बिंदु एक आवेदन के लिए स्वीकार्य नहीं है, तो वितरित समाधान एक समाधान प्रदान करते हैं। गैर-आरडीबीएमएस समाधान इस ओर अधिक उन्मुख होते हैं। यह केवल विचार करने के लिए वॉल्यूम नहीं है। विलंबता और उपलब्धता चिंताएं हैं। यदि आपकी आवश्यकता 99.9% अपटाइम करने की है। आप केवल एक वर्ष में लगभग 9 घंटे के लिए नीचे जा सकते हैं और एक डीबी में डेटा खोना आपत्तिजनक है इसलिए आपको प्रतिकृति / बैकअप / स्नैपशॉट के लिए खाते की आवश्यकता है। यह सोचने के लिए गुमराह है कि यह चीजों को सरल बनाता है।

— जिम्मीजम्स

Answer 4

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

यह शुरू में एक संबंधपरक डेटाबेस के साथ जाने और फिर बाद में नामंजूर करने के लिए एक सुरक्षित विकल्प होगा। इस प्रकार के उद्देश्य के लिए MySQL भयानक है (पाठ-आधारित खोज के साथ सरल संबंधपरक डेटाबेस), बहुत अधिक उपयोग-मामले नहीं हैं जहां आप इसे इस प्रकार के डेटा के साथ संघर्ष कर पाएंगे। बस यह सुनिश्चित करें कि आपके पास अपने इंडेक्स सही तरीके से सेट हैं और आप पाएंगे कि यह NoSQL डेटाबेस में एक तुलनीय (या पाठ खोज करते समय बेहतर) स्तर पर प्रदर्शन करेगा, और यह आपको आपके ऐप लॉजिक को संशोधित किए बिना लचीलापन देगा एक ठोस डेटा संरचना के लिए बाध्य।

जैसा कि आप अपने डेटा का सबसे आम उपयोग पाते हैं (और यदि आप कभी पाते हैं कि यह आपकी प्रदर्शन आवश्यकताओं को पूरा नहीं कर रहा है), तो आप एक सेट प्रारूप में आउटपुट करके डेटा को सामान्य करने के लिए आगे बढ़ सकते हैं जिसे लोड किया जा सकता है (और से पुनर्प्राप्त) एक NoSQL स्कीमा।