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

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

प्रवास

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

हम मानते हैं कि डेटाबेस पहले से ही विंडोज एज़्योर मैनेजमेंट पोर्टल या SQL सर्वर मैनेजमेंट स्टूडियो के माध्यम से बनाया गया है।

डेटाबेस में ऑब्जेक्ट बनाने के लिए स्क्रिप्ट खोलें।
USE xPenses
GO

IF EXISTS (SELECT name FROM sysobjects where name = N'Operation') DROP TABLE Operation
...

निकालने के लिए पहली चीज़ USE ऑपरेशन का उपयोग है, क्योंकि यह SQL Azure की मूल सीमाओं में से एक है। एक डेटाबेस - एक कनेक्शन। इसके बजाय, एक महासंघ बनाने के लिए अनुरोध जोड़ें:
-- A database must be selected before executing this statement
CREATE FEDERATION Accounts(AccountId BIGINT RANGE)
GO

USE FEDERATION Accounts(AccountId = 1) WITH RESET, FILTERING = OFF
GO

कृपया ध्यान दें कि उदाहरण के लिए, SSMS को SQL Azure Server से जोड़कर, आपको क्वेरी को पूरा करने के लिए सूची से एक डेटाबेस का चयन करना होगा।



इस प्रकार, हम एक नया फेडरेशन बनाएंगे, जिसका डेटा खाता पहचानकर्ता (खाता आईडी) के मूल्य द्वारा वितरित किया जाता है। कृपया ध्यान दें कि फिलहाल डेटाबेस में कोई तालिका नहीं बनाई गई है, अर्थात् खाता तालिका वास्तविक तालिकाओं में किसी भी डेटा सेट के साथ संबद्ध नहीं है। फ़ील्ड का नाम उस तालिका के फ़ील्ड के नाम से भी भिन्न हो सकता है जिसके द्वारा वितरण किया जाएगा।

यहां हम SQL Azure Federations की एक और, तार्किक, सीमा देख सकते हैं। जिस क्षेत्र में वितरण किया जाएगा वह INT, BIGINT, UNIQUEIDENTIFIER और VARBINARY प्रकार का होना चाहिए।

महासंघ बनाने के बाद, हमें पहले शार्क का चयन करने की आवश्यकता है जिसमें हम डेटा दर्ज करना शुरू करते हैं। यानी एक ऐसा शार्क जो पहले अकाउंट (खाता = 1) का डाटा स्टोर करता है।

हमारी स्क्रिप्ट नीचे देखें। हमें खातों की तालिका के निर्माण को संशोधित करने की आवश्यकता है ताकि SQL Azure को पता चले कि Id फ़ील्ड द्वारा इस तालिका का डेटा शार्क के साथ वितरित किया जाएगा।
CREATE TABLE Account (
[Id] INTEGER NOT NULL PRIMARY KEY IDENTITY(1,1),
[EntityId] INTEGER NOT NULL FOREIGN KEY REFERENCES Entity(Id),
[Currency] NVARCHAR(3)
)

इस प्रकार, तालिका निर्माण स्क्रिप्ट निम्नलिखित में बदल जाती है:
CREATE TABLE Account (
[Id] BIGINT NOT NULL,
[EntityId] INTEGER NOT NULL FOREIGN KEY REFERENCES Entity(Id),
[Currency] NVARCHAR(3),
CONSTRAINT [PK_Account] PRIMARY KEY CLUSTERED
(
[Id] ASC
)
) FEDERATED ON (AccountId= Id)

तो क्या बदल गया है? ID फ़ील्ड प्रकार BIGINT बन गया है। इसके अलावा, हमने एक नया रिकॉर्ड सम्मिलित करते समय इस फ़ील्ड के लिए स्वचालित रूप से मान उत्पन्न करने की क्षमता खो दी। यह SQL Azure Federations की एक और सीमा है। हालाँकि, आप अभी भी DEFAULT कीवर्ड का उपयोग कर सकते हैं। उदाहरण के लिए, यह उपयोगी होगा यदि ID फ़ील्ड का प्रकार UNIQUEIDENTIFIER है। इस मामले में, हम इस तरह से क्षेत्र की घोषणा कर सकते हैं:
[Id] UNIQUEIDENTIFIERNOT NULL DEFAULT NEWID()

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

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

अंतिम कार्य FEDERATED ON कीवर्ड के साथ इंगित करना है कि यह तालिका फ़ेडरेटेड होगी। इसमें डेटा को आईडी फ़ील्ड से विभाजित किया जाएगा।

इसलिए, खातों की एक तालिका के निर्माण के साथ, हम समझ गए। हम और आगे जा रहे हैं। जैसा कि आप डेटाबेस स्कीमा से देख सकते हैं, खाता तालिका "क्रेडिट कार्ड" और "बैंक खाता" तालिकाओं के संबंध में जनक है।





