बेस वि एसीडी

6.1 संक्षेपांची लढाई: BASE वि. ACID

लोकप्रिय रिलेशनल डेटाबेस, जसे की MySQL, फक्त ACID च्या आधारावर दिसू लागले. परंतु गेल्या दहा वर्षांत, तथाकथित NoSQL डेटाबेसेस, जे या नावाखाली अनेक भिन्न प्रकारचे डेटाबेस एकत्र करतात, त्यांनी ACID शिवाय चांगली कामगिरी केली आहे. खरेतर, NoSQL डेटाबेससह काम करणारे विकासक मोठ्या संख्येने आहेत आणि त्यांना व्यवहार आणि त्यांच्या विश्वासार्हतेची अजिबात काळजी नाही. ते बरोबर आहेत का ते पाहूया.

तुम्ही NoSQL डेटाबेसबद्दल सर्वसाधारणपणे बोलू शकत नाही, कारण ते फक्त एक चांगले अमूर्त आहे. NoSQL डेटाबेस डेटा स्टोरेज उपप्रणालीच्या डिझाइनमध्ये आणि अगदी डेटा मॉडेलमध्ये एकमेकांपेक्षा भिन्न आहेत: NoSQL हे दोन्ही दस्तऐवज-देणारं CouchDB आणि आलेख Neo4J आहे. परंतु जर आपण व्यवहाराच्या संदर्भात त्यांच्याबद्दल बोललो, तर ते सर्व एकाच गोष्टीत सारखे असतात: ते अणू आणि अलगावच्या मर्यादित आवृत्त्या प्रदान करतात आणि म्हणून ACID हमी देत ​​नाहीत. याचा अर्थ काय हे समजून घेण्यासाठी, या प्रश्नाचे उत्तर देऊया: ते ACID नसल्यास काय देतात? काही नाही?

खरंच नाही. शेवटी, त्यांना, रिलेशनल डेटाबेस प्रमाणे, स्वतःला एका सुंदर पॅकेजमध्ये विकण्याची देखील आवश्यकता आहे. आणि ते त्यांचे स्वतःचे "रासायनिक" संक्षेप घेऊन आले - BASE.

6.2 BASE विरोधी म्हणून

आणि येथे पुन्हा मी अक्षरांच्या क्रमाने जाणार नाही, परंतु मी मूलभूत संज्ञा - सुसंगतता सह प्रारंभ करेन. मला तुमचा ओळख प्रभाव समतल करावा लागेल, कारण या सुसंगततेचा ACID मधील सुसंगततेशी फारसा संबंध नाही. सातत्य या शब्दाची समस्या ही आहे की ती बर्याच संदर्भांमध्ये वापरली जाते. परंतु या सुसंगततेचा वापराचा अधिक विस्तृत संदर्भ आहे आणि खरंच हीच सुसंगतता आहे जी वितरित प्रणालींवर चर्चा करताना चर्चा केली जाते.

आम्ही वर ज्या रिलेशनल डेटाबेसबद्दल बोललो आहोत ते व्यवहार अलगावचे वेगवेगळे स्तर प्रदान करतात आणि त्यापैकी सर्वात कठोर हे सुनिश्चित करतात की एक व्यवहार दुसर्‍या व्यवहाराद्वारे केलेले अवैध बदल पाहू शकत नाही. जर तुम्ही स्टोअरमध्ये चेकआउटवर उभे असाल आणि त्या क्षणी तुमच्या खात्यातून भाड्याचे पैसे काढले जातील, परंतु भाड्याच्या पैशाच्या हस्तांतरणासह व्यवहार अयशस्वी झाला आणि तुमचे खाते त्याच्या मागील मूल्यावर परत आले (पैसे आहे डेबिट केलेले नाही), तर चेकआउटवर तुमचा पेमेंट व्यवहार प्रत्येकाला हे जेश्चर लक्षात येणार नाही - शेवटी, तो व्यवहार कधीही पार पडला नाही आणि व्यवहार अलगावच्या आवश्यकतेनुसार, त्याचे तात्पुरते बदल इतर व्यवहारांद्वारे लक्षात येऊ शकत नाहीत.

