SQL Azure Federations के साथ वास्तविक प्रोजेक्ट का डेटाबेस स्केल करें। भाग 2: इनपुट

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

इसलिए, हमारी परियोजना पर वापस जाएं। डेटाबेस का विषय क्षेत्र व्यक्तिगत वित्त लेखांकन है। डेटाबेस आरेख चित्र में दिखाया गया है।



जैसा कि हम देखते हैं कि डेटाबेस काफी सरल है। प्रत्येक सिस्टम ऑब्जेक्ट बुनियादी गुणों (आईडी, नाम, विवरण) के साथ एक इकाई है। विशिष्ट इकाइयाँ खाता हैं (इनसे विरासत में मिला: बैंक खाता, क्रेडिट कार्ड), खर्च करने वाली श्रेणी (इससे विरासत में मिली: बजट, साथ ही बाल श्रेणियां) और खाता लेनदेन।

तालिकाओं के अलावा, डेटाबेस में विशिष्ट प्रश्नों के परिणामों को प्रदर्शित करने के लिए डेटाबेस में इकाइयाँ जोड़ने के लिए कुछ तर्क सम्‍मिलित हैं (संग्रहीत कार्यविधियों के रूप में तैयार), साथ ही साथ कुछ दृश्य भी।

SQL स्क्रिप्ट डेटाबेस बनाने के लिए स्रोत कोड यहां पाया जा सकता है ।



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

के विश्लेषण

SQL Azure Federations का उपयोग करने के लिए किसी डेटाबेस को स्थानांतरित करने से पहले, आपको यह निर्धारित करना होगा कि डेटाबेस में कौन सा डेटा तार्किक रूप से स्वतंत्र है। विभिन्न डेटाबेस में किस प्रकार का डेटा वितरित किया जा सकता है। वास्तव में, आपको एक तालिका का चयन करना होगा जिसका डेटा कई डेटाबेसों में विभाजित होगा, तथाकथित फ़ेडरेटेड टेबल।



यदि हम डेटाबेस की संरचना को देखते हैं, तो पहला उम्मीदवार दिमाग में आता है, संस्थाओं की एक मूल तालिका (इकाई) है। इस तालिका को बनाने की पटकथा इस प्रकार है:
CREATE TABLE Entity (
[Id] INTEGER NOT NULL PRIMARY KEY IDENTITY(1,1),
[Name] NVARCHAR(MAX) NOT NULL,
[Description] NVARCHAR(MAX) NOT NULL,
)

पहली नज़र में, यह तालिका विभाजन के लिए आदर्श है। हालाँकि, ऐसा नहीं है। हां, इसमें विदेशी कुंजी नहीं है, इसकी एक काफी सरल संरचना है, और इसमें रिकॉर्ड किए गए अधिकतम रिकॉर्ड हैं। हालांकि, डेटाबेस के तर्क के अनुसार, "उत्तराधिकारी तालिकाओं" से डेटा इस तालिका से जुड़ा हुआ है। यही है, सिस्टम में बनाई गई सभी संस्थाओं में एंटिटी टेबल में एक प्रविष्टि है।

इस उदाहरण पर विचार करें। मान लीजिए कि हम डेटा को संस्थाओं की पहचानकर्ता (आईडी क्षेत्र) की एक सीमा में तोड़ते हैं। मान लें कि आईडी के साथ रिकॉर्ड 1-50 पहले शार्क में संग्रहीत हैं, दूसरे में 51-100, और इसी तरह।



उपयोगकर्ता ऑपरेशन तालिका में एक नया रिकॉर्ड जोड़ने की कोशिश कर रहा है। इसे दूध के पैकेज की खरीद पर डेटा दें। मान लें कि खाता इकाई आईडी 1 है, व्यय श्रेणी आईडी 6 है। हम यह भी मानते हैं कि पहले डेटाबेस में पहले से ही 50 रिकॉर्ड हैं, जिसका अर्थ है कि नए रिकॉर्ड को 51 के बराबर एक पहचानकर्ता मिलना चाहिए, अर्थात दूसरे शार्क में प्रवेश करें।

