आधार बनाम एसिड

6.1 संक्षिप्त रूपों की लड़ाई: आधार बनाम। एसिड

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

आप NoSQL डेटाबेस के बारे में सामान्य रूप से बात नहीं कर सकते, क्योंकि यह सिर्फ एक अच्छा अमूर्त है। NoSQL डेटाबेस डेटा स्टोरेज सबसिस्टम के डिज़ाइन में एक दूसरे से भिन्न होते हैं, और यहाँ तक कि डेटा मॉडल में भी: NoSQL दस्तावेज़-उन्मुख CouchDB और ग्राफ़ Neo4J दोनों है। लेकिन अगर हम लेन-देन के संदर्भ में उनके बारे में बात करते हैं, तो वे सभी एक ही चीज़ में समान होते हैं: वे परमाणुता और अलगाव के सीमित संस्करण प्रदान करते हैं, और इसलिए एसीआईडी ​​​​गारंटी प्रदान नहीं करते हैं। यह समझने के लिए कि इसका क्या अर्थ है, आइए इस प्रश्न का उत्तर दें: यदि ACID नहीं तो वे क्या प्रदान करते हैं? कुछ नहीं?

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

6.2 एक विरोधी के रूप में आधार

और यहां फिर से मैं अक्षरों के क्रम में नहीं जाऊंगा, लेकिन मैं मौलिक शब्द - संगति से शुरू करूंगा। मुझे आपके मान्यता प्रभाव को समतल करना होगा, क्योंकि इस संगति का ACID की संगति से बहुत कम लेना-देना है। संगति शब्द के साथ समस्या यह है कि इसका प्रयोग बहुत से संदर्भों में किया जाता है। लेकिन इस संगति का उपयोग का एक बहुत व्यापक संदर्भ है, और वास्तव में यही वह संगति है जिस पर वितरित प्रणालियों की चर्चा करते समय चर्चा की जाती है।

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

कई NoSQL डेटाबेस अलगाव की गारंटी को छोड़ देते हैं और "अंतिम स्थिरता" प्रदान करते हैं जिससे आप अंततः वैध डेटा देखेंगे, लेकिन एक मौका है कि आपका लेनदेन अमान्य मान पढ़ेगा - जो कि, अस्थायी, या आंशिक रूप से अद्यतन, या पुराना है। यह संभव है कि पढ़ने के दौरान डेटा "आलसी" मोड में सुसंगत हो जाएगा ("आलसी रूप से पढ़ने के समय")।

NoSQL को रीयल-टाइम एनालिटिक्स के लिए डेटाबेस के रूप में माना गया था, और अधिक गति प्राप्त करने के लिए, उन्होंने निरंतरता का त्याग किया। और एरिक ब्रेवर, वही आदमी जिसने आधार शब्द गढ़ा, तथाकथित "CAP प्रमेय" तैयार किया, जिसके अनुसार:

वितरित कंप्यूटिंग के किसी भी कार्यान्वयन के लिए, निम्नलिखित तीन गुणों में से दो से अधिक नहीं प्रदान करना संभव है:

• डेटा संगति ( संगति ) - विभिन्न नोड्स (उदाहरण) पर डेटा एक दूसरे का खंडन नहीं करते हैं;
• उपलब्धता ( उपलब्धता ) - वितरित प्रणाली के लिए कोई भी अनुरोध एक सही प्रतिक्रिया के साथ समाप्त होता है, लेकिन बिना गारंटी के कि सभी सिस्टम नोड्स की प्रतिक्रियाएं समान हैं;
• विभाजन सहिष्णुता (विभाजन सहिष्णुता ) - भले ही नोड्स के बीच कोई संबंध न हो, वे एक दूसरे से स्वतंत्र रूप से काम करना जारी रखते हैं।

यदि आप सीएपी की एक बहुत ही सरल व्याख्या चाहते हैं, तो आप यहां जाएं।

