🥇अधिक विकसकांना डेटाबेसबद्दल हे माहित असले पाहिजे

नोंद. अनुवाद: जाना डोगन ही Google मधील एक अनुभवी अभियंता आहे जी सध्या Go मध्ये लिहिलेल्या कंपनीच्या उत्पादन सेवांच्या निरीक्षणावर काम करत आहे. या लेखात, ज्याने इंग्रजी भाषिक प्रेक्षकांमध्ये मोठी लोकप्रियता मिळवली, तिने DBMS (आणि काहीवेळा सर्वसाधारणपणे वितरित प्रणाली) संबंधी 17 मुद्दे महत्वाचे तांत्रिक तपशील गोळा केले जे मोठ्या / मागणी असलेल्या अनुप्रयोगांच्या विकासकांसाठी विचारात घेण्यास उपयुक्त आहेत.

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

नेटवर्कमुळे 99,999% वेळा समस्या येत नसल्यास तुम्ही भाग्यवान आहात.
ACID म्हणजे अनेक वेगवेगळ्या गोष्टी.
सुसंगतता आणि अलगाव सुनिश्चित करण्यासाठी प्रत्येक डेटाबेसची स्वतःची यंत्रणा असते.
जेव्हा नेहमीचे एक राखणे कठीण असते तेव्हा आशावादी ब्लॉकिंग बचावासाठी येते.
गलिच्छ वाचन आणि डेटा गमावण्याव्यतिरिक्त इतर विसंगती आहेत.
डेटाबेस आणि वापरकर्ता नेहमी कृती करताना सहमत नसतात.
ऍप्लिकेशन-स्तरीय शार्डिंग ऍप्लिकेशनच्या बाहेर हलविले जाऊ शकते.
स्वयंवृद्धी धोकादायक असू शकते.
जुना डेटा उपयुक्त असू शकतो आणि लॉक करण्याची आवश्यकता नाही.
विकृती कोणत्याही वेळेच्या स्त्रोतांसाठी वैशिष्ट्यपूर्ण आहेत.
विलंबाचे अनेक अर्थ आहेत.
विशिष्ट व्यवहारासाठी कार्यप्रदर्शन आवश्यकतांचे मूल्यांकन केले पाहिजे.
नेस्टेड व्यवहार धोकादायक असू शकतात.
व्यवहार अर्जाच्या स्थितीशी जोडले जाऊ नयेत.
क्वेरी प्लॅनर तुम्हाला डेटाबेसबद्दल बरेच काही सांगू शकतात.
ऑनलाइन स्थलांतर कठीण आहे, परंतु शक्य आहे.
डेटाबेसमध्ये लक्षणीय वाढ अप्रत्याशिततेमध्ये वाढ करते.

मी इमॅन्युएल ओडेके, रेन हेनरिक आणि इतरांना या लेखाच्या पूर्वीच्या आवृत्तीबद्दल त्यांच्या अभिप्रायाबद्दल धन्यवाद देऊ इच्छितो.

नेटवर्कमुळे 99,999% वेळा समस्या येत नसल्यास तुम्ही भाग्यवान आहात.

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

स्पॅनर (Google चा जागतिक स्तरावर वितरित डेटाबेस) साठी 99,999% च्या उपलब्धता दरासह, Google दावा करते की फक्त 7,6% समस्या नेटवर्कशी संबंधित आहेत. त्याच वेळी, कंपनी त्याच्या विशेष नेटवर्कला उच्च उपलब्धतेचा "मुख्य स्तंभ" म्हणते. अभ्यास बेलीस आणि किंग्सबरी, 2014 मध्ये आयोजित, "वितरित संगणनाबद्दल गैरसमज", जे पीटर ड्यूशने 1994 मध्ये तयार केले होते. नेटवर्क खरोखर विश्वसनीय आहे?

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

मोठे खेळाडू त्यांच्या सिस्टीमबद्दल काय अहवाल देतात हे लक्षात घेता, नेटवर्क अडचणी संभाव्य डाउनटाइम समस्यांपैकी फक्त थोड्या टक्केवारीसाठी कारणीभूत असल्यास आपण नशीबवान आहात असे म्हणणे सुरक्षित आहे. हार्डवेअर बिघाड, टोपोलॉजी बदल, प्रशासकीय कॉन्फिगरेशन बदल आणि पॉवर आउटेज यासारख्या सांसारिक गोष्टींमुळे नेटवर्क कम्युनिकेशन्स अजूनही ग्रस्त आहेत. अलीकडे, संभाव्य समस्यांची यादी जोडली गेली हे जाणून मला आश्चर्य वाटले शार्क चावणे (होय, तुम्ही बरोबर ऐकले आहे).

ACID म्हणजे बर्‍याच वेगवेगळ्या गोष्टी

