3.1 ACID चा उदय

ACID हे संक्षेप प्रथम 1983 मध्ये थियो हेडर आणि अँड्रियास रॉयटर यांच्या लेखात दिसले. मजकूर सोपा करण्यासाठी आणि तो अधिक पटण्याजोगा करण्यासाठी, मी या लेखाच्या एका तुकड्याचे भाषांतर देईन (किंचित कपात करून). हे स्निपेट बँक व्यवहाराचे उदाहरण वापरते ज्यामध्ये पैसे एका खात्यातून दुसऱ्या खात्यात हस्तांतरित केले जातात.

$BEGIN_TRANSACTIONव्यवहाराची संकल्पना, ज्यात उदाहरणामध्ये आणि मधील डेटाबेससह सर्व परस्परसंवाद समाविष्ट आहेत $COMMIT_TRANSACTION, सर्व क्रिया अविभाज्यपणे केल्या जाणे आवश्यक आहे: एकतर सर्व क्रिया डेटाबेसच्या स्थितीत योग्यरित्या प्रतिबिंबित होतात किंवा काहीही होत नाही. वापरकर्त्यापर्यंत पोहोचण्यापूर्वी कोणत्याही वेळी , असलेले $COMMIT_TRANSACTIONविधान प्रविष्ट केल्यास , डेटाबेसमध्ये कोणतेही बदल दिसून येत नाहीत.ERROR$RESTORE_TRANSACTION

ही अविभाज्यता साध्य करण्यासाठी, व्यवहारात खालील चार गुणधर्म असणे आवश्यक आहे:

Atomicity (Atomicity). व्यवहार वर वर्णन केलेल्या सर्व-किंवा-काहीही प्रकारचा असणे आवश्यक आहे, आणि काहीही झाले तरी, वापरकर्त्याला हे माहित असणे आवश्यक आहे की व्यवहार कोणत्या स्थितीत आहे.

सातत्य (सातत्य). एक व्यवहार जो त्याच्या सामान्य व्यवहाराच्या शेवटी (EOT) पोहोचतो आणि त्याद्वारे त्याचे परिणाम डेटाबेसमध्ये सातत्य राखतो. दुसऱ्या शब्दांत, प्रत्येक यशस्वी व्यवहार, व्याख्येनुसार, केवळ वैध परिणाम देतो. ही स्थिती चौथ्या मालमत्तेचे समर्थन करण्यासाठी आवश्यक आहे - टिकाऊपणा.

अलगाव (अलगाव). व्यवहारात घडणार्‍या इव्हेंट्स एकाचवेळी होणार्‍या इतर व्यवहारांपासून लपवल्या पाहिजेत. जर ही अट पूर्ण झाली नाही, तर वर नमूद केलेल्या कारणांमुळे, व्यवहार त्याच्या सुरुवातीस परत येणे अशक्य होईल. अलगाव साध्य करण्यासाठी, सिंक्रोनाइझेशन नावाच्या पद्धती वापरल्या जातात ...

टिकाऊपणा (टिकाऊपणा). एकदा व्यवहार पूर्ण झाला आणि त्याचे परिणाम डेटाबेसला दिले की, सिस्टमने हे सुनिश्चित केले पाहिजे की ते परिणाम त्यानंतरच्या कोणत्याही अपयशात टिकून राहतील. व्यवहारांच्या संचापर्यंत नियंत्रणाची कोणतीही व्याप्ती नसल्यामुळे, डेटाबेस व्यवस्थापन प्रणाली (DBMS) चे व्यवहारांच्या सीमेपलीकडे कोणतेही नियंत्रण नसते.

म्हणून, वापरकर्त्याने हमी दिली पाहिजे की जर सिस्टमने त्याला काहीतरी घडले आहे याची माहिती दिली तर हे "काहीतरी" खरोखर घडले आहे. व्याख्येनुसार, कोणताही (यशस्वीपणे पूर्ण झालेला - S.K.) व्यवहार योग्य असल्याने, अपरिहार्यपणे चुकीचे व्यवहार दिसण्याचे परिणाम (म्हणजेच चुकीचा डेटा असलेले व्यवहार) केवळ संबंधित "काउंटर" व्यवहार (प्रतिव्यवहार) द्वारे काढून टाकले जाऊ शकतात.

3.2 व्यवहारांचा उदय

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

एक साधा PL/1-SQL प्रोग्राम जो एका खात्यातून दुसऱ्या खात्यात निधी हस्तांतरित करतो.


