benchANT compares MongoDB and ScyllaDB architectures, with a focus on what the differences mean for performance and scalability एक NoSQL डेटाबेस चुनते समय, विकल्प भारी हो सकते हैं. सबसे लोकप्रिय विकल्पों में से एक MongoDB है, जिसका उपयोग करने में आसान होने के लिए जाना जाता है. लेकिन उच्च प्रदर्शन उन्मुख ScyllaDB बढ़ते चुनौतियों में से एक है. यह रिपोर्ट दोनों डेटाबेस पर एक करीब तकनीकी नज़र डालती है - उनकी वास्तुकलाओं को एक स्वतंत्र, तकनीकी कोण से तुलना करती है। बेंचैन MongoDB और ScyllaDB दोनों एक उच्च उपलब्धता, प्रदर्शन और स्केलेबल आर्किटेक्चर का वादा करते हैं. लेकिन वे इन लक्ष्यों को प्राप्त करने का तरीका पहली नज़र में सोचने से बहुत अलग है. उदाहरण के लिए, एक अनुभव रिपोर्ट दिखाती है कि ScyllaDB को अपने वितरित आर्किटेक्चर के लिए धन्यवाद AWS EC2 स्पॉट इंस्टेंट्स पर आसानी से कैसे संचालित किया जा सकता है, जबकि MongoDB की वितरित आर्किटेक्चर इसे एक बहुत ही चुनौतीपूर्ण कार्य बना देगी। इन मतभेदों को उजागर करने के लिए, हम आंतरिक भंडारण वास्तुकला और वितरित वास्तुकलाओं पर गहराई से चर्चा प्रदान करते हैं जो उच्च उपलब्धता और क्षैतिज स्केलिंग की अनुमति देते हैं। हमने अभी भी इन मतभेदों के प्रभाव की मात्रा निर्धारित करने वाले एक बेंचमार्क जारी किया है। Note: DynamoDB vs MongoDB Benchmark संक्षिप्त पढ़ें इस तुलना रिपोर्ट को डाउनलोड करें Read the DynamoDB vs MongoDB Benchmark Summary DynamoDB vs MongoDB Benchmark संक्षिप्त पढ़ें Download this Comparison Report इस तुलना रिपोर्ट को डाउनलोड करें MongoDB vs ScyllaDB के भंडारण वास्तुकला पर एक प्रदर्शन दृष्टिकोण दोनों डेटाबेस सी ++ में लागू होते हैं और एक्सएफएस फ़ाइल सिस्टम का उपयोग करने की सिफारिश करते हैं। , ScyllaDB terminology में Commit Log और MongoDB terminology में Oplog. with write-ahead-logging, all operations are written to a log table before the operation is executed. write-ahead-log अन्य नोड्स में डेटा को पुनः प्राप्त करने के लिए एक स्रोत के रूप में कार्य करता है, और यह विफलताओं के मामले में डेटा को पुनर्स्थापित करने के लिए उपयोग किया जाता है क्योंकि डेटा को पुनर्स्थापित करने के लिए ऑपरेशन 'replay' करना संभव है. लिखने-पहले-लॉगिंग अवधारणा MongoDB डिफ़ॉल्ट स्टोरेज इंजन के रूप में डेटा स्टोरेज और रिकॉर्डिंग के लिए एक B+-Tree इंडेक्स (Wired Tiger) का उपयोग करता है. B+-Tree इंडेक्स संतुलित पेड़ डेटा संरचनाएं हैं जो डेटा को एक व्यवस्थित क्रम में संग्रहीत करते हैं, जिससे रेंज-आधारित पूछताछ को संचालित करना आसान होता है. MongoDB एक संग्रह पर कई इंडेक्स का समर्थन करता है, जिसमें यौगिक इंडेक्स, पाठ इंडेक्स और भौगोलिक इंडेक्स शामिल हैं. पैराइज़ तत्वों और निहित क्षेत्रों का इंडेक्सिंग भी संभव है, जो जटिल डेटा संरचनाओं पर कुशल पूछताछ की अनुमति देता है. इसके अलावा ScyllaDB डेटा को टुकड़ों में विभाजित करता है, एक नोड में कुल डेटा के एक टुकड़े को एक विशिष्ट CPU को, साथ ही इसके संबंधित मेमोरी (RAM) और स्थायी भंडारण (जैसे NVMe SSD) के साथ विभाजित करता है। ScyllaDB का आंतरिक भंडारण इंजन एक डिस्क स्थायी कमिट लॉग के साथ-साथ स्मृति आधारित स्मृति आधारित स्मृतियों को लागू करके लिखने-आगे-लॉगिंग अवधारणा का अनुसरण करता है, जो समय के साथ डिस्क पर फ्लश किए जाते हैं। ScyllaDB प्राथमिक, माध्यमिक और संयुक्त सूचकांकों का समर्थन करता है, दोनों नोड प्रति स्थानीय और वैश्विक प्रति क्लस्टर। प्राथमिक सूचकांक एक हेशिंग अंगूठी से बना इन अलग-अलग स्टोरेज आर्किटेक्चरों के परिणामस्वरूप कार्य भार को संभालने के लिए उपलब्ध हार्डवेयर का एक अलग उपयोग होता है. MongoDB मौजूदा सीपीयू कोर के लिए आंतरिक तारों को चिपका नहीं करता है, लेकिन कोर के लिए वितरित तारों के लिए एक अनबन दृष्टिकोण लागू करता है. सीपीयू आर्किटेक्चर, यह प्रदर्शन में कमी का कारण बन सकता है, खासकर बड़े सर्वरों के लिए क्योंकि तारों को गतिशील रूप से अलग-अलग मेमोरी नोड्स के साथ अलग-अलग सॉकेट पर कोरों को आवंटित किया जा सकता है। जिससे यह जिम्मेदार तारों को विशिष्ट कोरों पर चिपकाने की अनुमति देता है और विभिन्न कोरों और मेमोरी अंतरिक्षों के बीच स्विच करने से बचता है. इस प्रकार, शेड कुंजी को शेडों पर समान डेटा वितरण सुनिश्चित करने और हॉट शेडों को रोकने के लिए सावधानीपूर्वक चुना जाना चाहिए. इसके अलावा, ScyllaDB एक जो लंबी अवधि संवेदनशील और गैर संवेदनशील पूछताछ के लिए अंतर्निहित प्राथमिकता वर्ग प्रदान करता है, साथ ही साथ एक नोड पर टुकड़ों के माध्यम से समन्वयित आई / ओ कार्यक्रम को डिस्क प्रदर्शन को अधिकतम करने के लिए प्रदान करता है। नंबर पर आधारित कोर दृष्टिकोण पर Shard I/O कार्यक्रम ScyllaDB उपयोगकर्ता को यह नियंत्रित करने की अनुमति देता है कि डेटा डीबी कैश में रहना चाहिए या दुर्लभ रूप से एक्सेस किए गए विभाजनों के लिए इसे बाधित करना। ScyllaDB क्लाइंट को नोड और सीपीयू कोर (शार्ड) तक पहुंचने की अनुमति देता है जो डेटा का स्वामित्व रखता है। MongoDB वितरित आर्किटेक्चर - उच्च उपलब्धता और स्केलेबलता के लिए दो ऑपरेटिंग मोड MongoDB डेटाबेस आर्किटेक्चर दो क्लस्टर मोड प्रदान करता है जिन्हें निम्नलिखित अनुभागों में वर्णित किया जाता है: एक पुनरावृत्ति सेट क्लस्टर उच्च उपलब्धता का लक्ष्य रखता है, जबकि एक स्क्रैड क्लस्टर क्षैतिज स्केलेबलता और उच्च उपलब्धता का लक्ष्य रखता है। प्रतिलिपि सेट क्लस्टर: सीमित स्केलेबल के साथ उच्च उपलब्धता MongoDB आर्किटेक्चर प्रतिलिपि सेट की अवधारणा द्वारा उच्च उपलब्धता की अनुमति देता है. MongoDB प्रतिलिपि सेट प्राथमिक-दक्षिण नोड्स की अवधारणा का पालन करते हैं, जहां केवल प्राथमिक WRITE ऑपरेशनों को संभालता है. माध्यमिक डेटा का एक प्रतिलिपि रखते हैं और केवल READ ऑपरेशनों को संभालने के लिए सक्षम किया जा सकता है. एक सामान्य प्रतिलिपि सेट डिप्लोमा दो माध्यमिक सेटों से बना है, लेकिन अतिरिक्त माध्यमिक को उपलब्धता को बढ़ाने या पढ़ने के लिए भारी कार्य भारों को बढ़ाने के लिए जोड़ा जा सकता है. MongoDB एक प्रतिलिपि सेट के भीतर 50 माध्यमिक का समर्थन करता है. माध्यमिक को पूर्व प्राथमिक में विफलता के मामले में प्राथमिक के रूप में चुना जाएगा Geo-distribution के संबंध में, MongoDB डेटा सेंटर विफलताओं के मामले में उच्च उपलब्धता सुनिश्चित करने के लिए प्रतिलिपि सेट के लिए geo-distributed deployments का समर्थन करता है. In this context, secondary instances can be distributed across multiple data centers, as shown in the following figure. In addition, secondaries with limited resources or network constraints can be configured with a priority to control their electability as primary in case of a failure. Sharded क्लस्टर: ऑपरेटिंग जटिलता के साथ क्षैतिज स्केलेबलता और उच्च उपलब्धता MongoDB कई प्राथमिक संस्थानों के माध्यम से डेटा sharding द्वारा क्षैतिज स्केलिंग का समर्थन करता है ताकि लिखने की तीव्रता वाले कार्य लोड और बढ़ते डेटा आकार को संभालने के लिए. एक sharded क्लस्टर में, एक प्राथमिक और कई माध्यमिक से बना प्रत्येक प्रतिलिपि सेट एक shard का प्रतिनिधित्व करता है. चूंकि MongoDB 4.4 माध्यमिक भी हैडलिंग विकल्प का उपयोग करके पढ़ने के अनुरोधों को संभालने के लिए इस्तेमाल किया जा सकता है. Sharding को सक्षम करने के लिए, अतिरिक्त MongoDB नोड प्रकारों की आवश्यकता होती है: और सर्वर को कॉन्फ़िग करें. एक मोंगोस इंस्टीट्यूट एक सर्विस राउटर के रूप में कार्य करता है, जो क्लाइंट अनुप्रयोगों और स्क्रैड क्लस्टर के बीच एक इंटरफ़ेस प्रदान करता है. नतीजतन, क्लाइंट कभी भी सीधे स्क्रैड के साथ संचार नहीं करते हैं, बल्कि हमेशा सर्विस राउटर के माध्यम से. सर्विस राउटर स्टेटलेस और हल्के घटक हैं जो समर्पित संसाधनों पर या क्लाइंट अनुप्रयोगों के साथ एक साथ संचालित किए जा सकते हैं। Query रूटर्स (Mongos) क्लस्टर की पहुंच को सुनिश्चित करने के लिए कई पूछताछ राउटरों को तैनात करने की सिफारिश की जाती है क्योंकि पूछताछ राउटर क्लस्टर ड्राइवरों के लिए प्रत्यक्ष इंटरफ़ेस हैं. पूछताछ राउटरों की संख्या पर कोई सीमा नहीं है, लेकिन क्योंकि वे कॉन्फ़िग सर्वरों के साथ अक्सर संवाद करते हैं, यह ध्यान दिया जाना चाहिए कि बहुत अधिक पूछताछ राउटर कॉन्फ़िग सर्वरों को अवरोधित कर सकते हैं. कॉन्फ़िग सर्वरों को सभी डेटा और घटकों के लिए राज्य और संगठन सहित एक स्कारड क्लस्टर के मेटाडेटा को स्टोर किया जाता है. मेटाडेटा में प्रत्येक स्कारड पर टुकड़ों की सूची और टुकड़ों को परिभाषित करने वाले MongoDB में डेटा sharding संग्रह स्तर पर किया जाता है, और एक संग्रह को एक shard कुंजी के आधार पर sharded किया जा सकता है. MongoDB एक shard कुंजी का उपयोग यह निर्धारित करने के लिए करता है कि कौन से दस्तावेज़ किस shard पर संबंधित हैं. आम shard कुंजी विकल्पों में _id फ़ील्ड और एक उच्च cardinality के साथ एक फ़ील्ड, जैसे एक timestamp या user ID. MongoDB तीन sharding रणनीतियों का समर्थन करता है: सीमा आधारित, हैश आधारित और क्षेत्र आधारित. स्कारड क्लॉज के आधार पर स्कारड कुंजी मूल्य के अनुसार स्कारड क्लॉज दस्तावेज़ों को रैंकिंग करता है. यह स्कारड कुंजी मूल्य के साथ दस्तावेज़ों को एक दूसरे के करीब रखता है और रेंज-आधारित पूछताछ के लिए अच्छी तरह से काम करता है, उदाहरण के लिए समय श्रृंखला डेटा पर. स्कारड क्लॉज स्कारड क्लॉज की एक समान वितरण सुनिश्चित करता है, जो स्कारडों पर स्कारड करता है, जो लिखित कार्य भारों को बढ़ावा देता है. स्कारड क्लॉज डेवलपर्स को अनुकूलित स्कारडिंग नियमों को परिभाषित करने की अनुमति देता है, उदाहरण के लिए यह सुनिश्चित करने के लिए कि सबसे प्रासंगिक डेटा स्कार इसके अलावा, डेटा सेंटर विफलताओं को दूर करने के लिए भू-प्रसारित सेटिंग में विभाजित क्लस्टर लागू किया जा सकता है, जैसा कि निम्नलिखित चित्र में चित्रित है। ScyllaDB आर्किटेक्चर - उच्च उपलब्धता और क्षैतिज स्केलेबलता के लिए बहुप्रथम MongoDB के विपरीत, ScyllaDB एक प्राथमिक नोड और कई माध्यमिक नोड्स के साथ क्लासिक आरडीबीएमएस आर्किटेक्चर का अनुसरण नहीं करता है, लेकिन एक डिसेट्रेटेड संरचना का उपयोग करता है, जहां सभी डेटा व्यवस्थित रूप से वितरित और कई नोडों पर पुनरावृत्ति की जाती है जो एक क्लस्टर बनाते हैं। एक क्लस्टर एक वर्चुअल रिंग आर्किटेक्चर में व्यवस्थित कनेक्टेड नोडों का एक संग्रह है, जिसके माध्यम से डेटा वितरित किया जाता है। अंगूठी vNodes में विभाजित होती है, जो एक भौतिक नोड के लिए आवंटित टोकन की एक श्रृंखला का प्रतिनिधित्व करती है, और keyspace के लिए प्रतिलिपि कारक सेट के अनुसार भौतिक नोडों पर पुनरावृत्ति की जाती है। सभी नोड्स को बराबर माना जाता है, एक बहु प्राथमिक अर्थ में। एक परिभाषित नेता के बिना, क्लस्टर में कोई एकल विफलता बिंदु नहीं है। नोड्स व्यक्तिगत on-premises सर्वर, या आभासी सर्वर (व्यक्तिगत क्लाउड संस्करण) हो सकते हैं, जो सभी नोड्स एक दूसरे के माध्यम से संवाद करते हैं यह प्रोटोकॉल तय करता है कि किस विभाजन में कौन सा डेटा लिखा गया है और सूचकांकों का उपयोग करके सही विभाजन में डेटा रिकॉर्ड के लिए खोज करता है। गूगल प्रोटोकॉल स्केलिंग के मामले में, ScyllaDB की आर्किटेक्चर को कई सर्वरों और क्षेत्रों पर आसानी से क्षैतिज sharding के लिए बनाया गया है. ScyllaDB में sharding टेबल स्तर पर किया जाता है, और एक तालिका को एक विभाजन कुंजी के आधार पर sharded किया जा सकता है. विभाजन कुंजी एक एकल स्तंभ या कई स्तंभों का एक संयोजन हो सकता है. ScyllaDB भी रेंज-आधारित sharding का समर्थन करता है, जहां पंक्तियां विभाजन कुंजी मूल्य रेंज के आधार पर shards पर वितरित की जाती हैं, साथ ही डेटा को समान रूप से वितरित करने और हॉट स्पॉट से बचने के लिए हैश-आधारित sharding। इसके अलावा, ScyllaDB अधिक उपलब्धता और कम लाटेनियों के लिए कई डेटा सेंटरों पर डेटा को पुनरावृत्ति करने की अनुमति देता है. In this multi-data-center or multi-region setup, the data between data centers is asynchronously replicated. क्लाइंट पक्ष में, अनुप्रयोगों को मल्टीडैट सेंटर डिप्लोटिंग के बारे में पता हो सकता है या नहीं हो सकता है, और यह एप्लिकेशन डेवलपर्स पर निर्भर करता है कि वे मल्टीडैट सेंटर (एस) के बारे में पता लगाने के बारे में तय कर सकते हैं। MongoDB और ScyllaDB के वितरित आर्किटेक्चर पर एक तुलनात्मक स्केलेबलता दृष्टिकोण जब स्केलेबलता की बात आती है, तो ScyllaDB और MongoDB दोनों के काफी अलग वितरण दृष्टिकोणों को ध्यान में रखा जाना चाहिए, विशेष रूप से स्व-प्रबंधित क्लस्टर के लिए जो On-premises या IaaS पर चलते हैं। हालांकि, एक उल्लेखनीय लिखित अनुपात के साथ कार्य भारों को स्केलिंग करने के लिए, रिप्लिकेशन सेट को एक स्क्रैड रिप्लिकेशन सेट में परिवर्तित करने की आवश्यकता होती है और यह कई चुनौतियों के साथ आता है। सबसे पहले, दो अतिरिक्त MongoDB सेवाओं की आवश्यकता होती है: n पूछताछ रूटर (मंगोस) और उच्च उपलब्धता सुनिश्चित करने के लिए स्क्रैड रिप्लिकेशन सर्वरों का एक स्क्रैड सेट। परिणामस्वरूप, स्क्रैडिंग को पहले सक्षम करने के लिए काफी अधिक संसाधनों की आवश्यकता होती है। इसके अलावा, ऑपरेटिंग जटिलता स्पष्ट रूप से बढ़ जाती है। उदाहरण के लिए, तीन स्क्रैड के साथ स्क्रैड क्लस्टर में तीन मंगोस उदाहरण दूसरा चुनौती स्क्रैड क्लस्टर में डेटा का वितरण है. यहां, MongoDB एक लगातार चलने वाली पृष्ठभूमि कार्य को लागू करता है जो स्वचालित रूप से स्क्रैडों के माध्यम से डेटा के पुनर्विचार को शुरू करता है. पुनर्विचार तब नहीं होता है जब क्लस्टर में एक नया स्क्रैड जोड़ा जाता है, लेकिन जब कुछ आंतरिक सीमाओं को प्राप्त किया जाता है। परिणामस्वरूप, स्क्रैडों की संख्या को बढ़ाने से क्लस्टर तुरंत स्केलिंग प्रभाव हो सकता है. MongoDB संस्करण 5.0 तक, MongoDB इंजीनियर खुद स्क्रैड नहीं करने की सलाह देते हैं, लेकिन यदि संभव हो तो बड़े मशीनों के साथ ऊर्ध्वाधर स्केलिंग करना। ScyllaDB क्लस्टर का स्केलिंग उपयोगकर्ता के लिए तुलनात्मक रूप से आसान और पारदर्शी है, ScyllaDB के बहु-प्रथम आर्किटेक्चर के लिए धन्यवाद। यहां, प्रत्येक नोड समान है, और क्लस्टर को सैकड़ों नोडों तक स्केलिंग करने के लिए कोई अतिरिक्त सेवाएं आवश्यक नहीं हैं। इसके अलावा, डेटा रिपार्टिशन को तुरंत शुरू किया जाता है जैसे ही क्लस्टर में एक नया नोड जोड़ा जाता है। इस संदर्भ में, ScyllaDB MongoDB से स्पष्ट लाभ प्रदान करता है। सबसे पहले, लगातार हैशिंग दृष्टिकोण के लिए धन्यवाद, डेटा को पूरे क्लस्टर पर वितरित करने की आवश्यकता नहीं होती है, केवल नोडों के एक उपसेट पर। दूसरा, विभाजन नए नोड को जोड़कर शुरू मुख्य स्केलेबलता अंतर निम्नलिखित तालिका में सारांशित हैं: परिणाम और Outlook जब आप दो अलग-अलग वर्गों की तुलना करते हैं डेटाबेस में, आप हमेशा कुछ समानताओं को खोजते हैं, लेकिन कई महत्वपूर्ण अंतर भी। . दोनों डेटाबेस समान उपयोग मामलों को संबोधित करते हैं और एक समान उत्पाद और समुदाय रणनीति है. लेकिन जब तकनीकी पक्ष की बात आती है, तो आप अलग-अलग दृष्टिकोण और ध्यान देख सकते हैं. दोनों डेटाबेसों को वितरित आर्किटेक्चर के माध्यम से उच्च उपलब्धता की अनुमति देने के लिए बनाया गया है. लेकिन जब लक्ष्य कार्य भारों की बात आती है, तो MongoDB एकल नोड या प्रतिलिपि सेट तैनाती के साथ आसानी से शुरू करने की अनुमति देता है जो छोटे और मध्यम कार्य भारों के लिए अच्छी तरह से फिट होते हैं, जबकि बड़े कार्य भारों और डेटा सेटों को संबोधित करना तकनीकी आर्किटेक्चर के कारण एक चुनौती बन जाता है। नुस्खा MongoDB के खिलाफ ScyllaDB ScyllaDB स्पष्ट रूप से प्रदर्शन महत्वपूर्ण कार्य भारों को संबोधित करता है जो आसान और उच्च स्केलेबलता, उच्च प्रवाह, कम और स्थिर लाटेशन, और एक मल्टीडैट सेंटर डिप्लोमा में सब कुछ की मांग करते हैं। और उनके प्रासंगिक प्रदर्शन क्षमताओं के बारे में और अधिक अंतर्दृष्टि प्रदान करने के लिए, हम एक अलग संदर्भ रिपोर्ट में पारदर्शी और पुनरावृत्ति योग्य प्रदर्शन तुलना प्रदान करते हैं जो MongoDB अटलास और ScyllaDB क्लाउड के प्रदर्शन, स्केलेबलता और लागत की जांच करता है। अतिरिक्त ScyllaDB vs. MongoDB तुलना विवरण पूर्ण देखें इस तकनीकी तुलना के विस्तारित संस्करण के लिए, जिसमें तुलना करने के विवरण शामिल हैं: BenchANT MongoDB vs ScyllaDB की तुलना डेटा मॉडल भाषा चाहें उपयोग के मामले और ग्राहक उदाहरण डेटा संतुलन विकल्प पहला हाथ ऑपरेटिंग अनुभव
