कोई स्पष्ट समाधान नहीं है क्योंकि यह पूरी तरह से आपके संदर्भ पर निर्भर करता है - विशेष रूप से, आपके सिस्टम को किन आयामों के साथ स्केल करना है और आपकी वास्तविक समस्याएं क्या हैं। क्या डेटाबेस वास्तव में आपकी अड़चन है?
यह (दुर्भाग्य से लंबा) उत्तर थोड़ा सा पढ़ा होगा जैसे "microservices खराब हैं, जीवन के लिए अखंड हैं!", लेकिन यह मेरा इरादा नहीं है। मेरा कहना है कि माइक्रोसोर्सेज और डिस्ट्रिब्यूटेड डेटाबेस विभिन्न समस्याओं को हल कर सकते हैं, लेकिन अपने स्वयं के कुछ मुद्दों के बिना नहीं। अपनी वास्तुकला के लिए एक मजबूत तर्क बनाने के लिए, आपको यह दिखाना होगा कि ये मुद्दे लागू नहीं होते हैं, इसे कम किया जा सकता है, और यह कि यह वास्तुकला आपके व्यवसाय की जरूरतों के लिए सबसे अच्छा विकल्प है।
वितरित डेटा मुश्किल है।
एक ही लचीलापन जो बेहतर स्केलिंग को सक्षम करता है, वह कमजोर गारंटी का फ्लिप पक्ष है। विशेष रूप से, वितरित सिस्टम के बारे में तर्क करने के लिए बहुत कठिन हैं।
परमाणु अद्यतन, लेन-देन, संगति / संदर्भात्मक अखंडता, और स्थायित्व अत्यंत मूल्यवान हैं और इसे रोषपूर्वक माफ नहीं किया जाना चाहिए। डेटा अपूर्ण है, अगर यह अधूरा है, पुराना है, या गलत है, तो इसका कोई मतलब नहीं है। जब आपके पास ACID एक व्यावसायिक आवश्यकता के रूप में है, लेकिन डेटाबेस तकनीक का उपयोग कर रहे हैं जो इसे बॉक्स से बाहर की पेशकश नहीं कर सकते हैं (उदाहरण के लिए कई NoSQL डेटाबेस, या DB-per-microservice वास्तुकला), तो आपके आवेदन को अंतर भरना होगा और उन गारंटियों को प्रदान करना होगा।
यह करना असंभव नहीं है, लेकिन सही पाने के लिए मुश्किल है। बहुत मुश्किल है। विशेष रूप से एक वितरित सेटिंग में जहां प्रत्येक डेटाबेस के लिए कई लेखक हैं। यह कठिनाई संभवत: गिराए गए डेटा, असंगत डेटा, और इसी तरह, बग के एक उच्च अवसर का अनुवाद करती है।
उदाहरण के लिए, जाने-माने वितरित डेटाबेस सिस्टम के जेपसेन विश्लेषणों को पढ़ने पर विचार करें , शायद कैसेंड्रा के विश्लेषण के साथ शुरू करना । मैं उस विश्लेषण के आधे हिस्से को नहीं समझता, लेकिन टीएल; डीआर; डिस्ट्रीब्यूटेड सिस्टम इतना कठिन है कि उद्योग की अग्रणी परियोजनाएं भी कभी-कभी उन्हें गलत कर देती हैं, उन तरीकों से जो स्पष्ट रूप से स्पष्ट दिख सकते हैं।
वितरित सिस्टम भी विकास का एक बड़ा प्रयास है। कुछ हद तक, बीफ़ियर हार्डवेयर पर विकास लागत या पैसा छोड़ने के बीच सीधा व्यापार बंद है।
उदाहरण: झूलते संदर्भ
व्यवहार में, आपको कंप्यूटर विज्ञान को नहीं बल्कि अपने व्यावसायिक आवश्यकताओं को देखना चाहिए कि क्या और कैसे ACID को आराम दिया जा सकता है। उदाहरण के लिए, कई विदेशी-कुंजी रिश्ते उतने महत्वपूर्ण नहीं हो सकते हैं जितने वे लगते हैं। एक उत्पाद पर विचार करें - श्रेणी n: m संबंध। RDBMS में हम एक विदेशी-कुंजी बाधा का उपयोग कर सकते हैं ताकि केवल मौजूदा उत्पाद और मौजूदा श्रेणियां उस रिश्ते का हिस्सा बन सकें। यदि हम अलग-अलग उत्पाद और श्रेणी सेवाएँ पेश करते हैं, और एक उत्पाद या श्रेणी हटा दी जाती है तो क्या होता है?
इस मामले में, यह एक बड़ी समस्या नहीं हो सकती है और हम अपना आवेदन लिख सकते हैं ताकि यह किसी भी उत्पाद या श्रेणियों को फ़िल्टर कर दे जो अब मौजूद नहीं है। लेकिन वहाँ व्यापार कर रहे हैं!
ध्यान दें कि इसके लिए JOINकई डेटाबेस / माइक्रोसर्विसेज पर एप्लिकेशन-लेवल की आवश्यकता हो सकती है , जो केवल डेटाबेस सर्वर से आपके एप्लिकेशन में प्रोसेसिंग को स्थानांतरित करता है। इससे कुल भार बढ़ता है और नेटवर्क के माध्यम से अतिरिक्त डेटा को स्थानांतरित करना पड़ता है।
यह पेजिंग के साथ गड़बड़ कर सकता है। उदाहरण के लिए, आप एक श्रेणी से अगले 25 उत्पादों का अनुरोध करते हैं, और उस प्रतिक्रिया से अनुपलब्ध उत्पादों को फ़िल्टर करते हैं। अब आपका आवेदन 23 उत्पादों को प्रदर्शित करता है। सिद्धांत रूप में, शून्य उत्पादों वाला एक पृष्ठ भी संभव होगा!
आप कभी-कभार ऐसी स्क्रिप्ट चलाना चाहेंगे जो प्रत्येक प्रासंगिक परिवर्तन के बाद या नियमित अंतराल पर झूलने वाले संदर्भों को साफ कर दे। ध्यान दें कि इस तरह की स्क्रिप्ट काफी महंगी हैं, क्योंकि उन्हें बैकिंग डेटाबेस / माइक्रोसर्विस से हर उत्पाद / श्रेणी का अनुरोध करना होता है, यह देखने के लिए कि क्या यह अभी भी मौजूद है।
यह स्पष्ट होना चाहिए, लेकिन स्पष्टता के लिए: आईडी का पुन: उपयोग न करें। स्वत: अंकन शैली आईडी ठीक हो भी सकती है और नहीं भी। GUID या हैश आपको अधिक लचीलापन देते हैं, जैसे कि आइटम को डेटाबेस में डालने से पहले एक आईडी असाइन करने में सक्षम होना।
उदाहरण: समवर्ती आदेश
अब इसके बजाय एक उत्पाद पर विचार - आदेश संबंध। यदि कोई उत्पाद हटा दिया जाता है या बदल जाता है, तो ऑर्डर का क्या होता है? ठीक है, हम बस इसे उपलब्ध रखने के लिए ऑर्डर एंट्री में संबंधित उत्पाद डेटा की प्रतिलिपि बना सकते हैं - सादगी के लिए ट्रेडिंग डिस्क स्थान। लेकिन क्या होगा यदि उत्पाद की कीमत बदल जाए या उत्पाद उस उत्पाद के लिए ऑर्डर से ठीक पहले अनुपलब्ध हो जाए? एक वितरित प्रणाली में, प्रभावों को प्रचार करने में समय लगता है और आदेश संभवतः पुराने डेटा के माध्यम से जाएगा।
फिर, यह कैसे दृष्टिकोण करना है यह आपकी व्यावसायिक आवश्यकताओं पर निर्भर करता है। हो सकता है कि पुराना आदेश स्वीकार्य हो और आप बाद में उस आदेश को रद्द कर सकते हैं यदि वह पूरा नहीं किया जा सकता।
लेकिन शायद यह एक विकल्प नहीं है, जैसे अत्यधिक समवर्ती सेटिंग्स के लिए। पहले 10 सेकंड के भीतर कॉन्सर्ट टिकट खरीदने के लिए 3000 लोगों की भीड़ पर विचार करें, और मान लें कि उपलब्धता में बदलाव के लिए प्रचार करने के लिए 10ms की आवश्यकता होगी। कई लोगों को आखिरी टिकट बेचने की संभावना क्या है? इस बात पर निर्भर करता है कि उन टकरावों को कैसे संभाला जाता है, लेकिन λ = 3000 / (10s / 10ms) = 3हमारे साथ एक पॉइसन वितरण का उपयोग करके P(k > 1) = 1 - P(k = 0) - P(k = 1) = 80%प्रति 10ms अंतराल पर टक्कर का मौका मिलता है । चाहे बेचना और बाद में आपके अधिकांश आदेशों को रद्द करना संभव हो, बिना धोखाधड़ी किए आपके कानूनी विभाग के साथ एक दिलचस्प बातचीत हो सकती है।
व्यावहारिकता का अर्थ है, सबसे अच्छी विशेषताएं चेरी-पिकिंग।
अच्छी खबर यह है कि आपको किसी वितरित डेटाबेस मॉडल में जाने की जरूरत नहीं है, अगर यह अन्यथा आवश्यक नहीं है। यदि आप माइक्रोसेवा को "ठीक से" नहीं करते हैं, तो कोई भी आपके माइक्रोसॉर्स्क क्लब की सदस्यता को रद्द नहीं करेगा, क्योंकि ऐसा कोई क्लब नहीं है - और कोई भी सही तरीका नहीं है।
व्यावहारिकता हर बार जीतती है, इसलिए विभिन्न दृष्टिकोणों को मिलाएं और मिलान करें क्योंकि वे आपकी समस्या को हल करते हैं। यह भी एक केंद्रीकृत डेटाबेस के साथ microservices मतलब हो सकता है। अगर आपको नहीं करना है तो वास्तव में, वितरित डेटाबेस के दर्द से मत गुजरो।
आप बिना microservices के पैमाने कर सकते हैं।
माइक्रोसर्विस के दो प्रमुख लाभ हैं:
- संगठनात्मक लाभ जो उन्हें अलग-अलग टीमों द्वारा स्वतंत्र रूप से विकसित और तैनात किया जा सकता है (जो बदले में स्थिर इंटरफ़ेस की पेशकश करने के लिए सेवाओं की आवश्यकता होती है)।
- परिचालन लाभ जो प्रत्येक माइक्रोसेवा को स्वतंत्र रूप से बढ़ाया जा सकता है ।
यदि स्वतंत्र स्केलिंग की आवश्यकता नहीं है, तो माइक्रोसॉर्क्स बहुत कम आकर्षक हैं।
एक डेटाबेस सर्वर पहले से ही एक प्रकार की सेवा है जिसे आप स्वतंत्र रूप से (कुछ) स्केल कर सकते हैं, उदाहरण के लिए रीड प्रतिकृतियां जोड़कर। आप संग्रहीत प्रक्रियाओं का उल्लेख करते हैं। उन्हें कम करने से इतना बड़ा प्रभाव हो सकता है कि किसी भी अन्य स्केलेबिलिटी की चर्चा मूट हो।
और यह एक स्केलेबल मोनोलिथ होना पूरी तरह से संभव है जिसमें पुस्तकालयों के रूप में सभी सेवाएं शामिल हैं। फिर आप मोनोलिथ के अधिक उदाहरणों को लॉन्च करके स्केल कर सकते हैं, जिनमें से प्रत्येक को निश्चित रूप से स्टेटलेस होना चाहिए।
यह तब तक अच्छी तरह से काम करता है जब तक कि मोनोलिथ यथोचित रूप से तैनात होने के लिए बहुत बड़ा न हो, या यदि कुछ सेवाओं के लिए विशेष संसाधन आवश्यकताएं हों, ताकि आप उन्हें स्वतंत्र रूप से स्केल करना चाहें। अतिरिक्त डोमेन को शामिल करने वाले समस्या डोमेन में एक अलग डेटा मॉडल शामिल नहीं हो सकता है।
क्या आपके पास एक मजबूत व्यवसाय मामला है?
आप अपने संगठन की व्यावसायिक आवश्यकताओं से अवगत हैं, और इसलिए विश्लेषण के आधार पर डेटाबेस-प्रति-माइक्रो-आर्किटेक्चर के लिए एक तर्क बना सकते हैं:
- एक निश्चित पैमाने की आवश्यकता होती है, और यह वास्तुकला उस स्केलेबिलिटी को प्राप्त करने के लिए सबसे अधिक लागत प्रभावी तरीका है, इस तरह के सेटअप और वैकल्पिक समाधानों के लिए विकास के प्रयास को ध्यान में रखते हुए; तथा
- आपके व्यवसाय की आवश्यकताएं प्रासंगिक ACID गारंटी को आराम करने की अनुमति देती हैं, जैसे कि ऊपर चर्चा की गई विभिन्न समस्याओं के बिना।
इसके विपरीत, यदि आप इसे प्रदर्शित करने में असमर्थ हैं, विशेष रूप से यदि वर्तमान डेटाबेस डिजाइन भविष्य में पर्याप्त पैमाने का समर्थन करने में सक्षम है (जैसा कि आपके सहकर्मियों का मानना है), तो आपके पास भी आपका जवाब है।
स्केलेबिलिटी के लिए एक बड़ा YAGNI घटक भी है। अनिश्चितता का सामना करते हुए, यह अब स्केलेबिलिटी के लिए निर्माण पर एक रणनीतिक व्यवसाय निर्णय है (कम कुल लागत, लेकिन इसमें अवसर लागत शामिल है और इसकी आवश्यकता नहीं हो सकती है) बनाम स्केलेबिलिटी पर कुछ काम को विस्थापित करना (उच्च कुल लागत यदि आवश्यक हो, लेकिन आपके पास बेहतर है वास्तविक पैमाने का विचार)। यह मुख्य रूप से तकनीकी निर्णय नहीं है।