ऐसी राय है कि सीएपी प्रमेय काम नहीं करता है, और आम तौर पर बहुत सारगर्भित रूप से तैयार किया जाता है। एक तरह से या किसी अन्य, NoSQL डेटाबेस अक्सर CAP प्रमेय के संदर्भ में निरंतरता से इनकार करते हैं, जो निम्नलिखित स्थिति का वर्णन करता है: डेटा को कई उदाहरणों के साथ क्लस्टर में अपडेट किया गया है, लेकिन परिवर्तन अभी तक सभी उदाहरणों पर सिंक्रनाइज़ नहीं किए गए हैं। याद रखें, मैंने डायनेमोडीबी उदाहरण का उल्लेख किया था, जिसने मुझे बताया: आपके परिवर्तन टिकाऊ हो गए - यहां आपके लिए एक HTTP 200 है - लेकिन मैंने केवल 10 सेकंड के बाद परिवर्तन देखा? एक डेवलपर के दैनिक जीवन का एक अन्य उदाहरण DNS, डोमेन नाम प्रणाली है। यदि कोई नहीं जानता है, तो यह बिल्कुल "शब्दकोश" है जो http (s) पतों को IP पतों में अनुवादित करता है।

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

इसके अलावा, एंड-टू-एंड संगति का मतलब यह हो सकता है कि लिखने के अनुरोध क्रम से बाहर किए जाएंगे: यानी, सभी डेटा लिखे जाएंगे, लेकिन जो मूल्य अंततः प्राप्त होगा वह लेखन कतार में अंतिम नहीं होगा। ।

गैर-एसीआईडी ​​​​नोएसक्यूएल डेटाबेस में एंड-टू-एंड स्थिरता मॉडल के कारण एक तथाकथित "सॉफ्ट स्टेट" है, जिसका अर्थ है कि सिस्टम की स्थिति समय के साथ बदल सकती है, इनपुट के बिना भी। लेकिन ऐसी प्रणालियाँ अधिक पहुँच प्रदान करने का प्रयास करती हैं। 100% उपलब्धता प्रदान करना कोई मामूली काम नहीं है, इसलिए हम "मूल उपलब्धता" के बारे में बात कर रहे हैं। और साथ में ये तीन अवधारणाएँ: "मूल रूप से उपलब्ध", "सॉफ्ट स्टेट" ("सॉफ्ट स्टेट") और "अंतिम स्थिरता" एक्रोनिम बेस बनाती हैं।

ईमानदार होने के लिए, आधार की अवधारणा मुझे एसीआईडी ​​​​की तुलना में अधिक खाली मार्केटिंग रैपर लगती है - क्योंकि यह कुछ भी नया नहीं देती है और डेटाबेस को किसी भी तरह से चित्रित नहीं करती है। और कुछ डेटाबेस में लेबल (ACID, BASE, CAP) संलग्न करना केवल डेवलपर्स को भ्रमित कर सकता है। मैंने वैसे भी आपको इस शब्द से परिचित कराने का फैसला किया, क्योंकि डेटाबेस का अध्ययन करते समय इसे बायपास करना मुश्किल है, लेकिन अब जब आप जानते हैं कि यह क्या है, तो मैं चाहता हूं कि आप इसे जल्द से जल्द भूल जाएं। और आइए अलगाव की अवधारणा पर वापस जाएं।

6.3 तो आधार डेटाबेस ACID मानदंड को बिल्कुल भी पूरा नहीं करते हैं?

अनिवार्य रूप से, जहाँ ACID डेटाबेस गैर-ACID से भिन्न होते हैं, वह यह है कि गैर-ACID वास्तव में अलगाव से गुजरते हैं। यह समझना महत्वपूर्ण है। लेकिन डेटाबेस के दस्तावेज़ों को पढ़ना और हर्मिटेज प्रोजेक्ट के लोगों की तरह उनका परीक्षण करना और भी महत्वपूर्ण है। यह इतना महत्वपूर्ण नहीं है कि इस या उस डेटाबेस के निर्माता अपने दिमाग की उपज - ACID या BASE, CAP या CAP को कैसे कहते हैं। महत्वपूर्ण बात यह है कि यह या वह डेटाबेस वास्तव में क्या प्रदान करता है।

यदि डेटाबेस के निर्माता दावा करते हैं कि यह ACID गारंटी प्रदान करता है, तो शायद इसका एक कारण है, लेकिन यह समझने के लिए कि यह ऐसा है और किस हद तक है, इसे स्वयं परखने की सलाह दी जाती है। यदि वे घोषणा करते हैं कि उनका डेटाबेस ऐसी गारंटी प्रदान नहीं करता है, तो इसका अर्थ निम्न बातें हो सकता है:

• डीबी परमाणुता की कोई गारंटी नहीं देता है। जबकि कुछ NoSQL डेटाबेस परमाणु संचालन के लिए एक अलग API प्रदान करते हैं (जैसे DynamoDB);

