Let’s look at the performance-related complexities that teams commonly face with write-heavy workloads and discuss your options for tackling them लिखना-बड़े डेटाबेस कार्य लोड पढ़ना-बड़े लोगों की तुलना में स्पष्ट रूप से अलग चुनौतियों का एक सेट लाते हैं. For example: लेखन का स्केलिंग महंगा हो सकता है, खासकर यदि आप प्रति ऑपरेशन भुगतान करते हैं और लेखन पढ़ने की तुलना में 5 गुना अधिक महंगा है लॉकिंग देरी जोड़ सकती है और पारगमन को कम कर सकती है आई / ओ बोतल अवरोध लिखने के विस्तार और दुर्घटना वसूली को जटिल कर सकते हैं डेटाबेस बैकप्रेशर आने वाले लोड को हिला सकता है जबकि लागत महत्वपूर्ण है - कई मामलों में - यह एक विषय नहीं है जिसे हम यहां कवर करना चाहते हैं. बल्कि, चलो प्रदर्शन से संबंधित जटिलताओं पर ध्यान केंद्रित करते हैं जो टीम आमतौर पर सामना करते हैं और उनसे निपटने के लिए आपके विकल्पों पर चर्चा करते हैं। हम "वास्तविक समय में लिखने के लिए भारी कार्य भार" के लिए क्या मतलब है? सबसे पहले, आइए स्पष्ट करें कि हम "वास्तविक समय में लिखने के लिए भारी" कार्य भार के लिए क्या मतलब है. हम कार्य भार के बारे में बात कर रहे हैं जो: बड़ी मात्रा में डेटा (उदाहरण के लिए, 50K ओपीएस से अधिक) पढ़ने की तुलना में अधिक लिखें सख्त लाटेंसी एसएलए द्वारा बाध्य हैं (उदाहरण के लिए, एक-दिवसीय मिलीसेकंड P99 लाटेंसी) जंगली में, वे ऑनलाइन गेमिंग से वास्तविक समय में एक्सचेंजों तक हर चीज में होते हैं। चीजों के इंटरनेट (आईओटी) कार्य भारों में समय श्रृंखला डेटा के छोटे लेकिन अक्सर जोड़े-केवल लेख शामिल होते हैं. यहां, अवशोषण दर मुख्य रूप से डेटा एकत्र करने वाले अंत बिंदुओं की संख्या से निर्धारित होती है. स्मार्ट घर सेंसर या औद्योगिक निगरानी उपकरणों के बारे में सोचें जो लगातार प्रसंस्करण और भंडारण के लिए डेटा प्रवाह भेजते हैं. लॉगिंग और निगरानी प्रणालियों को भी बार-बार डेटा इंजेक्शन का सामना करना पड़ता है, लेकिन उनके पास एक निश्चित इंजेक्शन दर नहीं है. वे जरूरी नहीं कि वे केवल जोड़ें, साथ ही हॉटस्पॉट के लिए संवेदनशील हो सकते हैं, जैसे कि जब एक अंत बिंदु गलत व्यवहार करता है। ऑनलाइन गेमिंग प्लेटफार्मों को वास्तविक समय में उपयोगकर्ता बातचीत को संसाधित करने की आवश्यकता होती है, जिसमें गेम की स्थिति में बदलाव, खिलाड़ी कार्रवाई और संदेश शामिल हैं. कार्य भार अचानक गतिविधि में वृद्धि के साथ तेज होता है. वे अत्यधिक लाटेन संवेदनशील होते हैं क्योंकि यहां तक कि छोटे देरी गेमिंग अनुभव को प्रभावित कर सकते हैं. ई-कॉमर्स और खुदरा कार्य भार आमतौर पर अद्यतन भारी होते हैं और अक्सर बैच प्रसंस्करण शामिल होते हैं. इन सिस्टमों को सटीक भंडारण स्तरों को बनाए रखना चाहिए, ग्राहक समीक्षाओं को संसाधित करना चाहिए, आदेश की स्थिति को ट्रैक करना चाहिए, और शॉपिंग कार्ट ऑपरेशन का प्रबंधन करना चाहिए, जो आमतौर पर अपडेट करने से पहले मौजूदा डेटा को पढ़ने की आवश्यकता होती है। विज्ञापन तकनीक और रियल टाइम शॉपिंग सिस्टम में विभाजन सेकंड के निर्णयों की आवश्यकता होती है. ये सिस्टम प्रिंट ट्रैकिंग और शॉपिंग परिणामों सहित जटिल शॉपिंग प्रसंस्करण को संभालते हैं, जबकि एक ही समय में उपयोगकर्ता इंटरैक्शन जैसे क्लिक और रूपांतरण की निगरानी करते हैं. उन्हें वास्तविक समय में धोखाधड़ी का पता लगाने और लक्षित विज्ञापन के लिए परिष्कृत दर्शकों के विभाजन का प्रबंधन करना चाहिए. रियल टाइम स्टॉक एक्सचेंज सिस्टम उच्च आवृत्ति वाले ट्रेडिंग ऑपरेशन, निरंतर स्टॉक मूल्य अद्यतन, और जटिल ऑर्डर मेलिंग प्रक्रियाओं का समर्थन करना चाहिए - सब कुछ पूर्ण डेटा स्थिरता और न्यूनतम लाटेंस बनाए रखते हुए। अगला, चलो मुख्य वास्तुकला और कॉन्फ़िगरेशन विचारों को देखते हैं जो लिखने के प्रदर्शन को प्रभावित करते हैं। स्टोरेज इंजन वास्तुकला स्टोरेज इंजन आर्किटेक्चर का विकल्प डेटाबेस में लिखने की क्षमता को मौलिक रूप से प्रभावित करता है. दो प्राथमिक दृष्टिकोण मौजूद हैं: LSM पेड़ और B-Trees। डेटाबेस को लिखने का प्रभावी ढंग से संभालने के लिए जाना जाता है – जैसे ScyllaDB, Apache Cassandra, HBase, और Google BigTable – Log-Structured Merge Trees (LSM) का उपयोग करते हैं। यह आर्किटेक्चर बड़ी मात्रा में लिखने के प्रबंधन के लिए आदर्श है। चूंकि लिखने को तुरंत स्मृति में जोड़ा जाता है, यह बहुत तेजी से प्रारंभिक भंडारण की अनुमति देता है। उदाहरण के लिए, यहां ScyllaDB लिखने का पथ कैसा दिखता है: B-tree संरचनाओं के साथ, प्रत्येक लिखने के ऑपरेशन में पेड़ में एक नोड को खोजने और संशोधित करने की आवश्यकता होती है - और इसमें अनुक्रमिक और यादृच्छिक आई / ओ दोनों शामिल होते हैं. डेटासेट के विकास के रूप में, पेड़ को अतिरिक्त नोड्स और पुनः संतुलन की आवश्यकता हो सकती है, जिससे अधिक डिस्क आई / ओ हो सकता है, जो प्रदर्शन को प्रभावित कर सकता है. Payload आकार फील्ड लोड का आकार भी प्रदर्शन को प्रभावित करता है. छोटे फील्ड लोड के साथ, पारगमन अच्छा है लेकिन सीपीयू प्रोसेसिंग मुख्य बोतलन है. जैसा कि फील्ड लोड का आकार बढ़ता है, आप समग्र पारगमन कम करते हैं और डिस्क उपयोग भी बढ़ता है। आखिरकार, एक छोटा लेखन आमतौर पर सभी बफरों में फिट होता है और सब कुछ काफी तेजी से संसाधित किया जा सकता है. यही कारण है कि उच्च प्रवाह प्राप्त करना आसान है. बड़े पैमाने के लिए, आपको बड़े पैमाने के बफरों या कई बफरों को आवंटित करने की आवश्यकता होती है. जितना बड़ा पैमाने, उतना अधिक संसाधन (नेटवर्क और डिस्क) उन पैमाने की सेवा करने के लिए आवश्यक होते हैं. संपीड़न डिस्क उपयोग एक लिखने के लिए भारी कार्य भार के साथ करीब से देखने के लिए कुछ है. भले ही भंडारण लगातार सस्ता हो रहा है, यह अभी भी मुफ्त नहीं है. संपीड़न चीजों को नियंत्रण में रखने में मदद कर सकता है – इसलिए अपनी संपीड़न रणनीति को बुद्धिमानी से चुनें। सुनिश्चित करें कि आप देखते हैं कि संपीड़न मूल रूप से आपके डेटा को छोटे ब्लॉकों (या टुकड़ों) में विभाजित करता है और फिर प्रत्येक ब्लॉक को अलग-अलग संपीड़ित करता है। संपीड़न पैरामीटर सहानुभूति For LSM-based databases, the compaction strategy you select also influences write performance. Compaction involves merging multiple SSTables into fewer, more organized files, to optimize read performance, reclaim disk space, reduce data fragmentation, and maintain overall system efficiency. संपीड़न रणनीतियों का चयन करते समय, आप कम पढ़ने के विस्तार के लिए लक्ष्य कर सकते हैं, जो संपीड़न को जितना संभव हो उतना कुशल बनाता है. या, आप संपीड़न को बहुत आक्रामक होने से बचकर कम लिखने के विस्तार के लिए लक्ष्य कर सकते हैं. या, आप कम अंतरिक्ष संपीड़न को प्राथमिकता दे सकते हैं और संपीड़न शुद्ध डेटा को जितना संभव हो उतना कुशल बना सकते हैं. उदाहरण के लिए, ScyllaDB प्रदान करता है (और Cassandra इसी तरह की पेशकश करता है): कई संतुलन रणनीतियाँ आकार-स्तरीय संपीड़न रणनीति (STCS): जब सिस्टम में पर्याप्त (अनुमानित रूप से चार) समान आकार के SSTables होते हैं तो ट्रिगर किया जाता है। स्तरित संपीड़न रणनीति (एलसीएस): सिस्टम विभिन्न स्तरों पर वितरित छोटे, निश्चित आकार (160 एमबी डिफ़ॉल्ट) SSTables का उपयोग करता है। Incremental Compaction Strategy (ICS): STCS के समान पढ़ने और लिखने के amplification कारकों को साझा करता है, लेकिन यह बड़े स्टैब्ल को SSTable run में तोड़कर अपने 2x अस्थायी अंतरिक्ष amplification समस्या को ठीक करता है, जो छोटे (1 जीबी डिफ़ॉल्ट रूप से) के एक वर्गीकृत सेट से बना है, जो गैर-अवरुद्ध SSTables हैं। टाइम विंडो संपीड़न रणनीति (TWCS): टाइम श्रृंखला डेटा के लिए डिज़ाइन किया गया है। लिखने के लिए भारी कार्य भारों के लिए, हम उपयोगकर्ताओं को किसी भी कीमत पर स्तरित संपीड़न से बचने के लिए चेतावनी देते हैं. यह रणनीति पढ़ने के लिए भारी उपयोग मामलों के लिए डिज़ाइन की गई है. इसका उपयोग करने से एक दुर्भाग्यपूर्ण 40x लिखने के विस्तार का परिणाम हो सकता है. बैचिंग ScyllaDB और Cassandra जैसी डेटाबेस में, बैचिंग वास्तव में थोड़ा झटका हो सकता है - विशेष रूप से लिखने के लिए भारी कार्य भारों के लिए। यदि आप रिलायंस डेटाबेस के लिए उपयोग कर रहे हैं, तो बैचिंग लिखने की एक बड़ी मात्रा को संभालने के लिए एक अच्छा विकल्प की तरह लग सकता है. लेकिन यह वास्तव में चीजों को धीमा कर सकता है यदि यह सावधानीपूर्वक नहीं किया जाता है. मुख्य रूप से, ऐसा इसलिए है क्योंकि बड़े या गैर संरचित बैच नोड्स के बीच बहुत समानता और नेटवर्क ओवरहेड बनाते हैं. हालांकि, यह वास्तव में नहीं है कि आप ScyllaDB जैसे वितरित डेटाबेस में क्या चाहते हैं. यहां आप भारी लेखन से निपटने पर बैचिंग के बारे में कैसे सोचते हैं: विभाजन कुंजी द्वारा बैच: विभाजन कुंजी के साथ अपने लेखों को समूह करें ताकि बैच एक समन्वयक नोड तक जाता है जो डेटा का भी मालिक है. इस तरह, समन्वयक को अतिरिक्त डेटा के लिए अन्य नोडों तक पहुंचने की आवश्यकता नहीं होती है. इसके बजाय, यह केवल अपने आप को संभालता है, जो अनावश्यक नेटवर्क ट्रैफ़िक को कम करता है. बैच छोटे और लक्षित रखें: विभाजन द्वारा बड़े बैच को छोटे में विभाजित करना चीजों को कुशल बनाए रखता है. यह नेटवर्क को ओवरलोडिंग से बचता है और प्रत्येक नोड को केवल उस डेटा पर काम करने की अनुमति देता है जो उसके पास है। Unlogged Batches पर कब्जा करें: यह देखते हुए कि आप पिछले बिंदुओं का पालन करते हैं, यह अनlogged batches का उपयोग करना सबसे अच्छा है. Logged batches add extra consistency checks, which can really slow down the writing. इसलिए, यदि आप लिखना मुश्किल स्थिति में हैं, तो बड़े, क्रॉस-नोड बैच द्वारा पेश किए जाने वाले देरी से बचने के लिए अपने बैचों को सावधानीपूर्वक संरचित करें। कवर करें हमने काफी कुछ चेतावनी दी, लेकिन चिंता न करें. सीखने के सबक की एक सूची तैयार करना आसान था क्योंकि बहुत से टीमें वास्तविक समय में लिखने वाले भारी कार्य भार के साथ बेहद सफल हैं. अब आप अपने गलतियों का अनुभव किए बिना उनके कई रहस्यों को जानते हैं. 🙂 यदि आप अधिक जानना चाहते हैं, तो यहां उन टीमों से कुछ पहली नज़रें हैं जो काफी दिलचस्प लेखन भारी चुनौतियों का सामना करते हैं: Zillow: कई डेटा निर्माताओं से रिकॉर्ड का उपभोग, जिसके परिणामस्वरूप अनियमित लेखन हो सकता है जिसके परिणामस्वरूप गलत अपडेट हो सकते हैं Tractian: IoT उपकरणों से उच्च आवृत्ति डेटा लेखन में 10X वृद्धि के लिए तैयारी Fanatics: इस ऑनलाइन खेल खुदरा के लिए ऑर्डर प्रबंधन, शॉपिंग कार्ट, और उत्पाद अद्यतन जैसे भारी लिखने के ऑपरेशन जिला ट्रैक Fanatics के इसके अलावा, निम्नलिखित वीडियो पर एक नज़र डालें, जहां हम इन लिखने के लिए भारी चुनौतियों पर और भी अधिक गहराई में जा रहे हैं और आपको ScyllaDB पर ये कार्य भार कैसे दिखते हैं।