ACID चा संक्षिप्त शब्द म्हणजे Atomicity, Consistency, Isolation, Reliability. व्यवहारांचे हे गुणधर्म अयशस्वी, त्रुटी, हार्डवेअर अयशस्वी, इत्यादींच्या बाबतीत त्यांची वैधता सुनिश्चित करण्यासाठी आहेत. ACID किंवा तत्सम योजनांशिवाय, ऍप्लिकेशन डेव्हलपर्सना ते कशासाठी जबाबदार आहेत आणि डेटाबेस कशासाठी जबाबदार आहे यात फरक करणे कठीण होईल. बहुतेक रिलेशनल ट्रान्झॅक्शनल डेटाबेसेस ACID कंप्लायंट होण्याचा प्रयत्न करतात, परंतु NoSQL सारख्या नवीन पध्दतीने ACID व्यवहारांशिवाय अनेक डेटाबेस तयार केले आहेत कारण ते लागू करणे महाग आहेत.

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

प्रत्येक DBMS ACID अनुरूप नाही; त्याच वेळी, ACID ला समर्थन देणारी डेटाबेस अंमलबजावणी आवश्यकतेचा संच वेगळ्या प्रकारे समजते. ACID ची अंमलबजावणी गडबड असण्याचे एक कारण म्हणजे ACID आवश्यकता लागू करण्यासाठी कराव्या लागणाऱ्या अनेक ट्रेड-ऑफ. निर्माते त्यांचे डेटाबेस ACID-सुसंगत म्हणून सादर करू शकतात, परंतु "संभाव्य" घटना हाताळण्यासाठीच्या यंत्रणेप्रमाणेच धार प्रकरणांचे स्पष्टीकरण नाटकीयरित्या बदलू शकते. कमीतकमी, विकासक त्यांच्या विशेष वर्तनाची आणि डिझाइन ट्रेड-ऑफची योग्य समज मिळविण्यासाठी बेस अंमलबजावणीच्या गुंतागुंतीची उच्च-स्तरीय समज मिळवू शकतात.

MongoDB ACID आवश्यकतांचे पालन करते की नाही याबद्दल वादविवाद आवृत्ती 4 रिलीज झाल्यानंतरही सुरू आहे. MongoDB ला बर्याच काळापासून सपोर्ट नाही लॉगिंग, जरी डीफॉल्टनुसार डेटा डिस्कवर प्रत्येक 60 सेकंदात एकदापेक्षा जास्त नाही. खालील परिस्थितीची कल्पना करा: अनुप्रयोग दोन लेखन पोस्ट करतो (w1 आणि w2). MongoDB यशस्वीरित्या w1 संचयित करते, परंतु हार्डवेअर अयशस्वी झाल्यामुळे w2 गमावले आहे.

परिस्थितीचे चित्रण करणारा आकृती. मोंगोडीबी डिस्कवर डेटा लिहिण्यापूर्वी क्रॅश होतो

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

प्रत्येक डेटाबेसची स्वतःची सुसंगतता आणि अलगाव यंत्रणा असते

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

डीबीएमएस अनेकदा वेगवेगळ्या स्तरांचे अलगाव प्रदान करतात. अॅप्लिकेशन डेव्हलपर त्यांच्या प्राधान्यांच्या आधारावर सर्वात प्रभावी निवडू शकतात. कमी पृथक्करण वेग वाढवण्यास अनुमती देते, परंतु डेटा रेसचा धोका देखील वाढवते. उच्च इन्सुलेशनमुळे ही संभाव्यता कमी होते, परंतु काम मंदावते आणि स्पर्धा होऊ शकते, ज्यामुळे बेसमध्ये असे ब्रेक होऊ शकतात की अपयश सुरू होतात.

विद्यमान समवर्ती मॉडेल आणि त्यांच्यातील संबंधांचे पुनरावलोकन

एसक्यूएल मानक फक्त चार अलगाव पातळी परिभाषित करते, जरी सिद्धांत आणि सराव मध्ये बरेच काही आहेत. Jepson.io विद्यमान समवर्ती मॉडेल्सचे उत्कृष्ट विहंगावलोकन देते. उदाहरणार्थ, गुगल स्पॅनर क्लॉक सिंक्रोनाइझेशनसह बाह्य अनुक्रमिकतेची हमी देते आणि जरी हा एक कठोर अलगाव स्तर आहे, तो मानक अलगाव स्तरांमध्ये परिभाषित केलेला नाही.

एसक्यूएल मानक खालील अलगाव स्तरांचा उल्लेख करते:

Serializable (सर्वात कठोर आणि महाग): अनुक्रमिक अंमलबजावणीचा काही अनुक्रमिक व्यवहाराच्या अंमलबजावणीसारखाच प्रभाव असतो. अनुक्रमिक अंमलबजावणीचा अर्थ असा आहे की प्रत्येक पुढील व्यवहार मागील पूर्ण झाल्यानंतरच सुरू होतो. हे स्तर लक्षात घेतले पाहिजे Serializable स्नॅपशॉट पृथक्करण हे एसक्यूएल मानकात दर्शविले जात नसले तरी, व्याख्यामधील फरकांमुळे अनेकदा तथाकथित स्नॅपशॉट आयसोलेशन (उदाहरणार्थ, ओरॅकलमध्ये) म्हणून लागू केले जाते.
पुनरावृत्ती करण्यायोग्य वाचन: सध्याच्या व्यवहारातील अप्रतिबंधित नोंदी सध्याच्या व्यवहारासाठी उपलब्ध आहेत, परंतु इतर व्यवहारांद्वारे केलेले बदल (जसे की नवीन पंक्ती) अदृश्य.
वचनबद्ध वाचा: व्यवहारांसाठी अप्रतिबंधित डेटा उपलब्ध नाही. या प्रकरणात, व्यवहार केवळ वचनबद्ध डेटा पाहू शकतात आणि फॅंटम रीड होऊ शकतात. जर एखाद्या व्यवहाराने नवीन पंक्ती टाकल्या आणि कमिट केल्या तर, सध्याचा व्यवहार त्यांना विचारल्यावर पाहण्यास सक्षम असेल.
बिनधास्त वाचा (किमान कठोर आणि महाग स्तर): डर्टी रीडला परवानगी आहे, व्यवहार इतर व्यवहारांद्वारे केलेले अप्रतिबंधित बदल पाहू शकतात. व्यवहारात, ही पातळी अंदाजे अंदाजांसाठी उपयुक्त असू शकते, जसे की क्वेरी COUNT(*) टेबलावर.

पातळी Serializable डेटा रेसचा धोका कमी करते, तर अंमलबजावणीसाठी सर्वात महाग आणि परिणामी सिस्टमवर सर्वाधिक स्पर्धात्मक भार होतो. इतर अलगाव पातळी अंमलात आणणे सोपे आहे, परंतु डेटा रेसची शक्यता वाढवते. काही DBMS तुम्हाला सानुकूल अलगाव पातळी सेट करण्याची परवानगी देतात, इतरांना मजबूत प्राधान्ये आहेत आणि सर्व स्तर समर्थित नाहीत.

दिलेल्या डीबीएमएसमध्ये आयसोलेशन पातळीसाठी समर्थनाची अनेकदा जाहिरात केली जाते, परंतु केवळ त्याच्या वर्तनाचा काळजीपूर्वक अभ्यास केल्यावरच प्रत्यक्षात काय घडत आहे हे उघड होऊ शकते.

भिन्न DBMS साठी भिन्न अलगाव स्तरांवर समवर्ती विसंगतींचे पुनरावलोकन

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

जेव्हा नेहमीचे एक राखणे कठीण असते तेव्हा आशावादी ब्लॉकिंग बचावासाठी येते.

अवरोधित करणे खूप महाग असू शकते, केवळ ते डेटाबेसमध्ये स्पर्धा वाढवते म्हणून नाही तर त्यासाठी अॅप्लिकेशन सर्व्हरला सतत डेटाबेसशी कनेक्ट करणे आवश्यक आहे. नेटवर्क सेगमेंटेशन अनन्य लॉकिंग परिस्थिती वाढवू शकते आणि डेडलॉक होऊ शकते जे ओळखणे आणि निराकरण करणे कठीण आहे. ज्या प्रकरणांमध्ये अनन्य लॉकिंग योग्य नाही, आशावादी लॉकिंग मदत करते.

आशावादी लॉक ही एक पद्धत आहे ज्यामध्ये स्ट्रिंग वाचताना, ती त्याची आवृत्ती, चेकसम किंवा शेवटच्या बदलाची वेळ विचारात घेते. हे तुम्हाला एंट्री बदलण्यापूर्वी अणु आवृत्ती बदलत नसल्याचे सुनिश्चित करण्यास अनुमती देते:

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

या प्रकरणात, टेबल अद्यतनित करणे products या पंक्तीमध्ये पूर्वी दुसर्‍या ऑपरेशनने बदल केले असल्यास ते केले जाणार नाही. या पंक्तीवर इतर कोणतेही ऑपरेशन केले नसल्यास, एका पंक्तीसाठी बदल होईल आणि आम्ही असे म्हणू शकतो की अद्यतन यशस्वी झाले.

गलिच्छ वाचन आणि डेटा गमावण्याव्यतिरिक्त इतर विसंगती आहेत

जेव्हा डेटा सुसंगततेचा विचार केला जातो तेव्हा, शर्यतीच्या परिस्थितीच्या संभाव्यतेवर लक्ष केंद्रित केले जाते ज्यामुळे गलिच्छ वाचन आणि डेटा गमावला जाऊ शकतो. तथापि, डेटा विसंगती तेथे थांबत नाहीत.