• डीबी कोई अलगाव गारंटी प्रदान नहीं करता है। इसका मतलब यह हो सकता है, उदाहरण के लिए, डेटाबेस उस क्रम में डेटा नहीं लिखेगा जिस क्रम में वे लिखे गए थे।

स्थायित्व की गारंटी के लिए, कई डेटाबेस प्रदर्शन के लिए इस बिंदु पर समझौता करते हैं। डिस्क पर लिखना बहुत लंबा ऑपरेशन है, और इस समस्या को हल करने के कई तरीके हैं। मैं डेटाबेस थ्योरी में ज्यादा नहीं जाना चाहता, लेकिन ताकि आप मोटे तौर पर समझ सकें कि किस तरह से देखना है, मैं सामान्य शब्दों में वर्णन करूंगा कि विभिन्न डेटाबेस स्थायित्व के साथ समस्या को कैसे हल करते हैं।

विभिन्न डेटाबेसों की तुलना करने के लिए, अन्य बातों के अलावा, आपको यह जानने की आवश्यकता है कि किसी विशेष डेटाबेस के डेटा संग्रहण और पुनर्प्राप्ति सबसिस्टम के अंतर्गत कौन-सी डेटा संरचनाएँ हैं। संक्षेप में: अलग-अलग डेटाबेस में इंडेक्सिंग के अलग-अलग कार्यान्वयन होते हैं - यानी डेटा तक पहुंच को व्यवस्थित करना। उनमें से कुछ आपको डेटा को तेज़ी से लिखने की अनुमति देते हैं, अन्य - इसे तेज़ी से पढ़ने के लिए। लेकिन यह सामान्य तौर पर नहीं कहा जा सकता है कि कुछ डेटा संरचनाएं स्थायित्व को उच्च या निम्न बनाती हैं।

6.4 विभिन्न डेटाबेस डेटा को कैसे अनुक्रमित करते हैं, और यह कैसे स्थायित्व को प्रभावित करता है, और बहुत कुछ

डेटा को संग्रहीत करने और पुनर्प्राप्त करने के दो मुख्य तरीके हैं।

डेटा को बचाने का सबसे आसान तरीका फ़ाइल के अंत में लॉग-जैसे तरीके से ऑपरेशन जोड़ना है (यानी, एक एपेंड ऑपरेशन हमेशा होता है): इससे कोई फर्क नहीं पड़ता कि हम डेटा जोड़ना, बदलना या हटाना चाहते हैं - सभी CRUD ऑपरेशन केवल लॉग में लिखे जाते हैं। लॉग खोजना अक्षम है, और यहीं पर इंडेक्स आता है - एक विशेष डेटा संरचना जो मेटाडेटा को स्टोर करती है, जहां डेटा संग्रहीत किया जाता है। लॉग के लिए सबसे सरल अनुक्रमण रणनीति एक हैश मैप है जो कुंजियों और मूल्यों का ट्रैक रखता है। मान फ़ाइल के अंदर लिखे गए डेटा के लिए बाइट ऑफ़सेट के संदर्भ होंगे, जो लॉग (लॉग) है और डिस्क पर संग्रहीत है। यह डेटा संरचना पूरी तरह से मेमोरी में संग्रहीत होती है, जबकि डेटा स्वयं डिस्क पर होता है, और इसे LSM ट्री (लॉग स्ट्रक्चर्ड मर्ज) कहा जाता है।

आपने शायद सोचा था: यदि हम हर समय अपने कार्यों को जर्नल में लिखते हैं, तो यह बहुत अधिक बढ़ जाएगा? हां, और इसलिए संघनन तकनीक का आविष्कार किया गया था, जो डेटा को कुछ आवधिकता के साथ "साफ" करता है, अर्थात्, प्रत्येक कुंजी के लिए केवल सबसे प्रासंगिक मूल्य छोड़ देता है, या इसे हटा देता है। और अगर हमारे पास डिस्क पर एक से अधिक लॉग हैं, लेकिन कई, और वे सभी सॉर्ट किए गए हैं, तो हमें SSTable ("सॉर्ट की गई स्ट्रिंग टेबल") नामक एक नई डेटा संरचना मिलेगी, और यह निस्संदेह हमारे प्रदर्शन में सुधार करेगा। यदि हम मेमोरी में सॉर्ट करना चाहते हैं, तो हमें एक समान संरचना मिलेगी - तथाकथित मेमटेबल, लेकिन इसके साथ समस्या यह है कि यदि एक घातक डेटाबेस क्रैश होता है, तो अंतिम लिखा गया डेटा (मेमटेबल में स्थित है, लेकिन अभी तक नहीं लिखा गया है) डिस्क) खो गए हैं। वास्तव में,

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

