डेटा को भागों में विभाजित करने के लिए व्यावहारिक सुझाव। Azure Table Storage के लिए PartitionKey और RowKey उत्पन्न करना

सभी को नमस्कार। यहां "AtContent.com सेवा की आंतरिक संरचना और वास्तुकला" श्रृंखला का अंतिम लेख है। यहाँ Azure Table Storage और एक पूरे के रूप में प्लेटफ़ॉर्म के साथ हमारे अनुभव से सर्वोत्तम अभ्यास हैं। यह लेख विशिष्ट डेटा संरचनाओं के निर्माण के लिए एक प्रारंभिक बिंदु हो सकता है और विंडोज एज़्योर संसाधनों का बेहतर उपयोग करेगा।



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

यहां आपको एज़्योर स्टोरेज टेबल्स के लिए अभ्यास और उपयोग के मामले मिलेंगे।

सामान्य रूप से Azure Table Storage के बारे में

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

पहली बात यह है कि काम करते समय आपको ध्यान देना चाहिए कि तालिका से मूल्यों का चयन कैसे किया जाता है। कई विशेषताएं हैं:

• मान 1000 से अधिक नहीं के कुछ हिस्सों में चुने गए हैं;
• विभाजन कुंजी के बिना विभाजन (PartitionKey) बहुत धीमा है;
• जब कुंजी द्वारा मानों की एक सीमा चुनते हैं, तो स्थिति "कम से कम या बराबर" सही ढंग से चालू हो जाती है;

आपको हमेशा भागों में नमूने के बारे में याद रखना चाहिए, क्योंकि टेबल स्टोरेज किसी भी संख्या में रिकॉर्ड और एक निरंतर टोकन वापस कर सकता है। हालांकि सबसे अधिक बार ऐसा होता है जब 1000 से अधिक रिकॉर्ड होते हैं। एसडीके में एक तंत्र है जो आपको इसे स्वचालित रूप से संसाधित करने की अनुमति देता है, इसलिए आपको इसके बारे में बहुत चिंता नहीं करनी चाहिए। केवल यह याद रखना आवश्यक है कि प्रत्येक अनुरोध एक अतिरिक्त लेनदेन है। यदि आपके पास नमूने में 2001 का रिकॉर्ड है, तो रिपॉजिटरी में कम से कम 3 एक्सेस होंगे।

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



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



एक उदाहरण के रूप में, एक तालिका पर विचार करें जिसमें तारीख से कुंजी रोवे के साथ कई रिकॉर्ड हैं। और हमें 2 रिकॉर्ड का चयन करने की आवश्यकता है जिसके लिए RowKey 20120801221700 से कम है। हम उम्मीद करते हैं कि स्टोर "20120801221110" और "20120801201728" कुंजी के साथ रिकॉर्ड वापस करेगा। लेकिन सॉर्टिंग ऑर्डर के अनुसार, स्टोर "20120801171004" और "20120801181514" मान लौटाएगा।

आप एक उलटा कुंजी का उपयोग करके इसे दूर कर सकते हैं। तो, तारीख के मामले में, यह DateTime.MaxValue - CurrentDateTime है। फिर, जब नमूना लेते हैं, तो विपरीत स्थिति का उपयोग किया जाएगा और यह सही ढंग से काम करेगा।

विभाजन कुंजी चयन अभ्यास

एप्लिकेशन को डिज़ाइन करते समय, आपको उन अनुशंसाओं पर ध्यान देना चाहिए जो Microsoft संग्रहण तालिका ( http://msdn.microsoft.com/en-us/library/windowsazure/hh508997.aspx ) के संबंध में देता है। इन सिफारिशों का अर्थ बहुत सरल है। डिज़ाइन अनुप्रयोग ताकि बहुत अधिक न हों, और बहुत कम नहीं, विभाजन के लिए कुंजियाँ। और यह भी, ताकि प्रत्येक अनुभाग में बहुत अधिक प्रविष्टियां न हों। यह उचित है कि उन्हें समान रूप से वर्गों में वितरित किया जाए। यदि विभाजन पर लोड की भविष्यवाणी करना संभव है, तो अधिक लोड के साथ फिट होने वाले विभाजन को कम प्रविष्टियों से भरा जाना चाहिए। स्टोरेज टेबल्स आर्किटेक्चर के आधार पर, भारी लोड के तहत विभाजन स्वचालित रूप से दोहराया जाता है। और विभाजन का आकार जितना छोटा होगा, उतनी ही तेजी से प्रतिकृति होगी।

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

यह सरल कोड आपको एमडी 5 हैश से बिट्स की आवश्यक संख्या प्राप्त करने और अनुभाग संख्या के रूप में उपयोग करने की अनुमति देगा:

using System.Security.Cryptography; using System.Text; public static string GetHashMD5Binary(string Input, int BitCount = 128) { if (Input == null) return null; byte[] MD5Bytes = MD5.Create().ComputeHash( Encoding.Default.GetBytes(Input)); int Len = MD5Bytes.Length; string Result = ""; int HasBits = 0; for (int i = 0; i < Len; i++) { Result += Convert.ToString(MD5Bytes[i], 2).PadLeft(8, '0'); HasBits += 8; if (HasBits >= BitCount) break; } if (BitCount < 1 || BitCount >= 128) return Result; return Result.Substring(0, BitCount); } 

यह विधि, कई अन्य लोगों की तरह, CPlaseEngine के एक भाग के रूप में उपलब्ध है, एक लिंक जो लेख के अंत में पाया जा सकता है।

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

अभिलेखों के लिए चाबियाँ चुनने का अभ्यास

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

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

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

वितरण और सामान्यीकरण

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

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

मैं यह भी खुशी के साथ रिपोर्ट करना चाहता हूं कि हमारी ओपनसोर्स परियोजना CPlaseEngine कोडप्लेक्स पर खुली पहुंच में दिखाई दी है। इसमें ऐसे उपकरण हैं जो आपको विंडोज़ एज़्योर प्लेटफ़ॉर्म पर अधिक कुशलता से सेवाएं विकसित करने की अनुमति देंगे। आप इसे https://cplaseengine.codeplex.com/ पर डाउनलोड कर सकते हैं।

श्रृंखला में पढ़ें:

• “ AtContent.com आंतरिक संरचना और वास्तुकला ”,
• " भूमिकाओं और उदाहरणों के बीच संदेशों के आदान-प्रदान के लिए एक तंत्र ",
• " एक उदाहरण पर कैशिंग डेटा और कैशिंग प्रबंधन ",
• कुशल क्लाउड कतार (एज़्यू कतार) ,
• " अज़ुरे टेबल स्टोरेज के लिए LINQ एक्सटेंशन जो संचालन को लागू या नियंत्रित करता है ।"