यही है, BankAccount और CreditCard तालिकाओं में खाता तालिका के लिए एक विदेशी कुंजी है। चूंकि खाता तालिका अब फ़ेडरेटेड है, इसलिए एक तालिका से दूसरी तालिका की अखंडता सुनिश्चित करना असंभव है।

यह SQL Azure Federations की एक और सीमा है । फ़ेडरेटेड टेबल डेटा टेबल को अन्य तालिकाओं में संदर्भित नहीं किया जा सकता है। यही है, यह आवश्यक होगा कि खातों की तालिका (खाता) को संदर्भित करने वाली तालिकाओं से सभी विदेशी कुंजी को हटा दें।

इस प्रकार, एक तालिका निर्माण स्क्रिप्ट, उदाहरण के लिए, क्रेडिट कार्ड, फॉर्म के बजाय:
CREATE TABLE CreditCard (
[Id] INTEGER NOT NULL PRIMARY KEY IDENTITY(1,1),
[AccountId] INTEGER NOT NULL FOREIGN KEY REFERENCES Account(id),
[Type] NVARCHAR(MAX)
CONSTRAINT CreditCardType CHECK (
[Type] = 'Visa'
OR [Type] = 'MasterCard'
OR [Type] = 'JCB'
OR [Type] = 'AmericanExpress'),
[Number] NVARCHAR(MAX)
)

फार्म लेंगे:
CREATE TABLE CreditCard (
[Id] INTEGER NOT NULL PRIMARY KEY IDENTITY(1,1),
[AccountId] BIGINT NOT NULL,
[Type] NVARCHAR(MAX)
CONSTRAINT CreditCardType CHECK (
[Type] = 'Visa'
OR [Type] = 'MasterCard'
OR [Type] = 'JCB'
OR [Type] = 'AmericanExpress'),
[Number] NVARCHAR(MAX)
)

यही है, क्रेडिट कार्ड तालिका से लेखा तालिका के रिकॉर्ड में लिंक की अखंडता आवेदन तर्क के कंधों पर टिकी हुई है।

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

लेकिन एक नया खाता (AddAccount) जोड़ने की प्रक्रिया में मामूली बदलाव की आवश्यकता है। तो इस प्रक्रिया के लिए स्रोत कोड पर विचार करें:
CREATE PROCEDURE AddAccount(
@Name NVARCHAR(MAX),
@Description NVARCHAR(MAX),
@Currency NVARCHAR(3),
@Instrument NVARCHAR(MAX),
@Type NVARCHAR(MAX),
@Number NVARCHAR(MAX)
)
AS
INSERT INTO Entity VALUES (@Name, @Description)
DECLARE @EntityId INTEGER = (SELECT Id FROM Entity WHERE Name = @Name AND Description = @Description)

INSERT INTO Account VALUES (@EntityId, @Currency)

IF (@Instrument = 'BankAccount')
BEGIN
INSERT INTO BankAccount VALUES (
(SELECT Id FROM Account WHERE Account.EntityId = @EntityId),
@Type,
@Number
) END

IF (@Instrument = 'CreditCard')
BEGIN
INSERT INTO CreditCard VALUES (
(SELECT Id FROM Account WHERE Account.EntityId = @EntityId),
@Type,
@Number
) END
GO

वास्तव में, जिन बदलावों की आवश्यकता है, वे काफी हद तक स्पष्ट हैं। चूंकि हमने किसी खाते के लिए आईडी फ़ील्ड मान को स्वचालित रूप से जनरेट करने की क्षमता खो दी है, इसलिए यह तर्क एप्लिकेशन लॉजिक के साथ टिकी हुई है। यही है, हमें प्रक्रिया हेडर में परिवर्तन करने की आवश्यकता है:
CREATE PROCEDURE AddAccount(
@AccountId BIGINT,
@Name NVARCHAR(MAX),
@Description NVARCHAR(MAX),
@Currency NVARCHAR(3),
@Instrument NVARCHAR(MAX),
@Type NVARCHAR(MAX),
@Number NVARCHAR(MAX)
)
AS
INSERT INTO Entity VALUES (@Name, @Description)
DECLARE @EntityId INTEGER = (SELECT Id FROM Entity WHERE Name = @Name AND Description = @Description)

INSERT INTO Account VALUES (@AccountId, @EntityId, @Currency)
...
GO

तदनुसार, कोड के बजाय लेखा तालिका में रिकॉर्ड सम्मिलित करना:
EXEC AddAccount 'Cash', 'Everyday cash account', 'USD', NULL, NULL, NULL