आखिरकार, शीट स्तर पर, आपको अलग-अलग पेज मिलेंगे। यह विचार निम्न-स्तरीय प्रोग्रामिंग भाषाओं में पॉइंटर्स के समान है, सिवाय इसके कि ये पृष्ठ संदर्भ मेमोरी के बजाय डिस्क पर संग्रहीत होते हैं। जब INSERTs और DELETEs डेटाबेस में होते हैं, तो कुछ नोड ब्रांचिंग फैक्टर से मेल खाने के लिए दो सबट्री में विभाजित हो सकते हैं। यदि डेटाबेस प्रक्रिया के बीच में किसी कारण से विफल हो जाता है, तो डेटा की अखंडता से समझौता किया जा सकता है। ऐसा होने से रोकने के लिए, बी-ट्रीज़ का उपयोग करने वाले डेटाबेस "राइट-फॉरवर्ड लॉग" या वाल को बनाए रखते हैं, जिसमें हर एक लेनदेन रिकॉर्ड किया जाता है। इस वाल का उपयोग बी-ट्री की स्थिति को पुनर्स्थापित करने के लिए किया जाता है यदि यह दूषित है। और ऐसा लगता है कि यह वही है जो डेटाबेस को स्थायित्व के मामले में बी-ट्री का बेहतर उपयोग करता है। लेकिन एलएसएम-आधारित डेटाबेस भी एक फाइल को बनाए रख सकते हैं जो अनिवार्य रूप से वाल के समान कार्य करता है। इसलिए, मैं वही दोहराऊंगा जो मैंने पहले ही कहा है, और शायद एक से अधिक बार: आपके द्वारा चुने गए डेटाबेस के संचालन के तंत्र को समझें।

हालांकि, बी-ट्री के बारे में निश्चित बात यह है कि वे लेन-देन के लिए अच्छे हैं: प्रत्येक कुंजी इंडेक्स में केवल एक ही स्थान पर होती है, जबकि जर्नल्ड स्टोरेज सबसिस्टम में एक ही कुंजी की कई प्रतियां अलग-अलग टुकड़ों में हो सकती हैं (उदाहरण के लिए, जब तक कि अगला संघनन किया जाता है)।

हालाँकि, इंडेक्स का डिज़ाइन सीधे डेटाबेस के प्रदर्शन को प्रभावित करता है। एलएसएम ट्री के साथ, डिस्क पर लिखना अनुक्रमिक होता है, और बी-ट्री कई रैंडम डिस्क एक्सेस का कारण बनते हैं, इसलिए बी-ट्री की तुलना में एलएसएम के साथ राइट ऑपरेशंस तेज होते हैं। अंतर विशेष रूप से चुंबकीय हार्ड डिस्क ड्राइव (HDDs) के लिए महत्वपूर्ण है, जहां अनुक्रमिक लेखन यादृच्छिक लेखन की तुलना में बहुत तेज है। एलएसएम पेड़ों पर पढ़ना धीमा है क्योंकि आपको कई अलग-अलग डेटा संरचनाओं और एसएस तालिकाओं को देखना है जो संघनन के विभिन्न चरणों में हैं। अधिक विस्तार से यह ऐसा दिखता है। यदि हम एलएसएम के साथ एक साधारण डेटाबेस क्वेरी करते हैं, तो हम पहले मेमटेबल में कुंजी देखेंगे। यदि यह नहीं है, तो हम नवीनतम SSTable को देखते हैं; यदि नहीं, तो हम अंत से पहले SSTable, और इसी तरह देखते हैं। यदि अनुरोधित कुंजी मौजूद नहीं है, तो LSM के साथ हम इसे अंतिम रूप से जानेंगे। उदाहरण के लिए, LSM ट्री का उपयोग किया जाता है: LevelDB, RocksDB, Cassandra और HBase।