अनेक NoSQL डेटाबेस अलगाव हमी सोडून देतात आणि "अंतिम सुसंगतता" ऑफर करतात ज्याद्वारे तुम्हाला अखेरीस वैध डेटा दिसेल, परंतु तुमच्या व्यवहारात अवैध मूल्ये वाचण्याची शक्यता असते - म्हणजे, तात्पुरती, किंवा अंशतः अद्यतनित किंवा जुनी. हे शक्य आहे की डेटा वाचताना "आळशी" मोडमध्ये सुसंगत होईल ("आळशीपणे वाचनाच्या वेळी").

NoSQL ची संकल्पना रीअल-टाइम अॅनालिटिक्ससाठी डेटाबेस म्हणून करण्यात आली होती, आणि अधिक गती प्राप्त करण्यासाठी त्यांनी सातत्याचा त्याग केला. आणि एरिक ब्रेवर, तोच माणूस ज्याने BASE हा शब्द तयार केला, त्याने तथाकथित "CAP प्रमेय" तयार केला, त्यानुसार:

वितरित संगणनाच्या कोणत्याही अंमलबजावणीसाठी, खालील तीन गुणधर्मांपैकी दोनपेक्षा जास्त प्रदान करणे शक्य आहे:

• डेटा सुसंगतता ( सुसंगतता ) - वेगवेगळ्या नोड्सवरील डेटा (उदाहरणे) एकमेकांना विरोध करत नाहीत;
• उपलब्धता ( उपलब्धता ) - वितरित प्रणालीची कोणतीही विनंती योग्य प्रतिसादासह समाप्त होते, परंतु सर्व सिस्टम नोड्सचे प्रतिसाद समान आहेत याची हमी न देता;
• विभाजन सहिष्णुता (विभाजन सहिष्णुता ) - नोड्समध्ये कोणतेही कनेक्शन नसले तरीही ते एकमेकांपासून स्वतंत्रपणे कार्य करणे सुरू ठेवतात.

जर तुम्हाला CAP चे अगदी सोपे स्पष्टीकरण हवे असेल तर तुम्ही येथे जा.

असे मत आहेत की CAP प्रमेय कार्य करत नाही आणि सामान्यतः खूप अमूर्तपणे तयार केले जाते. एक मार्ग किंवा दुसरा, NoSQL डेटाबेस बहुतेक वेळा CAP प्रमेयच्या संदर्भात सुसंगतता नाकारतात, जे खालील परिस्थितीचे वर्णन करते: डेटा अनेक उदाहरणांसह क्लस्टरमध्ये अद्यतनित केला गेला आहे, परंतु बदल अद्याप सर्व उदाहरणांवर समक्रमित केले गेले नाहीत. लक्षात ठेवा, मी वरील डायनामोडीबी उदाहरणाचा उल्लेख केला आहे, ज्याने मला सांगितले: तुमचे बदल टिकाऊ झाले आहेत - तुमच्यासाठी येथे HTTP 200 आहे - परंतु मला फक्त 10 सेकंदांनंतर बदल दिसले? डेव्हलपरच्या दैनंदिन जीवनातील दुसरे उदाहरण म्हणजे DNS, डोमेन नेम सिस्टम. जर कोणाला माहित नसेल, तर हा "शब्दकोश" आहे जो http(s) पत्त्यांचे IP पत्त्यांमध्ये भाषांतर करतो.