तालिका में नया डेटा जोड़ने का अनुरोध इस प्रकार होगा:
USE FEDERATION Entities(EntityId = 51) WITH RESET, FILTERING = OFF
GO
INSERT INTO Operation VALUES (
51, -- EntityId
1, -- AccountId
6, -- CategoryId
GETDATE(), -- Date
10, -- Amount
'USD' -- Currency
)

अनुरोध को बिल्कुल सही तरीके से निष्पादित किया जाएगा। आइए अब इस खाते (आईडी = 1) के सभी कार्यों की एक सूची प्राप्त करने का प्रयास करें। इसके लिए डेटाबेस में एक संगत दृश्य है। इसका कोड इस प्रकार है:
SELECT
Account_Entity.Description AS 'Account',
Operation_Entity.Name AS 'Operation',
Operation_Entity.Description,
Operation.Amount,
Operation.Currency,
Operation.Date
FROM
Operation
INNER JOIN Entity AS Operation_Entity ON Operation.EntityId = Operation_Entity.Id
INNER JOIN Account ON Operation.AccountId = Account.Id
INNER JOIN Entity AS Account_Entity ON Account.EntityId = Account_Entity.Id
INNER JOIN Category ON Operation.CategoryId = Category.Id
INNER JOIN Entity AS Category_Entity ON Category.EntityId = Category_Entity.Id
WHERE
Account.Id = 1

जैसा कि हम याद करते हैं, एक खाते का डेटा विभिन्न शार्क पर संग्रहीत किया जाता है। इसलिए, इस क्वेरी के लिए सही परिणाम लौटाने के लिए, इसे प्रत्येक शार्क पर अलग से किया जाना चाहिए।
USE FEDERATION Entities(EntityId = 1) WITH RESET, FILTERING = OFF
GO
...
USE FEDERATION Entities(EntityId = 51) WITH RESET, FILTERING = OFF
GO
...

मुझे लगता है कि इस दृष्टिकोण से आवेदन प्रदर्शन के लिए एक बड़ा झटका क्या होगा, यह समझाने की आवश्यकता नहीं है। यहां तक ​​कि अगर सबसे सरल क्वेरी को अब दो बार निष्पादित करने की आवश्यकता है! जाहिर है, एंटिटी टेबल हमारे लिए उपयुक्त नहीं है।

यदि हम डेटाबेस डिजाइन के लिए बहु-किरायेदार दृष्टिकोण को याद करते हैं, जब प्रत्येक उपयोगकर्ता अपने डेटाबेस के साथ काम करता है और उनका डेटा ओवरलैप नहीं होता है, तो सवाल उठता है। क्या SQL Azure Federations के ढांचे के भीतर कुछ समान लागू करना संभव है? जहां प्रत्येक शार्क में एक उपयोगकर्ता (खाता) का डेटा होगा। वास्तव में, यह दृष्टिकोण काफी तार्किक होगा। व्यावसायिक तर्क की दृष्टि से, यह इस तरह दिखेगा:

मान लीजिए कि एक परिवार के सदस्य एक कार्यक्रम का उपयोग करते हैं। उनमें से प्रत्येक अलग से एक बजट बनाए रखता है। यह भी मान लें कि पति अपने खाते का संचालन करता है, पत्नी - उसका। इस प्रकार, पति का डेटा (खाता = 1) पत्नी के डेटा (खाता २ = २) के साथ ओवरलैप नहीं होता है। इस मामले में, खातों की तालिका द्वारा शार्क में विभाजित करना काफी तर्कसंगत लगता है।



एक नया खाता जोड़ना एक शार्द को जोड़ने के अनुरूप होगा। बार-बार किए जाने वाले ऑपरेशन, जैसे: श्रेणियों की सूची, संचालन आदि के साथ काम करने से उत्पादकता में कमी नहीं होगी।
USE FEDERATION Accounts(AccountId = 1) WITH RESET, FILTERING = OFF
GO

इस तरह के अनुरोध को निष्पादित करने के बाद, यह तुरंत स्पष्ट है कि हम वर्तमान में किस उपयोगकर्ता के साथ काम कर रहे हैं। इसलिए एक ही ऑपरेशन केवल एक बार किया जाएगा।

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