मैं इन सभी का इतने विस्तार से वर्णन करता हूं ताकि आप समझ सकें कि डेटाबेस चुनते समय आपको कई अलग-अलग चीजों पर विचार करने की आवश्यकता होती है: उदाहरण के लिए, क्या आप डेटा को अधिक लिखने या पढ़ने की अपेक्षा करते हैं। और मैंने अभी तक डेटा मॉडल में अंतर का उल्लेख नहीं किया है (क्या आपको डेटा को पार करने की आवश्यकता है, जैसा कि ग्राफ़ मॉडल अनुमति देता है? क्या आपके डेटा में विभिन्न इकाइयों के बीच कोई संबंध है - फिर संबंधपरक डेटाबेस बचाव में आएंगे?), और 2 प्रकार के डेटा स्कीमा - लिखते समय (जैसा कि कई NoSQL में होता है) और पढ़ना (जैसा कि संबंधपरक में होता है)।

यदि हम स्थायित्व के पहलू पर लौटते हैं, तो निष्कर्ष इस प्रकार होगा: कोई भी डेटाबेस जो डिस्क पर लिखता है, अनुक्रमण तंत्र की परवाह किए बिना, आपके डेटा के स्थायित्व के लिए अच्छी गारंटी प्रदान कर सकता है, लेकिन आपको प्रत्येक विशिष्ट डेटाबेस से निपटने की आवश्यकता है , यह वास्तव में क्या प्रदान करता है।

6.5 इन-मेमोरी डीबी कैसे काम करते हैं

वैसे, डिस्क पर लिखने वाले डेटाबेस के अलावा, तथाकथित "इन-मेमोरी" डेटाबेस भी हैं जो मुख्य रूप से रैम के साथ काम करते हैं। संक्षेप में, इन-मेमोरी डेटाबेस आमतौर पर तेज लिखने और पढ़ने की गति के लिए कम स्थायित्व प्रदान करते हैं, लेकिन यह कुछ अनुप्रयोगों के लिए उपयुक्त हो सकता है।

तथ्य यह है कि रैम मेमोरी लंबे समय से डिस्क की तुलना में अधिक महंगी रही है, लेकिन हाल ही में यह तेजी से सस्ती होने लगी है, जिसने एक नए प्रकार के डेटाबेस को जन्म दिया है - जो रैम से डेटा पढ़ने और लिखने की गति को देखते हुए तार्किक है। लेकिन आप सही पूछेंगे: इन डेटाबेसों की डेटा सुरक्षा के बारे में क्या? यहां फिर से, आपको कार्यान्वयन के विवरण को देखने की जरूरत है। सामान्य तौर पर, ऐसे डेटाबेस के डेवलपर्स निम्नलिखित तंत्र प्रदान करते हैं:

• आप बैटरी द्वारा संचालित RAM का उपयोग कर सकते हैं;
• डिस्क में परिवर्तन लॉग लिखना संभव है (ऊपर उल्लिखित WALs जैसा कुछ), लेकिन स्वयं डेटा नहीं;
• आप समय-समय पर डेटाबेस स्थिति की प्रतियां डिस्क पर लिख सकते हैं (जो अन्य विकल्पों का उपयोग किए बिना गारंटी नहीं देता है, लेकिन केवल स्थायित्व में सुधार करता है);
• आप RAM की स्थिति को अन्य मशीनों में दोहरा सकते हैं।

उदाहरण के लिए, इन-मेमोरी रेडिस डेटाबेस, जो मुख्य रूप से संदेश कतार या कैश के रूप में उपयोग किया जाता है, में एसीआईडी ​​​​से स्थायित्व की कमी होती है: यह गारंटी नहीं देता है कि सफलतापूर्वक निष्पादित आदेश डिस्क पर संग्रहीत किया जाएगा, क्योंकि रेडिस डेटा को डिस्क में फ़्लश करता है (यदि आप दृढ़ता सक्षम है) केवल अतुल्यकालिक रूप से, नियमित अंतराल पर।

हालांकि, यह सभी अनुप्रयोगों के लिए महत्वपूर्ण नहीं है: मुझे एथरपैड सहकारी ऑनलाइन संपादक का एक उदाहरण मिला, जो हर 1-2 सेकंड में फ्लश करता था, और संभावित रूप से उपयोगकर्ता कुछ अक्षर या एक शब्द खो सकता था, जो शायद ही महत्वपूर्ण था। अन्यथा, चूंकि इन-मेमोरी डेटाबेस अच्छे हैं क्योंकि वे डेटा मॉडल प्रदान करते हैं जो डिस्क इंडेक्स के साथ लागू करना मुश्किल होगा, Redis का उपयोग लेनदेन को लागू करने के लिए किया जा सकता है - इसकी प्राथमिकता कतार आपको ऐसा करने की अनुमति देती है।