अशा विसंगतींचे एक उदाहरण म्हणजे रेकॉर्डिंग विकृती (तिरकस लिहा). विकृती शोधणे कठीण आहे कारण ते सहसा सक्रियपणे शोधले जात नाहीत. ते गलिच्छ वाचन किंवा डेटा गमावल्यामुळे नाही, परंतु डेटावर ठेवलेल्या तार्किक मर्यादांचे उल्लंघन केल्यामुळे आहेत.

उदाहरणार्थ, एका मॉनिटरिंग ऍप्लिकेशनचा विचार करूया ज्यासाठी एका ऑपरेटरला नेहमी ऑन-कॉल असणे आवश्यक आहे:

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

वरील परिस्थितीत, दोन्ही व्यवहार यशस्वीरित्या पार पाडल्यास विक्रमी भ्रष्टाचार होईल. कोणतेही गलिच्छ वाचन किंवा डेटा गमावला नसला तरी, डेटाच्या अखंडतेशी तडजोड केली गेली होती: आता एकाच वेळी दोन लोकांना ऑन-कॉल मानले जाते.

अनुक्रमिक अलगाव, स्कीमा डिझाइन किंवा डेटाबेस मर्यादा लेखन भ्रष्टाचार दूर करण्यात मदत करू शकतात. विकासकांना अशा विसंगती उत्पादनात टाळण्यासाठी विकासादरम्यान ओळखण्यास सक्षम असणे आवश्यक आहे. त्याच वेळी, कोड बेसमध्ये रेकॉर्डिंग विकृती शोधणे अत्यंत कठीण आहे. विशेषत: मोठ्या प्रणालींमध्ये, जेव्हा भिन्न विकास कार्यसंघ समान सारण्यांवर आधारित कार्ये अंमलात आणण्यासाठी जबाबदार असतात आणि डेटा ऍक्सेसच्या वैशिष्ट्यांशी सहमत नसतात.

डेटाबेस आणि वापरकर्ता नेहमी काय करावे यावर सहमत नसतात

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

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

पहिल्या दृष्टीक्षेपात, खालील प्रोग्राममध्ये, T1 आणि T2 अनुक्रमे म्हटले जाते, परंतु जर ही फंक्शन्स नॉन-ब्लॉकिंग असतील आणि लगेच परिणाम फॉर्ममध्ये परत करा. जे वचन दिले आहे, नंतर त्यांनी डेटाबेसमध्ये प्रवेश केल्यावर कॉलचा क्रम निश्चित केला जाईल:

परिणाम1 = T1() // वास्तविक परिणाम हे वचन आहेत
परिणाम2 = T2()

जर अणुत्वाची आवश्यकता असेल (म्हणजेच, सर्व ऑपरेशन्स पूर्ण केल्या पाहिजेत किंवा रद्द केल्या पाहिजेत) आणि अनुक्रम महत्त्वाचा असेल, तर ऑपरेशन T1 आणि T2 एकाच व्यवहारात करणे आवश्यक आहे.

ऍप्लिकेशन-स्तरीय शार्डिंग ऍप्लिकेशनच्या बाहेर हलविले जाऊ शकते

Sharding ही डेटाबेस क्षैतिजरित्या विभाजित करण्याची एक पद्धत आहे. काही डेटाबेस आपोआप डेटा क्षैतिजरित्या विभाजित करू शकतात, तर इतर ते करू शकत नाहीत किंवा ते फार चांगले नाहीत. जेव्हा डेटा वास्तुविशारद/डेव्हलपर डेटामध्ये नेमका कसा प्रवेश केला जाईल याचा अंदाज लावू शकतात, तेव्हा ते डेटाबेसला हे काम सोपवण्याऐवजी वापरकर्त्याच्या जागेत क्षैतिज विभाजने तयार करू शकतात. या प्रक्रियेला "अॅप्लिकेशन-लेव्हल शार्डिंग" म्हणतात. (अनुप्रयोग-स्तरीय शार्डिंग).

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

आर्किटेक्चरचे उदाहरण ज्यामध्ये अॅप्लिकेशन सर्व्हर शार्डिंग सेवेपासून वेगळे केले जातात

एका वेगळ्या सेवेमध्ये शार्डिंग हलवण्यामुळे ऍप्लिकेशन्सची पुनर्नियोजन न करता विविध शार्डिंग धोरणे वापरण्याची क्षमता वाढते. विटेस अनुप्रयोग स्तरावर अशा शार्डिंग प्रणालीचे उदाहरण आहे. Vitess MySQL साठी क्षैतिज शार्डिंग प्रदान करते आणि क्लायंटला MySQL प्रोटोकॉलद्वारे त्याच्याशी कनेक्ट करण्याची परवानगी देते. सिस्टम डेटाला वेगवेगळ्या MySQL नोड्समध्ये विभागते ज्यांना एकमेकांबद्दल काहीही माहिती नसते.