अद्यतनित DNS रेकॉर्ड कॅशिंग इंटरव्हल सेटिंग्जनुसार सर्व्हरवर प्रसारित केले जाते - त्यामुळे अद्यतने त्वरित लक्षात येत नाहीत. बरं, तत्सम तात्पुरती विसंगती (म्हणजे, अखेरीस सुसंगतता) रिलेशनल डेटाबेस क्लस्टरमध्ये (म्हणजे, MySQL) होऊ शकते - शेवटी, या सातत्याचा ACID च्या सुसंगततेशी काहीही संबंध नाही. म्हणून, हे समजून घेणे महत्त्वाचे आहे की या अर्थाने, SQL आणि NoSQL डेटाबेस जेव्हा क्लस्टरमध्ये अनेक उदाहरणे येतात तेव्हा ते फारसे वेगळे असण्याची शक्यता नाही.

याव्यतिरिक्त, एंड-टू-एंड सुसंगततेचा अर्थ असा असू शकतो की लेखन विनंत्या क्रमशः केल्या जातील: म्हणजे, सर्व डेटा लिहिला जाईल, परंतु शेवटी प्राप्त होणारे मूल्य हे लेखन रांगेतील शेवटचे नसेल.

नॉन-एसीडी NoSQL डेटाबेसेसमध्ये एंड-टू-एंड कंसिस्टन्सी मॉडेलमुळे तथाकथित "सॉफ्ट स्टेट" असते, ज्याचा अर्थ असा होतो की सिस्टमची स्थिती वेळेनुसार बदलू शकते, अगदी इनपुटशिवाय. परंतु अशा प्रणाली अधिक सुलभता प्रदान करण्याचा प्रयत्न करतात. 100% उपलब्धता प्रदान करणे हे क्षुल्लक काम नाही, म्हणून आम्ही "मूलभूत उपलब्धता" बद्दल बोलत आहोत. आणि या तीन संकल्पना एकत्रितपणे: “मूळत: उपलब्ध”, “सॉफ्ट स्टेट” (“सॉफ्ट स्टेट”) आणि “अंतिम सुसंगतता” हे संक्षिप्त रूप BASE बनवतात.

खरे सांगायचे तर, BASE ची संकल्पना मला ACID पेक्षा अधिक रिकामे मार्केटिंग रॅपर वाटते - कारण ती नवीन काहीही देत ​​नाही आणि डेटाबेसचे कोणत्याही प्रकारे वैशिष्ट्यीकृत करत नाही. आणि विशिष्ट डेटाबेसला लेबले (ACID, BASE, CAP) जोडणे केवळ विकासकांना गोंधळात टाकू शकते. तरीही मी तुम्हाला या शब्दाची ओळख करून देण्याचे ठरवले आहे, कारण डेटाबेसचा अभ्यास करताना त्यास बायपास करणे कठीण आहे, परंतु आता तुम्हाला ते काय आहे हे माहित आहे, मला वाटते की तुम्ही ते शक्य तितक्या लवकर विसरावे. आणि अलगाव संकल्पनेकडे परत जाऊया.

6.3 तर BASE डेटाबेस ACID निकषांची पूर्तता करत नाहीत?

मूलत:, जेथे ACID डेटाबेस नॉन-ACID पेक्षा वेगळे असतात ते म्हणजे नॉन-ACID प्रत्यक्षात अलगाव सोडून देतात. हे समजून घेणे महत्त्वाचे आहे. परंतु डेटाबेस दस्तऐवजीकरण वाचणे आणि हर्मिटेज प्रकल्पातील मुले ज्या प्रकारे करतात त्याची चाचणी घेणे अधिक महत्त्वाचे आहे. या किंवा त्या डेटाबेसचे निर्माते त्यांचे ब्रेनचाइल्ड - ACID किंवा BASE, CAP किंवा CAP कसे म्हणतात हे इतके महत्त्वाचे नाही. महत्त्वाची गोष्ट म्हणजे हा किंवा तो डेटाबेस नेमका काय प्रदान करतो.