FUNDS_TRANSFER. PROCEDURE,
 $BEGIN_TRANSACTION;
 ON ERROR DO;                                   /* in case of error */
          $RESTORE_TRANSACTION,                 /* undo all work */
          GET INPUT MESSAGE;                    /* reacquire input */
          PUT MESSAGE ('TRANSFER FAILED');      /* report failure */
          GO TO COMMIT;
          END;
 GET INPUT MESSAGE;                             /* get and parse input */
 EXTRACT ACCOUNT_EBIT, ACCOUNT_CREDIT,
  AMOUNT FROM MESSAGE,
 $UPDATE ACCOUNTS                               /* do debit */
              SET BALANCE ffi BALANCE - AMOUNT
     WHERE ACCOUNTS.NUMBER = ACCOUNT_DEBIT;
 $UPDATE ACCOUNTS                               /* do credit */
              SET BALANCE = BALANCE + AMOUNT
     WHERE ACCOUNTS.NUMBER = ACCOUNT_CREDIT;
 $INSERT INTO HISTORY                           /* keep audit trail */
    <DATE, MESSAGE>;
 PUT MESSAGE ('TRANSFER DONE');                 /* report success */
COMMIT:                                         /* commit updates */
 $COMMIT_TRANSACTION;
 END;                                           /* end of program */

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

3.3 ACID कनेक्टिव्हिटी

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

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

ऑनलाइन स्टोअरच्या क्लायंटला त्याच्याद्वारे ऑर्डर केलेल्या आणि देय वस्तू वेळेवर वितरित केल्या पाहिजेत (स्थापित केलेल्या आणि क्लायंटला ज्ञात असलेल्या नियमांनुसार). अन्यथा, तो या स्टोअरवर विश्वास ठेवणार नाही. त्याच वेळी, बँकेचा क्लायंट किंवा इंटरनेट स्टोअरचा क्लायंट एंटरप्राइझच्या अंतर्गत स्वयंपाकघरची काळजी घेत नाही, त्याचे व्यवहार पूर्ण करण्यासाठी कोणत्या अंतर्गत क्रिया केल्या जातात. या एंटरप्राइझची भौतिक सुसंगतता कशी राखली जाते, भौतिक स्तरावर ऑपरेशन कसे केले जातात याची क्लायंटला काळजी नसते.

डीबीएमएसने व्यवहारांची तार्किक सुसंगतता (आणि डेटाबेस) राखण्याची काळजी घेतल्यास, अनुप्रयोग सोपे, अधिक समजण्यायोग्य आणि अधिक विश्वासार्ह बनतात. व्यवहार आणि डेटाची वैध स्थिती संबंधित अनुप्रयोग क्षेत्राचे सर्व तर्क (बँक, स्टोअर, गोदाम इ.) डेटाबेस सिस्टममध्ये जातात. आणि या प्रणालीच्या आवश्यकता अगदी सोप्या आहेत: ऍप्लिकेशनद्वारे डेटाबेसमध्ये प्रदान केलेले सुसंगततेचे नियम लक्षात घेऊन ACID व्यवहारांसाठी समर्थन. माझ्या दृष्टिकोनातून, ACID व्यवहारांना नकार दिल्याने अॅप्लिकेशन डेव्हलपर्ससाठी अत्यल्प अडचणी निर्माण होतात, ज्यांना, तुम्हाला ते आवडले किंवा नसले तरी, त्यांच्या ग्राहकांच्या नैसर्गिक गरजा पूर्ण करण्यासाठी स्वतःला असे काहीतरी लागू करावे लागेल.

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

दुर्दैवाने, आज बर्‍याच प्रकरणांमध्ये (विशेषतः, हे NoSQL दिशानिर्देशाचे वैशिष्ट्य आहे), लोक OLTP ऍप्लिकेशन्सला समर्थन देण्याबद्दल बोलतात, ते कोणत्या प्रकारचे व्यवहार करायचे हे स्पष्ट न करता. म्हणून, या लेखात, वास्तविक व्यवहारांचा संदर्भ देण्यासाठी मी संयोजन ACID व्यवहाराचा वापर करेन, आणि अयोग्य संज्ञा व्यवहार अनौपचारिक अर्थाने वापरला जाईल, भिन्न संदर्भांमध्ये भिन्न.

आता आपण CAP चे "प्रमेय" हाताळू आणि ब्रुअरच्या अर्थाने सातत्य म्हणजे काय हे शोधण्याचा प्रयत्न करूया.