SQL Azure Federations के साथ वास्तविक प्रोजेक्ट डेटाबेस स्केल करें

sharding

क्लाउड में अनुप्रयोगों को स्केल करने का मुद्दा बहुत आम है। क्लाउड टेक्नोलॉजी की बहुत अवधारणा में मांग पर स्केलिंग एप्लिकेशन शामिल हैं। कोई भी स्वाभिमानी क्लाउड प्रदाता संबंधित कार्यों का समर्थन करता है।

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

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

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

यदि हम Microsoft से क्लाउड प्लेटफ़ॉर्म की क्षमताओं पर विचार करते हैं, तो वे काफी विस्तृत हैं। ऑटो-स्केलिंग, मांग पर स्केलिंग है, और यह सब यूआई का उपयोग करके और एसडीके, रीस्ट एपीआई और पावरशेल दोनों का उपयोग करके उपलब्ध है।

हालाँकि, यदि किसी एप्लिकेशन (PaS) या वर्चुअल मशीन (IaaS) को स्केल करना काफी सरल है, तो निर्दिष्ट करें कि आपको कितने उदाहरणों की आवश्यकता है, बहुत सारे होंगे, यदि आपका एप्लिकेशन MS SQL डेटाबेस का उपयोग करता है, तो कई प्रश्न उठते हैं। बेशक, पहली बात जो दिमाग में आती है, वह SQL सर्वर वर्चुअल मशीनों के क्लस्टर को व्यवस्थित करना है। समाधान काफी सरल और सभी के लिए परिचित है। लेकिन क्या होगा यदि एप्लिकेशन डेटाबेस को सेवा (SaaS) के रूप में उपयोग करता है? यदि हम SQL सर्वर क्लस्टर को कॉन्फ़िगर नहीं करना चाहते हैं तो क्या होगा?

बेशक, अगर हम Windows Azure के बारे में बात कर रहे हैं, तो SQL Azure का उपयोग SQL डेटाबेस के रूप में किया जाएगा। यह डेटाबेस SQL ​​अज़ूर फ़ेडरेशंस नामक क्षैतिज स्केलिंग (शार्किंग) की तकनीक का समर्थन करता है। इसके संचालन का सिद्धांत बहुत सरल है: तार्किक रूप से एक तालिका के प्रत्येक अन्य पंक्तियों से अलग-अलग डेटाबेस में संग्रहीत किया जाता है। सबसे सरल उदाहरण:



यह एक ही तालिका है जिसका डेटा विभिन्न डेटाबेस इंस्टेंसेस (शार्क) में संग्रहित है। यही है, पहचानकर्ता 1 के साथ खाता डेटा पहले डेटाबेस में संग्रहीत किया जाता है, पहचानकर्ता 2 के साथ - दूसरे में, आदि।

Azure SQL सीमाएँ

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

डेटाबेस से डेटा सैंपलिंग की गति बढ़ जाती है, क्योंकि किसी विशेष शार्क में संग्रहीत डेटा का आकार डेटाबेस की कुल राशि से छोटे परिमाण का एक क्रम है।

हालांकि, किसी भी तकनीक की अपनी कमियां हैं। शेयरिंग कोई अपवाद नहीं है। आइए ऊपर वर्णित उदाहरण डेटाबेस का उपयोग करते हुए शार्किंग तकनीक का उपयोग करते समय होने वाले नुकसान के बारे में सोचें?

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

मूल अनुरोध:
SELECT Count(*) FROM Account

विशिष्ट शार्क के लिए उदाहरण अनुरोध:
USE FEDERATION Accounts(AccountId = 4) WITH RESET, FILTERING = OFF
GO
SELECT Count(*) FROM Account

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

प्रस्तावना

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

यदि आपको एक नया उपयोगकर्ता जोड़ने की आवश्यकता है, तो हम उसके लिए एक अलग डेटाबेस कॉन्फ़िगर करेंगे। सवाल यह है कि आवेदन तर्क में एक "रूटिंग" तंत्र होना चाहिए। यही है, एप्लिकेशन को पता होना चाहिए कि वह वर्तमान में किस डेटाबेस के साथ काम कर रहा है।

लेकिन Azure Federations SQL में वापस ...
Microsoft का विचार बहुत सराहनीय है। एक उपकरण प्राप्त करना अच्छा होगा जो डेटाबेस को हस्तमैथुन करना आसान बनाता है। और ऑटो-स्केलिंग करने के लिए, कुछ प्रश्नों के परिणामों के आधार पर (ठीक है, यह पहले से ही शानदार है) ...

हालांकि, एक नियम के रूप में, SQL Azure Federations का उपयोग करने के लिए स्विच करने का अंतिम निर्णय लेने से पहले, मौजूदा डेटाबेस का सावधानीपूर्वक विश्लेषण करना आवश्यक है (और, एक नियम के रूप में, पहले से मौजूद डेटाबेस स्थानांतरित हो जाते हैं), या डेटाबेस के आर्किटेक्चर के छोटे विवरणों के माध्यम से सोचें कि एप्लिकेशन का उपयोग करेगा, साथ ही साथ तर्क भी। इस डेटाबेस के साथ काम करने के लिए आवेदन।

वे सिद्धांत को सुलझाते हैं। हालांकि, एक नियम के रूप में, अभ्यास में काफी बड़ी संख्या में रेक होते हैं जिन्हें आप आगे बढ़ा सकते हैं। इसलिए, यह दिखाने के बजाय कि खरोंच से SQL Azure Federations का उपयोग करना कितना आसान है, हम संघों का उपयोग करने के लिए मौजूदा Azure SQL डेटाबेस को स्थानांतरित करने का प्रयास करेंगे। उन चरणों पर विचार करें जो एक डीबीए को लेने की आवश्यकता है, साथ ही प्रवास चरण के दौरान आने वाली समस्याओं का सामना करना पड़ सकता है।

सामान्य तौर पर, स्विच न करें! कार्य सप्ताह के लिए एक अच्छी शुरुआत करें!