जर डेटाबेसचे निर्माते असा दावा करतात की ते ACID हमी प्रदान करते, तर कदाचित याचे एक कारण आहे, परंतु हे असे आहे की नाही आणि किती प्रमाणात आहे हे समजून घेण्यासाठी ते स्वतःच तपासणे उचित आहे. जर त्यांनी घोषित केले की त्यांचा डेटाबेस अशी हमी देत ​​​​नाही, तर याचा अर्थ पुढील गोष्टी असू शकतात:

• डीबी अणुत्वाची कोणतीही हमी देत ​​नाही. काही NoSQL डेटाबेस अणु ऑपरेशन्ससाठी स्वतंत्र API देतात (उदा. DynamoDB);

• DB कोणतीही अलगाव हमी देत ​​नाही. याचा अर्थ असा होऊ शकतो, उदाहरणार्थ, डेटाबेस डेटा ज्या क्रमाने लिहिला होता त्या क्रमाने लिहिणार नाही.

टिकाऊपणाच्या हमीबद्दल, अनेक डेटाबेस कार्यक्षमतेच्या फायद्यासाठी या मुद्द्यावर तडजोड करतात. डिस्कवर लिहिणे खूप लांब ऑपरेशन आहे आणि या समस्येचे निराकरण करण्याचे अनेक मार्ग आहेत. मला डेटाबेस थिअरीमध्ये जास्त जायचे नाही, परंतु कोणता मार्ग पहायचा हे तुम्हाला अंदाजे समजण्यासाठी, भिन्न डेटाबेस टिकाऊपणासह समस्येचे निराकरण कसे करतात याचे सामान्य शब्दात वर्णन करेन.

वेगवेगळ्या डेटाबेसची तुलना करण्यासाठी, इतर गोष्टींबरोबरच, तुम्हाला हे माहित असणे आवश्यक आहे की डेटा स्टोरेज आणि विशिष्ट डेटाबेसचे पुनर्प्राप्ती उपप्रणाली कोणत्या डेटा स्ट्रक्चर्समध्ये आहे. थोडक्यात: वेगवेगळ्या डेटाबेसमध्ये अनुक्रमणिकेची वेगवेगळी अंमलबजावणी असते - म्हणजेच डेटामध्ये प्रवेश आयोजित करणे. त्यापैकी काही आपल्याला डेटा जलद लिहिण्याची परवानगी देतात, इतर - ते वाचण्यासाठी जलद. परंतु सर्वसाधारणपणे असे म्हणता येणार नाही की काही डेटा स्ट्रक्चर्स टिकाऊपणा जास्त किंवा कमी करतात.

6.4 भिन्न डेटाबेस डेटा कसे अनुक्रमित करतात आणि हे टिकाऊपणावर कसा परिणाम करते आणि बरेच काही

डेटा संग्रहित करण्यासाठी आणि पुनर्प्राप्त करण्यासाठी दोन मुख्य पद्धती आहेत.

डेटा जतन करण्याचा सर्वात सोपा मार्ग म्हणजे फाइलच्या शेवटी ऑपरेशन्स लॉग सारख्या पद्धतीने जोडणे (म्हणजेच, ऍपेंड ऑपरेशन नेहमीच होते): आम्हाला डेटा जोडायचा, बदलायचा किंवा हटवायचा असेल तर काही फरक पडत नाही - सर्व CRUD ऑपरेशन्स फक्त लॉगवर लिहिल्या जातात. लॉग शोधणे अकार्यक्षम आहे, आणि तिथेच निर्देशांक येतो - एक विशेष डेटा संरचना जी मेटाडेटा संग्रहित करते ज्यामध्ये डेटा नक्की कुठे संग्रहित केला जातो. लॉगसाठी सर्वात सोपी अनुक्रमणिका धोरण एक हॅश नकाशा आहे जो की आणि मूल्यांचा मागोवा ठेवतो. मूल्ये फाइलमध्ये लिहिलेल्या डेटासाठी बाइट ऑफसेटचा संदर्भ असेल, जो लॉग (लॉग) आहे आणि डिस्कवर संग्रहित आहे. ही डेटा रचना पूर्णपणे मेमरीमध्ये संग्रहित केली जाते, डेटा स्वतः डिस्कवर असताना, आणि त्याला LSM ट्री (लॉग स्ट्रक्चर्ड मर्ज) म्हणतात.

