An in-depth look at database and cache internals, and the tradeoffs in each. ScyllaDB सार्वजनिक रूप से dormando (Memcached maintainer) और Danny Kopping को इस परियोजना में उनके योगदान के लिए धन्यवाद देना चाहता है, साथ ही उनके समर्थन और धैर्य के लिए धन्यवाद। नींद डेनिक कोपिंग ScyllaDB के पीछे के इंजीनियरों - पैमाने पर अनुमानित प्रदर्शन के लिए डेटाबेस - ने दोनों प्रौद्योगिकियों को एक साथ तुलना करने के लिए Memcached रखरखाव dormando के साथ संयुक्त प्रयास किए, एक सहयोगी निर्माता तटस्थ तरीके से। परिणाम बताते हैं कि: Memcached और ScyllaDB दोनों ने डिस्क और नेटवर्क बैंडविड्थ को अधिकतम किया, जबकि समान परिस्थितियों में जोर दिया गया था, समग्र रूप से समान प्रदर्शन बनाए रखा। जबकि ScyllaDB को नेटवर्क पारगमन को पूरी तरह से संतृप्त करने के लिए डेटा मॉडलिंग परिवर्तनों की आवश्यकता थी, Memcached को डिस्क आई / ओ को संतृप्त करने के लिए अतिरिक्त आईओ थ्रेडों की आवश्यकता थी। हालांकि ScyllaDB डिस्क के लिए Memcached पाइपलाइन अनुरोधों की तुलना में बेहतर लाटेन्स दिखाया, Memcached लाटेन्स व्यक्तिगत अनुरोधों के लिए बेहतर थे। यह दस्तावेज़ इन परीक्षणों के लिए हमारी प्रेरणा को समझाता है, परीक्षण किए गए परिदृश्यों और परिणामों की एक सारांश प्रदान करता है, फिर उन सभी के लिए सिफारिशें प्रस्तुत करता है जो ScyllaDB और Memcached के बीच निर्णय ले सकते हैं। वहाँ भी है परीक्षणों और परिणामों की एक व्यापक नज़र के साथ और विशिष्ट कॉन्फ़िगरेशनों के लिए लिंक जो आप परीक्षणों को स्वयं करने के लिए उपयोग कर सकते हैं। इस परियोजना के लिए एक विस्तृत Gitbook, बोनस: dormando और मैंने हाल ही में P99 CONF में इस परियोजना पर चर्चा की, जो प्रदर्शन और कम लाटेंसी इंजीनियरिंग पर एक उच्च तकनीकी सम्मेलन है। मांग पर नजर रखें नींद और मैं हाल ही में इस परियोजना पर चर्चा की , प्रदर्शन और कम लाटेंसी इंजीनियरिंग पर एक उच्च तकनीकी सम्मेलन। Bonus: P99 कॉन्फ Watch on demand मांग पर नजर रखें हमने ऐसा क्यों किया? सबसे पहले, ScyllaDB ने समय और इंजीनियरिंग संसाधनों को हमारे डेटाबेस को अनुकूलित करने में निवेश किया है ताकि वास्तविक समय में डेटा-अधिक अनुप्रयोगों के लिए भविष्यवाणी योग्य कम लाटेंस हो सके। साझा-नहीं आर्किटेक्चर और (यह पूरी तरह से लिनक्स पेज कैश को दूर करता है) इस तरह के अनुकूलन के कुछ उल्लेखनीय उदाहरण हैं। चार्ज-पर-कोर उपयोगकर्ता अंतरिक्ष I / O योजना आंतरिक कैश की स्थापना दूसरा: प्रदर्शन समय के साथ मिलता है। लंबे समय से, इन-मेमरी कैश को दुनिया में सबसे तेज़ बुनियादी ढांचे के घटकों में से एक माना जाता है. हालांकि, कैशिंग समाधानों को फ्लैश डिस्क के क्षेत्र में देखना शुरू करने के बाद से अब कुछ साल बीत चुके हैं. ये पहलू स्पष्ट रूप से एक दिलचस्प सवाल उठाते हैं: If an in-memory cache can rely on flash storage, then why can’t a persistent database also work as a cache? तीसरा: हमने पहले चर्चा की थी और हाल ही में जांच की गई कि कैसे विशिष्ट टीमों ने सफलतापूर्वक . 7 कारण अपने डेटाबेस के सामने कैश न रखने के लिए अपने कैश को ScyllaDB के साथ प्रतिस्थापित करें चौथा: पिछले साल के P99 CONF में, डेनी कोपिंग ने हमें एक उज्ज्वल भाषण दिया, , जहां उन्होंने समझाया कि कैसे Memcached Extstore ने ग्रेफाना लैब को लागतों को कम करने के दौरान अपने कैश फ़ीडबैग को 42 गुना बढ़ाने में मदद की। मुझे छिपाओ अगर आप कर सकते हैं और अंत में, प्रदर्शन बेंचमार्क द्वारा प्राप्त किए गए (वैध) आलोचना के बावजूद, वे अभी भी नवाचार को बढ़ावा देने में एक महत्वपूर्ण भूमिका निभाते हैं. बेंचमार्क इंजीनियरों के लिए उपयोगी संसाधन हैं जो आंतरिक अनुकूलन अवसरों की तलाश में हैं. अब तुलना के बारे में। सेटअप अधिकारियों परीक्षण निम्नलिखित AWS इंस्टेंट प्रकारों का उपयोग करके किए गए थे: लोडर: c7i.16xlarge (64 vCPUs, 128GB रैम) Memcached: i4i.4xlarge (16 vCPUs, 128GB RAM, 3.75TB NVMe) ScyllaDB: i4i.4xlarge (16 vCPUs, 128GB रैम, 3.75TB NVMe) सभी संस्थानों को प्रदान किया जा सकता है 25Gbps नेटवर्क बैंडविड्थ. ध्यान रखें कि विशेष रूप से परीक्षणों के दौरान जो वादा किए गए नेटवर्क क्षमता को अधिकतम करते हैं, हमने ध्यान दिया . ऊपर से थ्रोटलिंग बैंडविड्थ को उदाहरणों की मूल लाइन क्षमता तक कम करता है अनुकूलन और Settings संभावित बोतलों को दूर करने के लिए, निम्नलिखित अनुकूलन और सेटिंग्स लागू किए गए हैं: एडब्ल्यूएस पक्ष: सभी संस्थानों ने एक क्लस्टर प्लेसमेंट रणनीति का उपयोग किया, एडब्ल्यूएस दस्तावेजों का पालन करते हुए: "यह रणनीति कार्य लोडों को उच्च प्रदर्शन कंप्यूटिंग (एचपीसी) अनुप्रयोगों के लिए विशिष्ट निकट से जुड़े नोड-टू-नोड संचार के लिए आवश्यक कम लाटेंसी नेटवर्क प्रदर्शन प्राप्त करने की अनुमति देती है। Memcached: Version 1.6.25, compiled with Extstore enabled. Except where denoted, run with 14 threads, pinned to specific CPUs. The remaining 2 vCPUs were assigned to CPU 0 (core & HT sibling) to handle Network IRQs, as specified by sq_split mode in seastar perftune.py. CAS operations were disabled to save space on per-item overhead. The full command line arguments were:taskset -c 1-7,9-15 /usr/local/memcached/bin/memcached -v -A -r -m 114100 -c 4096 –lock-memory –threads 14 - scylla -C ScyllaDB: i4i.4xlarge में ScyllaDB Enterprise 2024.1.2 AMI (ami-id: ami-018335b47ba6bdf9a) द्वारा कॉन्फ़िगर किए गए डिफ़ॉल्ट सेटिंग्स। तनाव मेकअप के लिए, हमने उपयोग किया , memcached की आधिकारिक परीक्षण श्रृंखला का हिस्सा. लागू तनाव प्रोफाइल में हैं GitHub रिकॉर्ड मैक्सिको फ्लिप-मिंड्स / Shredders ScyllaDB के लिए, हमने उपयोग किया , ScyllaDB के साथ भेजे गए के रूप में, और Memcached के लिए उपयोग किए गए लोगों के रूप में तुलनात्मक कार्य भार निर्दिष्ट किया। कैटरीना तनाव परीक्षण और परिणाम निम्नलिखित में हमने किए गए परीक्षणों और उनके परिणामों की एक सारांश है. यदि आप अधिक विस्तृत विवरण और विश्लेषण चाहते हैं, तो जाएं . इस प्रोजेक्ट का विस्तार रैम कैशिंग दक्षता जितने अधिक आइटम आप रैम में फिट कर सकते हैं, कैश हिट प्राप्त करने की आपकी संभावना बेहतर है. अधिक कैश हिट डिस्क पर जाने की तुलना में काफी तेजी से पहुंच का परिणाम देता है. आखिरकार, यह लाटेनता में सुधार करता है. यह परियोजना यह मापकर शुरू हुई कि हम प्रत्येक डेटास्टोर में कितने आइटम संग्रहीत कर सकते हैं. हमारे परीक्षणों के दौरान, कुंजी Memcached के लिए 4 से 12 बैट्स (key0 .. keyN) और ScyllaDB के लिए 12 बैट्स के बीच थी. मूल्य 1000 बैट्स पर तय किया गया था. मेकअप Memcached ने निकासी शुरू होने तक लगभग 101M आइटम संग्रहीत किए. यह मेमोरी कुशल है. Memcached के 114G आवंटित मेमोरी से, यह लगभग 101G मूल्य है, कुंजी आकार और अन्य झंडे पर विचार किए बिना: ScyllaDB यह कोई आश्चर्य नहीं है, यह देखते हुए कि इसके प्रोटोकॉल को एक लिखने के हिस्से के रूप में संग्रहीत करने के लिए अधिक डेटा की आवश्यकता होती है (जैसे युग के बाद लिखने का टाइमस्टैम्प, पंक्ति जीवनकाल, आदि)। Takeaways Memcached में ScyllaDB की तुलना में लगभग 65% अधिक आइटम संग्रहीत किए गए थे। ScyllaDB पंक्तियां एक व्यापक स्तंभ परिप्रेक्ष्य का समर्थन करने के लिए प्रति आइटम पर अधिक ओवरहेड हैं। ScyllaDB में, ब्लूम फिल्टर, इंडेक्स कैशिंग, और अन्य घटकों को प्रभावी डिस्क खोजों का समर्थन करने के लिए स्मृति में भी संग्रहीत किया जाता है, जो ओवरहेड के एक और परत में योगदान देता है। केवल पढ़ने के लिए In-Memory Workload के एक कैश के लिए (हालांकि असंतोषपूर्ण) कार्य भार एक ऐसा है जहां सभी डेटा रैम में फिट होते हैं - इसलिए पढ़ने के लिए डिस्क एक्सेस की आवश्यकता नहीं होती है और कोई निष्कासन या यादें नहीं होती हैं. ScyllaDB और Memcached दोनों LRU (कम से कम हाल ही में उपयोग किए गए) तर्क को याददाश्त को मुक्त करने के लिए उपयोग करते हैं: जब सिस्टम दबाव के तहत चलता है, तो आइटम LRU के दाग से निष्कासित होते हैं; ये आमतौर पर सबसे कम सक्रिय आइटम हैं। आदर्श छवि से बाहर निकलने और कैश मिस लेने से दोनों डेटा स्टोर के लिए प्रदर्शन के आधार को मापने और सेट करने में मदद मिलती है. यह इन प्रकार के कार्य भार के लिए सबसे महत्वपूर्ण बातों पर ध्यान केंद्रित करता है: पढ़ने के पारगमन और अनुरोध latency। इस परीक्षण में, हमने पहले पिछले परीक्षण में इस्तेमाल किए गए समान उपयोगी लोड आकार के साथ दोनों स्टोरों को गर्म किया। Memcached Memcached ने प्रति सेकंड एक प्रभावशाली 3 मिलियन गेट प्राप्त किए, जिससे AWS NIC बैंडविड्थ (25 जीबीपीएस) को पूरी तरह से अधिकतम किया गया! Memcached ने एक स्थिर 3M आरपीएस बनाए रखा, पूरी तरह से NIC पारगमन को अधिकतम किया पेरिस यह दिखाता है कि p99.999 प्रतिक्रियाएं 1ms के तहत पूरी हुई हैं: परिणाम सॉफ्टवेयर: cmd_get कुल ऑप्स: 5503513496 अनुपात: 3060908 / s === घंटे mg === 0 0 0 0 0 0 0 0 0 0 0 10-99us 343504394 6.238% 100-999us 5163057634 93.762% 1-2 एमएस 11500 0.00021% ScyllaDB ScyllaDB में अधिक पंक्तियों को पढ़ने के लिए, हमें प्रोटोकॉल विशेषताओं के कारण क्लाइंट अनुरोधों के लिए एक बेहतर डेटा मॉडल विकसित करने की आवश्यकता थी (विशेष रूप से, कोई पाइपलिनिंग नहीं)। नतीजतन, कैश के भीतर रिकॉर्ड की संख्या पहले दिखाए गए कुंजी-मूल्य संख्याओं की तुलना में काफी सुधार हुई। जैसा कि dormando ने सही ढंग से इंगित किया है (धन्यवाद!), यह कॉन्फ़िगरेशन पिछले Memcached से काफी अलग है. जबकि Memcached कार्य भार हमेशा एक व्यक्तिगत कुंजी-मूल्य जोड़े को हिट करता है, ScyllaDB में एक एकल अनुरोध में कई पंक्तियों को वापस किया जाता है. उल्लेखनीय रूप से, Memcached का उपयोग करके समान परिणाम प्राप्त किए जा सकते हैं, पूरे उपयोगिता भार को एक एकल कुंजी के तहत मूल्य के रूप में डालें, और परिणाम इसके अनुरूप स्केलिंग करते हैं. हमने इन बदलावों के कारणों को समझाया। वहां, हमने सीकेएल प्रोटोकॉल की विशेषताओं को कवर किया (जैसे कि प्रति आइटम ओवरहेड [memcached की तुलना में] और पाइपलिनिंग के लिए कोई समर्थन नहीं) जो ScyllaDB पर विशाल विभाजन को एकल कुंजी से प्राप्त करने की तुलना में अधिक कुशल बनाते हैं। विस्तृत लेखन में इन समायोजनों के साथ, हमारे लोडरों ने 30 मिनट के लिए प्रति सेकंड कुल 187K पढ़ने के ऑप्शन चलाए. प्रत्येक ऑपरेशन के परिणामस्वरूप 16 पंक्तियां रिकॉर्ड की गईं। memcached के समान, ScyllaDB ने भी NIC पारगमन को अधिकतम किया. यह लगभग 3M पंक्तियों / सेकंड को अकेले मेमोरी डेटा से सेवा करता था: ScyllaDB सर्वर-साइड लाटेशन जानकारी प्रकट करता है, जो नेटवर्क के बिना लाटेशन का विश्लेषण करने के लिए उपयोगी है. परीक्षण के दौरान, ScyllaDB का सर्वर-साइड p99 लाटेशन 1ms सीमाओं के भीतर रहता था: क्लाइंट-साइड सेंटील, आश्चर्य की बात नहीं है, 0.9ms के एक रीडिंग P99 के साथ सर्वर-साइड लाटेशन की तुलना में अधिक हैं। Takeaways Memcached और ScyllaDB दोनों ने नेटवर्क को पूरी तरह से संतृप्त किया; प्रति सेकंड की अधिकतम नेटवर्क पैकेज को संतृप्त करने से रोकने के लिए, Memcached अनुरोध पाइपलाइनिंग पर भरोसा किया, जबकि ScyllaDB को एक व्यापक कॉलम उन्मुख करने के लिए स्विच किया गया था। ScyllaDB के कैश ने एक व्यापक स्तंभ योजना के बाद काफी लाभ दिखाया, जो पिछले सरल कुंजी-मूल्य उन्मुखीकरण की तुलना में अधिक वस्तुओं को संग्रहीत करने में सक्षम था। प्रोटोकॉल स्तर पर, Memcached का प्रोटोकॉल सरल और हल्का है, जबकि ScyllaDB का CQL अधिक समृद्ध सुविधाएं प्रदान करता है लेकिन अधिक भारी हो सकता है। चित्र में डिस्क जोड़ना फ्लैश स्टोरेज प्रदर्शन को मापने में अपनी चुनौतियों का एक सेट आता है, जिससे एक निश्चित कार्य भार को पूरी तरह से यथार्थवादी रूप से वर्णित करना लगभग असंभव हो जाता है। डिस्क से संबंधित परीक्षणों के लिए, हमने सबसे निराशाजनक स्थिति को मापने का फैसला किया: दोनों समाधानों की तुलना करें जो (बहुत) ब्लॉक स्टोरेज से डेटा सेवा करते हैं, यह जानते हुए कि: ऐसा करने वाले यथार्थवादी कार्य भार की संभावना कहीं न कहीं शून्य के करीब है उपयोगकर्ताओं को व्यावहारिक रूप से पिछले आशावादी कैश कार्य भार और निराशाजनक डिस्क-बैंड कार्य भार के बीच संख्याओं की उम्मीद करनी चाहिए Memcached Extstore के एक उच्च स्तर पर, यह memcached को अपनी हैश टेबल और कुंजी को स्मृति में रखने की अनुमति देता है, लेकिन मूल्यों को बाहरी भंडारण पर संग्रहीत करता है। विटामिन विटामिन हमारे परीक्षणों के दौरान, हमने 1.25B आइटम के साथ memcached को 1KB के मूल्य आकार और 14 बैट तक की कुंजी आकार के साथ भरा: एक्सटस्टोर के साथ, हमने पिछली मेमोरी कार्य भार की तुलना में लगभग 11X आइटम की संख्या को संग्रहीत किया जब तक कि निष्कासन शुरू नहीं हुआ (जैसा कि ऊपर की छवि में दाहिने हाथ पैनल में दिखाया गया है)। Read-Only Performance वास्तविक प्रदर्शन परीक्षणों के लिए, हमने 1KB और 8KB के आइटम आकार के खिलाफ Extstore पर जोर दिया। Test Type Items per GET Payload Size IO Threads GET Rate P99 perfrun_metaget_pipe 16 1KB 32 188K/s 4~5 ms perfrun_metaget 1 1KB 32 182K/s <1ms perfrun_metaget_pipe 16 1KB 64 261K/s 5~6 ms perfrun_metaget 1 1KB 64 256K/s 1~2ms perfrun_metaget_pipe 16 8KB 16 92K/s 5~6 ms perfrun_metaget 1 8KB 16 90K/s <1ms perfrun_metaget_pipe 16 8KB 32 110K/s 3~4 ms perfrun_metaget 1 8KB 32 105K/s <1ms मेटागेट_पीइप 16 1KB 32 188 सेकंड 4 से 5 एमएस मेटाग्राउंड - Metaget 1 1KB 32 182 सेकंड 1 एमएस मेटागेट_पीइप 16 1KB 64 261 करोड़ 5 से 6 एमएस मेटाग्राउंड - Metaget 1 1KB 64 256k / सेकंड 1 से 2 एमएस मेटागेट_पीइप 16 8 करोड़ 16 92 फीसदी 5 से 6 एमएस मेटाग्राउंड - Metaget 1 8 करोड़ 16 90 सेकंड 1 एमएस मेटागेट_पीइप 16 8 करोड़ 32 110 सेकंड 3 से 4 एमएस मेटाग्राउंड - Metaget 1 8 करोड़ 32 105 फीसदी 1 एमएस ScyllaDB हमने memcached के लिए इस्तेमाल किए गए आइटमों की एक ही संख्या के साथ ScyllaDB को जनित किया. हालांकि ScyllaDB ने memcached की तुलना में उच्च GET दर दिखाई, लेकिन यह memcached के गैर-pipelining कार्य भारों की तुलना में थोड़ा उच्च शेड लाटेन्स के तहत ऐसा किया। Test Type Items per GET Payload Size GET Rate Server-side P99 Client-side P99 1KB Read 1 1KB 268.8K/s 2ms 2.4ms 8KB Read 1 8KB 156.8K/s 1.54ms 1.9ms 1KB पढ़े 1 1KB 268.8 करोड़ रुपये 2 एमएस 2.4 एमएस 8KB पढ़े 1 8 करोड़ 156.8 करोड़ रुपये 1.45 एमएस 1.9 एमएस Takeaways एक्सटस्टोर को फ्लैश स्टोरेज आई / ओ को पूरी तरह से संतृप्त करने के लिए अपने सेटिंग्स के लिए काफी ट्यूनिंग की आवश्यकता थी। Memcached आर्किटेक्चर के कारण, छोटे उपयोगी लोड उपलब्ध डिस्क स्थान का पूरी तरह से उपयोग नहीं कर सकते हैं, ScyllaDB की तुलना में छोटे लाभ प्रदान करते हैं। ScyllaDB दरें एक कुंजी-मूल्य उन्मुखता में Memcached की तुलना में सामान्य रूप से अधिक थीं, खासकर उच्च उपयोगी लोड आकारों के तहत। Workload को Overwrite करें हमारे पिछले डिस्क परिणामों का पालन करते हुए, हमने फिर दोनों समाधानों की तुलना की एक ज्यादातर पढ़ने वाले कार्य भार में एक ही प्रवाह (250K ऑप्स / सेक) को लक्षित करते हुए। , 10% यादृच्छिक ओवरस्क्रिट के साथ. यह एक "आधा खराब परिदृश्य" माना जाता है। Extstore के लिए 'आधारित' परीक्षण Memcached Memcached ने परीक्षण के दौरान 249K के थोड़े नीचे की दर हासिल की. हालांकि लिखने की दर परीक्षण की अवधि के दौरान स्थिर रही, हमने देखा कि पढ़ने की दर थोड़ी भिन्न थी : पूरे दौड़ में हमने थोड़ा-थोड़ा भी देखा। पढ़ने के अनुपात को कम करने के बावजूद मीट्रिक, लेकिन लाटेन्स अभी भी कम रहे. इन परिणामों को नीचे संक्षेप में प्रस्तुत किया गया है: प्रिंसिपल_मैं_मैं Operation IO Threads Rate P99 Latency cmd_get 64 224K/s 1~2 ms cmd_set 64 24.8K/s <1ms जीएसटी - मिलता है 64 224 करोड़ 1 से 2 एमएस सीएमडी सेट 64 24.8 करोड़ रुपये 1 एमएस ScyllaDB ScyllaDB परीक्षण को 2 लोडर का उपयोग करके चलाया गया था, प्रत्येक लक्ष्य दर के आधे के साथ। हालांकि ScyllaDB ने थोड़ा अधिक पारगमन (259.5K) प्राप्त किया, पूरे चलने के दौरान लिखने की लाटेंस कम रखा गया था और पढ़ने की लाटेंस अधिक थी (मेम्चैड के समान): नीचे दिए गए तालिका में दो लोडरों के बीच क्लाइंट-साइड चलने के परिणामों को सारांशित किया गया है: Loader Rate Write P99 Read P99 loader1 124.9K/s 1.4ms 2.6 ms loader2 124.6K/s 1.3ms 2.6 ms लोडर1 124.9 करोड़ रुपये 1.4 एमएस 2.6 एमएस लोडर2 126.6 करोड़ रुपये 1.3 एमएस 2.6 एमएस Takeaways दोनों Memcached और ScyllaDB लिखने की दरें स्थिर थीं, साथ ही पढ़ने की दरें पूरे दौर में थोड़ा भिन्न थीं। ScyllaDB अभी भी commitlog ओवरहेड के लिए लिखता है, जो हॉट लिखने के पथ में बैठता है ScyllaDB सर्वर-साइड लाटेन्स Memcached परिणामों में देखे गए लोगों के समान थे, हालांकि क्लाइंट-साइड लाटेन्स थोड़ा अधिक थे इस परियोजना के लिए Gitbook में अधिक विस्तृत विश्लेषण पढ़ें कवर करें दोनों memcached और ScyllaDB सभी परीक्षणों में आधारभूत हार्डवेयर उपयोग को अधिकतम करने में कामयाब रहे और लाटेन्स को भविष्यवाणी योग्य रूप से कम रखने में कामयाब रहे। यदि आपका मौजूदा कार्य भार एक सरल कुंजी-मूल्य मॉडल को समायोजित कर सकता है और यह पाइपलाइनिंग से लाभ उठाता है, तो memcached आपकी जरूरतों के लिए अधिक उपयुक्त होना चाहिए। Memcached के साथ जुड़ने का एक और कारण: यह आसानी से ट्रैफ़िक को बहुत अधिक प्रदान करता है जो एक NIC बनाए रख सकता है। , dormando ने उल्लेख किया कि वह इसे एक काफी बड़े सर्वर के लिए 55 मिलियन read ops/sec से ऊपर बढ़ा सकता है. इस तथ्य को देखते हुए, आप एक समान कार्य भार बनाए रखने के लिए छोटे और / या सस्ते इंस्टीट्यूट प्रकार का उपयोग कर सकते हैं, जब तक कि उपलब्ध मेमोरी और डिस्क पैरवी आपके कार्य भार की जरूरतों के लिए पर्याप्त हो। यह हैकर्स समाचार थ्रेड विचार करने के लिए एक अलग कोण डेटा सेट का आकार है. हालांकि Extstore आपको रैम से परे वस्तुओं को संग्रहीत करने की अनुमति देकर बड़ी लागत बचत प्रदान करता है, लेकिन प्रति जीबी स्मृति में कितने कुंजी फिट हो सकते हैं पर एक सीमा है. बहुत छोटे वस्तुओं के साथ कार्य भारों को बड़े वस्तुओं के साथ उन लोगों की तुलना में छोटे लाभ देखना चाहिए. ScyllaDB के साथ ऐसा नहीं है, जो आपको उनके आकार के बावजूद अरब वस्तुओं को संग्रहीत करने की अनुमति देता है. यदि ऐसा है, तो ScyllaDB को एक पुनरावृत्तिकृत वितरित कैश के रूप में चलाना आपको अधिक प्रतिरोधशीलता और non-stop ऑपरेशन प्रदान करता है, साथ ही साथ tradeoff होने के साथ (और ) कि पुनरावृत्ति आपके प्रभावी कैश आकार को आधे से कम करती है। दुर्भाग्य से, एक्स्टस्टस्टोर गर्म पुनरारंभ का समर्थन नहीं करता है और इसलिए एकल नोड की विफलता या रखरखाव आपके कैश मिस अनुपात को बढ़ाने की संभावना है। यह स्वीकार्य है या नहीं, यह आपकी एप्लिकेशन समानता पर निर्भर करता है: यदि कैश मिस डेटाबेस के लिए एक दौर-ट्रिप के अनुरूप है, तो अंत से अंत की लाटेंशन थोड़ी देर के लिए अधिक होगी। सही तरीके से बनाए गए राज्य लगातार हैशिंग के संबंध में, memcached क्लाइंट आपके वितरित सर्वरों पर कुंजी वितरित करने के लिए जिम्मेदार हैं. यह कुछ हिकअप को पेश कर सकता है, क्योंकि अलग-अलग क्लाइंट कॉन्फ़िगरेशन कुंजी को अलग-अलग सेट किया जाएगा, और कुछ कार्यान्वयन एक-दूसरे के साथ संगत नहीं हो सकते हैं. इन विवरणों में वर्णित हैं ScyllaDB एक अलग दृष्टिकोण लेता है: समान हैशिंग सर्वर स्तर पर किया जाता है और कनेक्शन को पहली बार स्थापित करते समय क्लाइंट को फैलाया जाता है। Memcached का ConfiguringClient wiki तो कौन जीता (या कौन खोता है)? ठीक है... यह एक प्रतियोगिता नहीं होना चाहिए, न ही प्रत्येक समाधान के लिए प्रत्येक विचारों को वर्णन करने वाला एक पूर्ण सूची है. दोनों ScyllaDB और memcached आधारित बुनियादी ढांचे का प्रभावी रूप से उपयोग करने के लिए अलग-अलग दृष्टिकोणों का उपयोग करते हैं. जब सही ढंग से कॉन्फ़िगर किया जाता है, तो दोनों में बड़ी लागत बचत प्रदान करने की क्षमता होती है. हम ScyllaDB को उद्योग द्वारा मान्यता प्राप्त Memcached के आंकड़ों के साथ मेल खाते हुए देखकर खुश थे. बेशक, हमारे पास हमारी डेटाबेस के लिए "अधिक तेजी से" होने की कोई उम्मीद नहीं थी. वास्तव में, जैसा कि हम माइक्रोसेकंड लाटेन्स को पैमाने पर पहुंचते हैं, तेजी से परिभाषित करने का परिभाषा काफी व्यक्तिगत हो जाता है. 🙂