स्वयंवृद्धी धोकादायक असू शकते

AUTOINCREMENT हा प्राथमिक की व्युत्पन्न करण्याचा एक सामान्य मार्ग आहे. डेटाबेस आयडी जनरेटर म्हणून वापरले जातात आणि डेटाबेसमध्ये आयडेंटिफायर व्युत्पन्न करण्यासाठी डिझाइन केलेले टेबल्स असतात. स्वयं-वाढीचा वापर करून प्राथमिक की व्युत्पन्न करण्याची अनेक कारणे आहेत:

वितरित डेटाबेसमध्ये, स्वयं-वाढ होणे ही एक गंभीर समस्या आहे. आयडी तयार करण्यासाठी, जागतिक लॉक आवश्यक आहे. त्याऐवजी, तुम्ही UUID व्युत्पन्न करू शकता: यासाठी वेगवेगळ्या डेटाबेस नोड्समधील परस्परसंवादाची आवश्यकता नाही. लॉकसह स्वयं-वाढीमुळे विवाद होऊ शकतो आणि वितरीत परिस्थितींमध्ये इन्सर्टची कार्यक्षमता लक्षणीयरीत्या कमी होऊ शकते. काही DBMSs (उदाहरणार्थ, MySQL) मास्टर-मास्टर प्रतिकृती व्यवस्थित करण्यासाठी विशेष कॉन्फिगरेशन आणि अधिक काळजीपूर्वक लक्ष देण्याची आवश्यकता असू शकते. आणि कॉन्फिगर करताना चुका करणे सोपे आहे, ज्यामुळे रेकॉर्डिंग अयशस्वी होईल.
काही डेटाबेसमध्ये प्राथमिक की वर आधारित विभाजन अल्गोरिदम असतात. सलग आयडींमुळे काही विभाजनांवर अनपेक्षित हॉट स्पॉट्स आणि लोड वाढू शकतात तर काही निष्क्रिय राहतात.
डेटाबेसमधील पंक्तीमध्ये प्रवेश करण्याचा सर्वात जलद मार्ग म्हणजे प्राथमिक की. रेकॉर्ड ओळखण्याच्या चांगल्या पद्धतींसह, अनुक्रमिक आयडी टेबलमधील सर्वात महत्त्वाच्या स्तंभाला निरर्थक मूल्यांनी भरलेल्या निरुपयोगी स्तंभात बदलू शकतात. म्हणून, जेव्हा शक्य असेल तेव्हा, कृपया जागतिक स्तरावर अद्वितीय आणि नैसर्गिक प्राथमिक की निवडा (उदा. वापरकर्तानाव).

एखाद्या दृष्टिकोनावर निर्णय घेण्यापूर्वी, अनुक्रमणिका, विभाजन आणि शार्डिंगवर स्वयं-वाढीव आयडी आणि यूयूआयडीचा प्रभाव विचारात घ्या.

जुना डेटा उपयुक्त असू शकतो आणि लॉकिंगची आवश्यकता नाही

मल्टीव्हर्शन कॉन्करन्सी कंट्रोल (MVCC) वर थोडक्यात चर्चा केलेल्या अनेक सातत्य आवश्यकता लागू करते. काही डेटाबेस (उदाहरणार्थ, पोस्टग्रेस, स्पॅनर) MVCC चा वापर स्नॅपशॉटसह व्यवहारांना “फीड” करण्यासाठी करतात—डेटाबेसच्या जुन्या आवृत्त्या. सुसंगतता सुनिश्चित करण्यासाठी स्नॅपशॉट व्यवहार देखील अनुक्रमित केले जाऊ शकतात. जुन्या स्नॅपशॉटमधून वाचताना, कालबाह्य डेटा वाचला जातो.

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

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

पॅसिफिक महासागराच्या दुसऱ्या बाजूला नवीनतम आवृत्ती उपलब्ध असली तरीही अॅप्लिकेशन सर्व्हर 5 सेकंद जुना असलेला स्थानिक प्रतिकृतीचा डेटा वाचतो

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

कोणत्याही वेळी स्रोत विकृतीच्या अधीन असतात

कॉम्प्युटर सायन्समधले सर्वोत्कृष्ट गुपित हे आहे की सर्व टायमिंग API खोटे बोलतात. खरं तर, आमच्या मशीन्सना वर्तमान वेळ माहित नाही. संगणकांमध्ये क्वार्ट्ज क्रिस्टल्स असतात जे कंपन निर्माण करतात जे वेळ राखण्यासाठी वापरले जातात. तथापि, ते पुरेसे अचूक नाहीत आणि अचूक वेळेच्या पुढे/मागे असू शकतात. शिफ्ट दररोज 20 सेकंदांपर्यंत पोहोचू शकते. म्हणून, आमच्या संगणकावरील वेळ वेळोवेळी नेटवर्कशी सिंक्रोनाइझ करणे आवश्यक आहे.

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