तुम्हाला कदाचित आश्चर्य वाटले असेल: जर आम्ही आमची ऑपरेशन्स जर्नलवर नेहमीच लिहित राहिलो तर ते खूप वाढेल? होय, आणि म्हणूनच कॉम्पॅक्शन तंत्राचा शोध लावला गेला, जो काही कालांतराने डेटा "साफ" करतो, म्हणजे, प्रत्येक कीसाठी फक्त सर्वात संबंधित मूल्य सोडते किंवा ते हटवते. आणि जर आमच्याकडे डिस्कवर एकापेक्षा जास्त लॉग असतील, परंतु अनेक, आणि ते सर्व क्रमवारी लावलेले असतील, तर आम्हाला SSTable ("सॉर्टेड स्ट्रिंग टेबल") नावाची नवीन डेटा रचना मिळेल आणि यामुळे आमची कामगिरी सुधारेल यात शंका नाही. जर आपल्याला मेमरीमध्ये क्रमवारी लावायची असेल, तर आपल्याला एक समान रचना मिळेल - तथाकथित मेमटेबल, परंतु त्यासह समस्या अशी आहे की जर घातक डेटाबेस क्रॅश झाला, तर शेवटचा डेटा (मेमटेबलमध्ये स्थित आहे, परंतु अद्याप लिहिलेला नाही) डिस्क) हरवली आहेत. प्रत्यक्षात,

अनुक्रमणिका करण्याचा दुसरा दृष्टिकोन बी-ट्रीज (“बी-वृक्ष”) वर आधारित आहे. बी-ट्रीमध्ये, डेटा निश्चित आकाराच्या पृष्ठांमध्ये डिस्कवर लिहिला जातो. डेटाचे हे ब्लॉक्स बहुतेकदा सुमारे 4 KB आकाराचे असतात आणि की-व्हॅल्यू जोड्या की द्वारे क्रमवारी लावलेल्या असतात. एक बी-ट्री नोड पृष्ठांच्या श्रेणीच्या लिंकसह अॅरेसारखे आहे. कमाल अॅरेमधील लिंक्सच्या संख्येला शाखा घटक म्हणतात. प्रत्येक पृष्ठ श्रेणी इतर पृष्ठ श्रेणींच्या लिंकसह दुसरा बी-ट्री नोड आहे.

अखेरीस, शीट स्तरावर, तुम्हाला वैयक्तिक पृष्ठे सापडतील. ही कल्पना निम्न-स्तरीय प्रोग्रामिंग भाषांमधील पॉइंटरसारखीच आहे, याशिवाय हे पृष्ठ संदर्भ मेमरीमध्ये न ठेवता डिस्कवर संग्रहित केले जातात. जेव्हा डेटाबेसमध्ये INSERTs आणि DELETEs येतात, तेव्हा काही नोड ब्रँचिंग फॅक्टरशी जुळण्यासाठी दोन उपवृक्षांमध्ये विभाजित होऊ शकतात. प्रक्रियेच्या मध्यभागी कोणत्याही कारणास्तव डेटाबेस अयशस्वी झाल्यास, डेटाच्या अखंडतेशी तडजोड केली जाऊ शकते. हे होण्यापासून रोखण्यासाठी, B-trees वापरणारे डेटाबेस "राइट-अहेड लॉग" किंवा WAL ठेवतात, ज्यामध्ये प्रत्येक व्यवहार रेकॉर्ड केला जातो. या डब्ल्यूएएलचा वापर बी-ट्री दूषित झाल्यास त्याची स्थिती पुनर्संचयित करण्यासाठी केला जातो. आणि असे दिसते की यामुळेच बी-ट्रीजचा वापर करून टिकाऊपणाच्या दृष्टीने डेटाबेस अधिक चांगला बनतो. परंतु LSM-आधारित डेटाबेस एक फाईल देखील राखू शकतात जी मूलत: WAL प्रमाणेच कार्य करते. म्हणून, मी आधीच सांगितलेल्या गोष्टींची पुनरावृत्ती करीन, आणि कदाचित एकापेक्षा जास्त वेळा: आपण निवडलेल्या डेटाबेसच्या ऑपरेशनची यंत्रणा समजून घ्या.