अब यह एक और पैरामीटर (खाता बनाए जाने की आईडी) को स्वीकार करेगा:
EXEC AddAccount 1, 'Cash', 'Everyday cash account', 'USD', NULL, NULL, NULL

संभवतः अगला तार्किक प्रश्न होगा: क्या प्रक्रिया के शरीर में वांछित महासंघ (USE FEDERATION) का उपयोग करने के लिए कमांड जोड़ना संभव है? चूंकि, यदि हम उस खाते की आईडी प्राप्त करते हैं जिसे हम बना रहे हैं, तो हम जानते हैं कि हमें किस फेडरेशन के साथ काम करने की आवश्यकता है, जिसका अर्थ है कि हम तुरंत आवश्यक शार्ड का उपयोग करने के लिए आगे बढ़ सकते हैं:
USE FEDERATION Accounts(AccountId = @AcccountId) WITH RESET, FILTERING = OFF
GO

दुर्भाग्य से, यदि आप ऐसा करते हैं, तो SSMS आपको एक त्रुटि देगा। बात यह है कि AddAccount प्रक्रिया एक विशिष्ट शार्क में संग्रहीत है, जिसका अर्थ है कि हमारे पास USE FEDERATION का उपयोग करने की क्षमता नहीं है। इसके अतिरिक्त, प्रक्रियाओं में USE FEDERATION का उपयोग आमतौर पर संभव नहीं है। महासंघों को बदलने के लिए कोड "एक स्तर ऊपर" होना चाहिए।

डेटाबेस निर्माण स्क्रिप्ट में किए जाने वाले परिवर्तन समाप्त हो गए हैं। हम इसे त्रुटियों के बिना निष्पादित कर सकते हैं। परिणामस्वरूप, एक रूट डेटाबेस (फेडरेशन रूट) और एक शार्क (फेडरेशन सदस्य) बनाया जाएगा।

टुकड़े में विभाजन

हमारे लिए यह सब करना वास्तव में स्केलिंग डेटाबेस का उत्पादन करना है। यानी एक खाते से संबंधित डेटा को दूसरे खाते के डेटा से अलग करना।

ऐसा करने के लिए, एक अलग स्क्रिप्ट बनाएं:
-- Scaling out the federation
USE FEDERATION ROOT WITH RESET
GO

ALTER FEDERATION Accounts SPLIT AT (AccountId = 2)
GO

पहली स्क्रिप्ट जो यह करती है वह फेडरेशन रूट का उपयोग करने के लिए स्विच है, अर्थात, यह xPenses डेटाबेस के भीतर काम करता है, क्योंकि फेडरेशन जानकारी (मेटाडेटा) वहां संग्रहीत होती है।

फिर हम संकेत करते हैं कि हम खाता नाम के साथ महासंघ को तोड़ना चाहते हैं, खाता 2 फ़ील्ड के मूल्य के बराबर से शुरू होता है। यानी, पहले खाते का डेटा पहले से ही बनाए गए हिस्से में रहता है, और अन्य खातों का डेटा अगले शार्क को स्थानांतरित कर दिया जाता है। कृपया यह भी ध्यान दें कि हम कहीं भी यह संकेत नहीं देते हैं कि डेटा खातों की तालिका में टूट गया है। हम केवल xPenses डेटाबेस मेटाडेटा के साथ काम करते हैं!



इसलिए, हम इस कमांड को निष्पादित करते हैं और ... यह काफी संभावना है कि जब आप ऑब्जेक्ट एक्सप्लोरर विंडो को रिफ्रेश करेंगे तो आपको निम्नलिखित दिखाई देंगे:



एक नए शार्क के बजाय, हमें मिला ... 3 के रूप में कई! वास्तव में, इसमें कुछ भी असामान्य नहीं है। बात यह है कि पहले शार्द के भीतर संग्रहीत डेटा को AccountId के मान के अनुसार कॉपी किया जाता है। यही है, 1 की आईडी के साथ एक खाते के लिए, आपको डेटा को एक शार्द पर कॉपी करने की आवश्यकता है, जिसमें 2 से दूसरे की आईडी है। स्वाभाविक रूप से, इसमें समय लगता है। SQL Azure डेटा को शार्क में पुनः वितरित करने के बाद, हम देखेंगे कि हमारे पास वास्तव में फेडरेशन मेटाडेटा और दो शार्क वाले डेटाबेस हैं।



अब, अगर हमें डेटा को 3 शार्क में विभाजित करने की आवश्यकता है, उदाहरण के लिए, खाता डेटा को 3 की आईडी के साथ एक अलग शार्क में स्थानांतरित करें, तो यह हमारे लिए निम्न कमांड निष्पादित करने के लिए पर्याप्त होगा:
ALTER FEDERATION Accounts SPLIT AT (AccountId = 3)
GO

निष्कर्ष

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