अणु घड्याळे आणि त्यांचे GPS समकक्ष वर्तमान वेळ ठरवण्यासाठी चांगले आहेत, परंतु ते महाग आहेत आणि जटिल सेटअप आवश्यक आहेत, म्हणून ते प्रत्येक कारवर स्थापित केले जाऊ शकत नाहीत. यामुळे, डेटा सेंटर एक टायर्ड दृष्टीकोन वापरतात. अणु आणि/किंवा GPS घड्याळे अचूक वेळ दर्शवतात, त्यानंतर ते दुय्यम सर्व्हरद्वारे इतर मशीनवर प्रसारित केले जातात. याचा अर्थ प्रत्येक मशीनला अचूक वेळेपासून विशिष्ट ऑफसेटचा अनुभव येईल.

अनुप्रयोग आणि डेटाबेस बर्‍याचदा वेगवेगळ्या मशीन्सवर (वेगवेगळ्या डेटा सेंटरमध्ये नसल्यास) स्थित असतात या वस्तुस्थितीमुळे परिस्थिती आणखी बिकट झाली आहे. अशा प्रकारे, वेगवेगळ्या मशीनवर वितरित केलेल्या डीबी नोड्सवरच वेळ भिन्न असेल. ते अॅप्लिकेशन सर्व्हरवर देखील वेगळे असेल.

Google TrueTime पूर्णपणे भिन्न दृष्टीकोन घेते. बहुतेक लोकांचा असा विश्वास आहे की या दिशेने Google ची प्रगती अणु आणि GPS घड्याळांमधील सामान्य संक्रमणाद्वारे स्पष्ट केली गेली आहे, परंतु हे केवळ मोठ्या चित्राचा एक भाग आहे. TrueTime कसे कार्य करते ते येथे आहे:

TrueTime दोन भिन्न स्त्रोत वापरते: GPS आणि अणु घड्याळे. या घड्याळांमध्ये गैर-सहसंबंधित अपयश मोड असतात. [तपशीलांसाठी पृष्ठ 5 पहा येथे - अंदाजे अनुवाद.), म्हणून त्यांचा संयुक्त वापर विश्वसनीयता वाढवतो.
TrueTime मध्ये असामान्य API आहे. हे मोजमाप त्रुटी आणि अनिश्चिततेसह मध्यांतर म्हणून वेळ परत करते. वेळेतील वास्तविक क्षण मध्यांतराच्या वरच्या आणि खालच्या सीमांच्या दरम्यान कुठेतरी असतो. स्पॅनर, Google चा वितरित डेटाबेस, वर्तमान वेळ मर्यादेबाहेर आहे असे म्हणणे सुरक्षित होईपर्यंत फक्त प्रतीक्षा करते. ही पद्धत सिस्टममध्ये काही विलंबतेचा परिचय देते, विशेषत: जर मास्टर्सवरील अनिश्चितता जास्त असेल, परंतु जागतिक स्तरावर वितरित परिस्थितीतही अचूकता सुनिश्चित करते.

स्पॅनर घटक TrueTime वापरतात, जिथे TT.now() एक मध्यांतर परत करतो, त्यामुळे स्पॅनर फक्त त्या बिंदूपर्यंत झोपतो जिथे तो खात्री बाळगू शकतो की सध्याची वेळ विशिष्ट बिंदू पार केली आहे.

वर्तमान वेळ निश्चित करण्यात कमी अचूकता म्हणजे स्पॅनर ऑपरेशन्सच्या कालावधीत वाढ आणि कार्यक्षमतेत घट. म्हणूनच संपूर्णपणे अचूक घड्याळ मिळणे अशक्य असले तरीही शक्य तितक्या उच्च अचूकता राखणे महत्त्वाचे आहे.

विलंबाचे अनेक अर्थ आहेत

विलंब म्हणजे काय याबद्दल आपण डझनभर तज्ञांना विचारल्यास, आपल्याला कदाचित भिन्न उत्तरे मिळतील. DBMS मध्ये लेटन्सीला अनेकदा "डेटाबेस लेटन्सी" असे म्हटले जाते आणि क्लायंटच्या लक्षात येण्यापेक्षा वेगळे असते. वस्तुस्थिती अशी आहे की क्लायंट नेटवर्क विलंब आणि डेटाबेस विलंब यांची बेरीज पाहतो. वाढत्या समस्यांना डीबग करताना विलंबाचा प्रकार वेगळे करण्याची क्षमता महत्त्वाची असते. मेट्रिक्स गोळा करताना आणि प्रदर्शित करताना, नेहमी दोन्ही प्रकारांवर लक्ष ठेवण्याचा प्रयत्न करा.