बी-ट्रीज बद्दल निश्चित काय आहे, तथापि, ते व्यवहारासाठी चांगले आहेत: प्रत्येक की निर्देशांकात फक्त एकाच ठिकाणी आढळते, तर जर्नल केलेल्या स्टोरेज उपप्रणालींमध्ये एकाच कीच्या अनेक प्रती वेगवेगळ्या शार्ड्समध्ये असू शकतात (उदाहरणार्थ, जोपर्यंत पुढील कॉम्पॅक्शन केले जाते).

तथापि, निर्देशांकाची रचना डेटाबेसच्या कार्यक्षमतेवर थेट परिणाम करते. LSM ट्रीसह, डिस्कवर लिहिणे अनुक्रमिक असतात आणि B-trees मुळे एकाधिक यादृच्छिक डिस्क ऍक्सेस होतात, त्यामुळे B-trees पेक्षा LSM सह लेखन ऑपरेशन्स जलद होतात. चुंबकीय हार्ड डिस्क ड्राइव्हस् (HDDs) साठी हा फरक विशेषतः लक्षणीय आहे, जेथे अनुक्रमिक लेखन यादृच्छिक लेखनापेक्षा खूप वेगवान आहे. LSM झाडांवर वाचन कमी होते कारण तुम्हाला अनेक भिन्न डेटा स्ट्रक्चर्स आणि SS टेबल्स पहाव्या लागतात जे कॉम्पॅक्शनच्या वेगवेगळ्या टप्प्यांवर असतात. अधिक तपशीलात हे असे दिसते. जर आपण LSM सह एक साधी डेटाबेस क्वेरी केली, तर आपण प्रथम मेमटेबलमधील की शोधू. जर ते तेथे नसेल, तर आम्ही सर्वात अलीकडील SSTable पाहतो; जर तेथे नसेल, तर आम्ही उपांत्य SSTable पाहतो, आणि असेच. विनंती केलेली की अस्तित्वात नसल्यास, LSM सह आम्हाला हे शेवटचे कळेल. LSM झाडे यामध्ये वापरली जातात, उदाहरणार्थ: LevelDB, RocksDB, Cassandra आणि HBase.

मी हे सर्व तपशीलवार वर्णन करतो जेणेकरुन तुम्हाला समजेल की डेटाबेस निवडताना, तुम्हाला बर्‍याच वेगवेगळ्या गोष्टी विचारात घ्याव्या लागतील: उदाहरणार्थ, तुम्ही अधिक डेटा लिहिण्याची किंवा वाचण्याची अपेक्षा करता का. आणि मी अद्याप डेटा मॉडेल्समधील फरक नमूद केलेला नाही (ग्राफ मॉडेलनुसार तुम्हाला डेटा ट्रॅव्हर्स करण्याची आवश्यकता आहे का? तुमच्या डेटामधील भिन्न युनिट्समध्ये काही संबंध आहेत का - मग रिलेशनल डेटाबेस बचावासाठी येतील?), आणि 2 प्रकारचे डेटा स्कीमा - लिहिताना (अनेक NoSQL प्रमाणे) आणि वाचताना (रिलेशनल प्रमाणे).