विशिष्ट व्यवहारासाठी कार्यप्रदर्शन आवश्यकतांचे मूल्यांकन केले पाहिजे

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

टेबल X मध्ये नवीन पंक्ती (50 दशलक्ष पंक्तींसह) समाविष्ट करताना थ्रूपुट आणि लेटन्सी लिहा आणि संबंधित सारण्यांमध्ये निर्दिष्ट मर्यादा आणि रो पॅडिंगसह
मित्रांची सरासरी संख्या 500 असताना विशिष्ट वापरकर्त्याच्या मित्रांचे मित्र प्रदर्शित करण्यात विलंब.
जेव्हा वापरकर्ता प्रति तास X नोंदीसह 100 इतर वापरकर्त्यांना फॉलो करतो तेव्हा वापरकर्त्याच्या इतिहासातील शीर्ष 500 नोंदी पुनर्प्राप्त करण्यात विलंब.

डेटाबेस कार्यक्षमतेच्या आवश्यकता पूर्ण करतो याची खात्री होईपर्यंत मूल्यांकन आणि प्रयोगात अशा गंभीर प्रकरणांचा समावेश असू शकतो. लेटन्सी मेट्रिक्स गोळा करताना आणि SLO निर्धारित करतानाही असाच नियम हा ब्रेकडाउन लक्षात घेतो.

प्रत्येक ऑपरेशनसाठी मेट्रिक्स गोळा करताना उच्च कार्डिनॅलिटीची जाणीव ठेवा. उच्च-शक्ती डीबगिंग डेटा प्राप्त करण्यासाठी लॉग, इव्हेंट संकलन किंवा वितरित ट्रेसिंग वापरा. लेखात "लेटन्सी डीबग करू इच्छिता?» तुम्ही स्वतःला विलंब डीबगिंग पद्धतींसह परिचित करू शकता.

नेस्टेड व्यवहार धोकादायक असू शकतात

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

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

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

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

वरील कोडचे आउटपुट काय असेल? हे दोन्ही व्यवहार मागे घेईल की फक्त अंतर्गत व्यवहार? आपल्यासाठी व्यवहारांची निर्मिती करणाऱ्या ग्रंथालयांच्या अनेक स्तरांवर आपण अवलंबून राहिल्यास काय होईल? अशी प्रकरणे ओळखून त्यात सुधारणा करू शकू का?

एकाधिक ऑपरेशन्ससह डेटा लेयरची कल्पना करा (उदा. newAccount) आधीच त्याच्या स्वतःच्या व्यवहारांमध्ये लागू केले आहे. तुम्ही त्यांना उच्च-स्तरीय व्यवसाय तर्कशास्त्राचा भाग म्हणून चालवल्यास काय होईल जे स्वतःच्या व्यवहारात चालते? या प्रकरणात वेगळेपणा आणि सातत्य काय असेल?

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

अशा अंतहीन प्रश्नांची उत्तरे शोधण्याऐवजी नेस्टेड व्यवहार टाळलेलेच बरे. शेवटी, तुमचा डेटा स्तर स्वतःचे व्यवहार न बनवता उच्च-स्तरीय ऑपरेशन्स सहजपणे करू शकतो. याव्यतिरिक्त, व्यवसाय तर्कशास्त्र स्वतःच व्यवहार सुरू करण्यास, त्यावर ऑपरेशन्स करण्यास, व्यवहार करण्यास किंवा रद्द करण्यास सक्षम आहे.

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

व्यवहार अर्जाच्या स्थितीशी जोडले जाऊ नयेत

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

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

वरील व्यवहार अंतिम परिणामाकडे दुर्लक्ष करून, प्रत्येक वेळी अंमलात आणल्यावर क्रम संख्या वाढवेल. नेटवर्क समस्यांमुळे कमिट अयशस्वी झाल्यास, तुम्ही पुन्हा प्रयत्न कराल तेव्हा विनंती वेगळ्या क्रम क्रमांकासह अंमलात येईल.

क्वेरी प्लॅनर तुम्हाला डेटाबेसबद्दल बरेच काही सांगू शकतात

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

SELECT * FROM articles where author = "rakyll" order by title;

परिणाम दोन प्रकारे पुनर्प्राप्त केले जाऊ शकतात:

संपूर्ण टेबल स्कॅन: तुम्ही टेबलमधील प्रत्येक एंट्री पाहू शकता आणि लेखकाच्या नावाशी जुळणारे लेख परत करू शकता आणि नंतर त्यांना ऑर्डर करू शकता.
इंडेक्स स्कॅन: तुम्ही जुळणारे आयडी शोधण्यासाठी, त्या पंक्ती मिळवण्यासाठी आणि नंतर त्यांना ऑर्डर करण्यासाठी अनुक्रमणिका वापरू शकता.