जर आपण टिकाऊपणाच्या पैलूकडे परत गेलो तर निष्कर्ष खालीलप्रमाणे असेल: इंडेक्सिंग यंत्रणेकडे दुर्लक्ष करून डिस्कवर लिहिणारा कोणताही डेटाबेस, आपल्या डेटाच्या टिकाऊपणासाठी चांगली हमी देऊ शकतो, परंतु आपल्याला प्रत्येक विशिष्ट डेटाबेसशी व्यवहार करणे आवश्यक आहे. , ते नेमके काय देते.

6.5 इन-मेमरी DB कसे कार्य करतात

तसे, डिस्कवर लिहिणाऱ्या डेटाबेस व्यतिरिक्त, तथाकथित "इन-मेमरी" डेटाबेस देखील आहेत जे प्रामुख्याने RAM सह कार्य करतात. थोडक्यात, इन-मेमरी डेटाबेस सामान्यत: जलद लेखन आणि वाचण्याच्या गतीसाठी कमी टिकाऊपणा देतात, परंतु हे काही अनुप्रयोगांसाठी योग्य असू शकते.

वस्तुस्थिती अशी आहे की डिस्कपेक्षा रॅम मेमरी फार पूर्वीपासून महाग आहे, परंतु अलीकडे ती वेगाने स्वस्त होऊ लागली आहे, ज्यामुळे नवीन प्रकारच्या डेटाबेसला जन्म दिला आहे - जो तार्किक आहे, RAM वरून डेटा वाचण्याची आणि लिहिण्याची गती पाहता. परंतु आपण योग्यरित्या विचाराल: या डेटाबेसच्या डेटा सुरक्षिततेचे काय? येथे पुन्हा, आपल्याला अंमलबजावणीचे तपशील पाहण्याची आवश्यकता आहे. सर्वसाधारणपणे, अशा डेटाबेसचे विकसक खालील यंत्रणा ऑफर करतात:

• आपण बॅटरीद्वारे समर्थित रॅम वापरू शकता;
• डिस्कवर चेंज लॉग लिहिणे शक्य आहे (वर नमूद केलेल्या WAL सारखे काहीतरी), परंतु डेटा स्वतःच नाही;
• आपण डिस्कवर डेटाबेस स्थितीच्या प्रती वेळोवेळी लिहू शकता (जे, इतर पर्याय न वापरता, हमी देत ​​​​नाही, परंतु केवळ टिकाऊपणा सुधारते);
• तुम्ही इतर मशीनवर RAM च्या स्थितीची प्रतिकृती बनवू शकता.

उदाहरणार्थ, इन-मेमरी रेडिस डेटाबेस, जो मुख्यतः संदेश रांग किंवा कॅशे म्हणून वापरला जातो, ACID कडून टिकाऊपणा नसतो: रेडिस डिस्कवर डेटा फ्लश करत असल्याने, यशस्वीरित्या अंमलात आणलेली कमांड डिस्कवर संग्रहित केली जाईल याची हमी देत ​​​​नाही (जर तुम्ही सातत्य सक्षम केले आहे) केवळ अतुल्यकालिकपणे, नियमित अंतराने.

तथापि, हे सर्व अनुप्रयोगांसाठी गंभीर नाही: मला इथरपॅड कोऑपरेटिव्ह ऑनलाइन संपादकाचे उदाहरण सापडले, जे दर 1-2 सेकंदांनी फ्लश होते आणि संभाव्यतः वापरकर्ता काही अक्षरे किंवा शब्द गमावू शकतो, जे फारच गंभीर नव्हते. अन्यथा, इन-मेमरी डेटाबेस चांगले असल्यामुळे ते डेटा मॉडेल प्रदान करतात जे डिस्क इंडेक्ससह लागू करणे कठीण आहे, रेडिसचा वापर व्यवहार अंमलात आणण्यासाठी केला जाऊ शकतो - त्याची प्राथमिकता रांग तुम्हाला हे करण्याची परवानगी देते.