कोणती रणनीती सर्वोत्तम आहे हे ठरवणे हे क्वेरी प्लॅनरचे काम आहे. हे लक्षात घेण्यासारखे आहे की क्वेरी प्लॅनरकडे केवळ मर्यादित अंदाज क्षमता असते. यामुळे चुकीचे निर्णय होऊ शकतात. DBAs किंवा डेव्हलपर त्यांचा वापर कमी कामगिरी करणार्‍या क्वेरीचे निदान करण्यासाठी आणि छान-ट्यून करण्यासाठी करू शकतात. DBMS च्या नवीन आवृत्त्या क्वेरी प्लॅनर कॉन्फिगर करू शकतात आणि नवीन आवृत्तीमुळे कार्यप्रदर्शन समस्या उद्भवल्यास डेटाबेस अद्यतनित करताना स्व-निदान मदत करू शकते. स्लो क्वेरी लॉग, लेटन्सी इश्यू रिपोर्ट्स किंवा एक्झिक्यूशन टाइम स्टॅटिस्टिक्स ऑप्टिमायझेशन आवश्यक असलेल्या क्वेरी ओळखण्यात मदत करू शकतात.

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

ऑनलाइन स्थलांतर अवघड आहे पण शक्य आहे

ऑनलाइन स्थलांतर, थेट स्थलांतर किंवा रिअल-टाइम स्थलांतर म्हणजे डाउनटाइम किंवा डेटा करप्शनशिवाय एका डेटाबेसमधून दुसर्‍या डेटाबेसमध्ये जाणे. जर संक्रमण समान DBMS/इंजिनमध्ये झाले असेल तर थेट स्थलांतर करणे सोपे आहे. जेव्हा भिन्न कार्यप्रदर्शन आणि स्कीमा आवश्यकतांसह नवीन DBMS वर जाणे आवश्यक असते तेव्हा परिस्थिती अधिक क्लिष्ट होते.

विविध ऑनलाइन स्थलांतर मॉडेल आहेत. त्यापैकी एक येथे आहे:

दोन्ही डेटाबेसमध्ये डबल एंट्री सक्षम करा. या टप्प्यावर नवीन डेटाबेसमध्ये सर्व डेटा नाही, परंतु केवळ नवीनतम डेटा स्वीकारतो. एकदा तुम्हाला याची खात्री पटली की, तुम्ही पुढील पायरीवर जाऊ शकता.
दोन्ही डेटाबेसमधून वाचन सक्षम करा.
प्रणाली कॉन्फिगर करा जेणेकरून वाचन आणि लेखन मुख्यतः नवीन डेटाबेसवर केले जाईल.
जुन्या डेटाबेसमधून डेटा वाचत असताना त्यावर लिहिणे थांबवा. या टप्प्यावर, नवीन डेटाबेस अद्याप काही डेटापासून रहित आहे. ते जुन्या डेटाबेसमधून कॉपी केले पाहिजेत.
जुना डेटाबेस केवळ वाचनीय आहे. जुन्या डेटाबेसमधील गहाळ डेटा नवीनमध्ये कॉपी करा. स्थलांतर पूर्ण झाल्यानंतर, मार्ग नवीन डेटाबेसवर स्विच करा आणि जुना थांबवा आणि सिस्टममधून हटवा.

अतिरिक्त माहितीसाठी, मी संपर्क साधण्याची शिफारस करतो लेख, जे या मॉडेलवर आधारित स्ट्राइपच्या स्थलांतर धोरणाचा तपशील देते.

डेटाबेसमध्ये लक्षणीय वाढ अप्रत्याशिततेमध्ये वाढ करते

डेटाबेसच्या वाढीमुळे त्याच्या स्केलशी संबंधित अप्रत्याशित समस्या उद्भवतात. डेटाबेसच्या अंतर्गत संरचनेबद्दल आपल्याला जितके अधिक माहिती असेल, तितके चांगले आपण अंदाज लावू शकतो की ते कसे मोजले जाईल. तथापि, काही क्षणांचा अंदाज लावणे अद्याप अशक्य आहे.
जसजसा बेस वाढतो, डेटा व्हॉल्यूम आणि नेटवर्क बँडविड्थ आवश्यकतांबद्दल पूर्वीच्या गृहीतके आणि अपेक्षा कालबाह्य होऊ शकतात. हे असे आहे जेव्हा संभाव्य समस्या टाळण्यासाठी प्रमुख डिझाइन दुरुस्ती, मोठ्या प्रमाणात ऑपरेशनल सुधारणा, पुनर्विचार उपयोजन किंवा इतर DBMSs मध्ये स्थलांतर करण्याचा प्रश्न उद्भवतो.

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

...

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

PS

आमच्या ब्लॉगवर देखील वाचा:

स्त्रोत: www.habr.com

अधिक विकासकांना डेटाबेसबद्दल हे माहित असले पाहिजे