💋 👩🏿‍💻 👨🏽‍🎓 आप डेटा कहाँ संग्रहीत करते हैं? 🔹 🎏 🧖🏾

नमस्कार, हेब्र! हम लेखों की हमारी प्रयोगात्मक श्रृंखला जारी रखते हैं, जिसका अवलोकन करके आप वास्तविक समय में UWP पर गेम बनाने की प्रक्रिया को प्रभावित कर सकते हैं। आज हम इस सवाल के बारे में बात करेंगे कि "डेटा कहां स्टोर करें?" जो लगातार डेवलपर्स के रैंक में पैदा होता है। हमसे जुड़ें और टिप्पणियों में अपने विचार साझा करें!

मैं लेखक अलेक्सी प्लॉटनिकोव को मंजिल देता हूं।

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

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

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

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

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

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

हालाँकि, मैं ध्यान देता हूं कि कंपनी Android या iOS के लिए डेवलपर्स के लिए Azure के उपयोग को आकर्षक बनाने के लिए हर संभव प्रयास करती है। खैर, अंतिम उल्लेख किया गया है, लेकिन कम से कम नहीं, मुद्दा क्लाउड का उपयोग करने की लागत है। चूंकि मैं बिज़स्पार्क सदस्यता का धारक हूं, इसलिए मुझे अपनी क्लाउड जरूरतों को कवर करने से अधिक ब्याज के साथ एक बैग के लिए एक मासिक ऋण प्रदान किया गया है, हालांकि मुफ्त आधार पर प्रदान की जाने वाली शर्तें भी एक निजी डेवलपर की अधिकांश जरूरतों को कवर कर सकती हैं।

अब एक सिंक्रोनाइज़ेशन और डेटा स्टोरेज मैकेनिज्म के सीधे चयन पर चलते हैं। मैं चालाक नहीं होने जा रहा हूं, एक स्वयं-सिखाया व्यक्ति के रूप में मुझे अक्सर उन प्रौद्योगिकियों से निपटना पड़ता है जिनके बारे में मुझे कोई पता नहीं है इससे पहले कि मुझे UWP पता चले, मैंने SQL डेटाबेस का उपयोग करके इसी तरह की समस्याओं को हल किया।

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

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

अंतर्ज्ञान से पता चलता है कि यह वही है जो आपको चाहिए, इसलिए मैंने इस मुद्दे के गहन अध्ययन पर ध्यान केंद्रित करने का निर्णय लिया, ताकि परियोजना में आगे उपयोग किया जा सके।

क्लाउड स्टोरेज अलग-अलग कार्यों के लिए कई उत्पादों का एक सेट है, जिसके बारे में यहां और अधिक पढ़ा जा सकता है , लेकिन मुझे मुख्य रूप से टेबल स्टोरेज में दिलचस्पी थी, जो कि NoSQL डेटाबेस निकला।

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

शुरू करने के लिए, आइए जानें कि NoSQL तालिका कैसे बनाएं:

1. एक नि: शुल्क एज़्योर खाता पंजीकृत करें । यदि आपके पास MSDN या BizSpark सदस्यता है और यह पहले से ही Azure में सक्रिय है, तो आप इस चरण को छोड़ सकते हैं। एक मुफ्त खाता आपको पहले महीने के लिए $ 200 का ऋण देता है और फिर अधिकांश Azure सेवाओं के संसाधनों की एक निश्चित राशि तक मुफ्त पहुंच प्रदान करता है। एक समझने योग्य भाषा में अनुवादित, सब कुछ इस तरह से किया जाता है कि आपको तब तक भुगतान नहीं करना होगा जब तक कि आपका उत्पाद खर्चों को कवर करने के लिए पर्याप्त नहीं कमाता है, न कि स्व-शिक्षा के लिए एज़्योर के उपयोग का उल्लेख करने के लिए।

लेकिन भले ही आप फ्री थ्रेसहोल्ड को पार करते हैं, लेकिन एक समान स्टोरेज के लिए SQL डेटाबेस की तुलना में टेबल स्टोरेज के लिए कीमतें बहुत अधिक वफादार होती हैं। उदाहरण के लिए, इस लेख को लिखने के समय, मैंने दो तालिकाओं का निर्माण किया है, अब तक केवल एक प्रविष्टि के साथ। रिपोर्टिंग अवधि के 18 दिनों के लिए, मैंने उसे दिन में औसतन 20-30 बार घुमाया और इस अवधि के लिए क्रेडिट खाते से 2 कोपेक लिखे गए। नियोजित मात्रा के लिए इस तरह की लागतों को स्केल करना, मुझे एहसास हुआ कि वे आवेदन से संभावित आय द्वारा कवर से अधिक हैं।

2. अब आपका Azure में खाता है, हम एक संग्रहण खाता बनाने के लिए आगे बढ़ते हैं।

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

नई विंडो में, आपको निम्न चरण करने होंगे:

आरंभ करने के लिए, आपको अपने Microsoft खाते से लॉग इन करना होगा। आपको उस खाते का उपयोग करने की आवश्यकता है जो आपकी सदस्यताएँ एक स्वतंत्र Azure खाते से जुड़ी हुई हैं।
आपके खाते में लॉग इन करने के बाद, आपकी सदस्यता (ए) "सदस्यता" फ़ील्ड में दिखाई देगी। पसंद के साथ सब कुछ सरल है, इसलिए टिप्पणियां शानदार हैं।
"नाम" फ़ील्ड में, भंडारण सेवा का वांछित नाम निर्दिष्ट करें। चूंकि यह सेवा का डोमेन नाम भी है, इसलिए यह Azure में उपलब्ध सभी खातों के भीतर अद्वितीय होना चाहिए, न कि केवल आपके स्वयं के भीतर।
"मूल्य श्रेणी" फ़ील्ड के लिए आपको क्लाउड प्लेटफ़ॉर्म और पारंपरिक होस्टिंग के बीच के अंतर को समझने की आवश्यकता होगी, क्योंकि फ़ील्ड के तहत लिंक पर क्लिक करके आप कीमतों की एक सूची देख सकते हैं, लेकिन एक समझदार स्पष्टीकरण नहीं है, जो आपको प्रत्येक विकल्प देता है। बेशक, साइटलिंक के विकलों में आप जीआरएस और एलआरएस जैसे इन सभी संक्षिप्ताक्षरों के बारे में व्यापक जानकारी पा सकते हैं, लेकिन यह औसत डेवलपर के लिए बहुत ही बढ़िया है। यह समझने के लिए पर्याप्त है कि टैरिफ जितना अधिक महंगा होगा, उतना ही अधिक डेटा सेंटर आपके डेटा के प्रसंस्करण और भंडारण में शामिल होगा और उनकी सुरक्षा की संभावना अधिक होगी। एक छोटी परियोजना के लिए, सबसे कम LRS दर ठीक है।
एक "संसाधन समूह" एकल प्रबंधन के लिए कई एज़्योर सेवाओं का एक संयोजन है। हमारे मामले में, एक नया बनाएं, किसी भी अनुकूल नाम को निर्दिष्ट करें और आगे बढ़ें।
आपकी सेवा के लिए अंतिम स्थान "स्थान" है। स्थान के आधार पर डेटा केंद्रों का वास्तविक स्थान होता है जो हमारे डेटा के साथ काम करने के लिए जिम्मेदार होगा। कृपया ध्यान दें कि मैं बहुवचन में बोलता हूं, जैसा कि एक क्षेत्र में कई डेटा केंद्र हो सकते हैं और उनके बीच काम वितरित किया जा सकता है (यदि आप एक सलाह मूल्य श्रेणी चुनते हैं)। वह चुनें जो आपके प्राथमिक उपयोगकर्ता आधार के सबसे करीब है। हालाँकि, यदि आप पूरी दुनिया के पैमाने पर बढ़ने की योजना बना रहे हैं और आपको दुनिया में कहीं भी अधिकतम प्रतिक्रिया की आवश्यकता है, तो कोई भी आपको एक अलग स्टोरेज अकाउंट बनाने और उनके बीच डेटा सिंक्रोनाइज़ेशन को लागू करने के लिए आवेदन के प्रत्येक क्षेत्रीय संस्करण के लिए परेशान नहीं करता है। यह उच्च स्तर की व्यापकता है जो बादल का मुख्य लाभ है।

3. भंडारण खाता बनाने के बाद, इसे सूची में जोड़ा जाएगा और आप "ऐड" बटन पर क्लिक करके जारी रख सकते हैं। इस कार्रवाई का परिणाम परियोजना में एज़्योर के साथ काम करने और प्रोजेक्ट के ऐप.कॉन्फ़िग फ़ाइल में कनेक्शन स्ट्रिंग को सहेजने के लिए एक NuGet पैकेज जोड़ना होगा।

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

4. अब यह एक टेबल बनाने और इसके साथ काम करना शुरू करने के लिए बना हुआ है। और यहां व्यक्तिगत कार्य शुरू होता है, सीधे कार्यों पर निर्भर करता है।

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

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

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

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

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

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

इसलिए, जब आपने डेटा संग्रहण संरचना का पता लगाया, तो अंत में एक नई तालिका जोड़ें। चूंकि हमने इसे कोड स्तर पर बनाने से इनकार कर दिया था, इसलिए दो विकल्प शेष हैं: Azure वेब पोर्टल के माध्यम से या विशेष Microsoft Azure संग्रहण एक्सप्लोरर उपकरण का उपयोग करके, जिसे Storageexplorer.com से डाउनलोड किया जा सकता है। दोनों ही मामलों में, वांछित भंडारण खाते का चयन करना आवश्यक है और "टेबल्स / टेबल्स सर्विस" सेक्शन में "+ टेबल / टेबल" का चयन करें। दिखाई देने वाले संवाद में, वांछित नाम दर्ज करें और परिवर्तन करें।

उसके बाद, आप बिना किसी समस्या के कोड से नई तालिका के साथ काम कर सकते हैं।

मुख्य कार्य जो मैं तालिका के साथ करूंगा, वे पंक्तियों का सम्मिलन और निष्कर्षण हैं, जिन्हें तालिका संग्रहण शब्दावली में "निकाय" कहा जाता है। इस तरह के एक शब्द को समझना आसान है, जब आपको पता चलता है कि एक इकाई को सम्मिलित करने और पुनः प्राप्त करने के लिए, आपको इसे Microsoft.WindowsAzure.Storage.Table से TableEntity से विरासत में मिली कक्षा को मैप करने की आवश्यकता होगी। उत्तराधिकारी वर्ग में पहले से ही कुछ आवश्यक फ़ील्ड शामिल होंगे, जैसे, उदाहरण के लिए, PartitionKey (अनुभाग नाम) और RowKey (लाइन नाम), और उन फ़ील्ड जिन्हें हम स्वतंत्र रूप से कार्यान्वित करते हैं, वे पंक्ति (इकाई गुण) में कॉलम होंगे।

एक तालिका के उदाहरण पर विचार करें जिसमें उनके नाम, अवतार और देश की संबद्धता वाले सभी खिलाड़ियों की एक सूची संग्रहीत की जाएगी।

    : Imports Microsoft.WindowsAzure.Storage Imports Microsoft.WindowsAzure.Storage.Table

मैंने आवेदन के विभिन्न बिंदुओं से काम करने की सुविधा के लिए तालिका के साथ काम करने के तरीकों को एक अलग वर्ग में रखने का फैसला किया। इसे बनाएं और पहले से ज्ञात स्थिरांक को तुरंत जोड़ें:

 Public Class AzureWorker Private Const AzureStorageConnectionString As String = "  ,     app.config" Private Const GamerListTableNameString As String = "GamerList" '    … End Class

अब हमें एक वर्ग बनाने की आवश्यकता है जिसे हम तालिका के अंदर इकाई (पंक्ति) में मैप करेंगे:

  Private Class GamerListClodTableDataClass Inherits TableEntity Public Const RowKeyValue As String = "UserID" Public Sub New () RowKey = RowKeyValue End Sub Public Property UserName As String = "" Public Property UserountryID As String = "" Public Property UserAvatar As String = "" End Class

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

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

तालिका में प्रत्यक्ष प्रश्नों से पहले अंतिम तैयारी चरण एक अलग कार्य में अपनी वस्तु का निर्माण है:

  Private Shared Function GetCloudTable(tableName As String) As CloudTable Dim storageAccount As CloudStorageAccount = CloudStorageAccount.Parse(AzureStorageConnectionString) Dim tableClient As CloudTableClient = storageAccount.CreateCloudTableClient() Dim table As CloudTable = tableClient.GetTableReference(tableName) Return table End Function

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

अंत में, चलिए सीधे टेबल के साथ काम करते हैं और वर्तमान उपयोगकर्ता डेटा को सहेजकर शुरू करते हैं:

  Public Shared Async Function SavedOrUpdateUserData(u As UserManager) As Task(Of Boolean) Dim table As CloudTable = GetCloudTable(GamerListTableNameString) Try If Await table.ExistsAsync Then Dim UserDataClodTableData As New GamerListClodTableDataClass With {.PartitionKey = u.UserId, .UserName = u.UserName.Trim, .UserountryID = u.UserountryID, .UserAvatar = "https://apis.live.net/v5.0/" & u.UserId & "/picture"} Dim insertOperation As TableOperation = TableOperation.InsertOrReplace(UserDataClodTableData) Await table.ExecuteAsync(insertOperation) Return True End If Catch ex As Exception End Try Return False End Function

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

तालिका के प्रश्नों के लिए, पहले आपको रिपॉजिटरी और टेबल नाम से कनेक्शन स्ट्रिंग का उपयोग करके इसकी ऑब्जेक्ट बनाने की आवश्यकता है (हमने इस प्रक्रिया को पहले एक अलग फ़ंक्शन में डाल दिया है)। अगला, आपको तालिका के अस्तित्व की जांच करनी चाहिए और, हालांकि हमें यकीन है कि हमारे पास उस नाम के साथ एक तालिका है, एक त्रुटि हो सकती है, उदाहरण के लिए, नेटवर्क कनेक्टिविटी की कमी के कारण या क्लाउड में विफलता के कारण (इसीलिए इस कोड को Try / में रखा गया है) कैच)। फिर, तालिका में लिखने से पहले, आपको UserDataClodTableData वर्ग का एक उदाहरण बनाने और इसके क्षेत्रों को आवश्यक मान निर्दिष्ट करने की आवश्यकता है और उसके बाद ही InsertOrReplace ऑपरेशन बनाएं। जैसा कि आप ऑपरेशन के नाम से अनुमान लगा सकते हैं, यह तालिका में एक नई पंक्ति सम्मिलित करेगा यदि विभाजन और रॉकी की समान जोड़ी वाली पंक्तियाँ तालिका में मौजूद नहीं हैं और यदि ऐसी पंक्ति पहले से मौजूद है तो डेटा को प्रतिस्थापित करें। खैर, अंतिम ExecuteAsync टीम, वास्तव में, टेबल भंडारण पक्ष पर नियोजित कार्रवाई करेगी।

तालिका से डेटा पढ़ना उतना ही आसान है जितना कि इसे लिखना। उदाहरण के लिए, उपयोगकर्ता नाम का अनुरोध करें:

  Public Shared Async Function GetUserName(id As String) As Task(Of String) Dim table As CloudTable = GetCloudTable(GamerListTableNameString) Try If Await table.ExistsAsync Then Dim retrieveOperation As TableOperation = TableOperation.Retrieve(Of GamerListClodTableDataClass)(id, GamerListClodTableDataClass.RowKeyValue) Dim retrievedResult As TableResult = Await table.ExecuteAsync(retrieveOperation) If retrievedResult.Result IsNot Nothing Then Return CType(retrievedResult.Result, GamerListClodTableDataClass).UserName End If End If Catch ex As Exception End Try Return "" End Function

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

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

उपरोक्त उदाहरण क्वेरी की गति के दृष्टिकोण से सबसे इष्टतम है, क्योंकि एड्रेसिंग सिस्टम को संभवतः पथ "स्टोरेज नेम" टेबल नेम + पार्टिशनके + राउके + के साथ एक इकाई मिल जाएगी, हालांकि, केवल एक नाम प्राप्त करने के लिए, हम पूरी इकाई को एक पूरे के रूप में लोड करते हैं, जो लाभकारी नहीं है। हस्तांतरित डेटा की मात्रा पर।

निम्नलिखित अधिकतम क्वेरी अनुकूलन को ध्यान में रखते हुए एक संशोधित फ़ंक्शन कोड है:

  Public Shared Async Function GetUserName(id As String) As Task(Of String) Dim table As CloudTable = GetCloudTable(GamerListTableNameString) Try If Await table.ExistsAsync Then Dim projectionQuery As TableQuery(Of DynamicTableEntity) = New TableQuery(Of DynamicTableEntity)().Where(TableQuery.CombineFilters(TableQuery.GenerateFilterCondition("PartitionKey", QueryComparisons.Equal, id), "and", TableQuery.GenerateFilterCondition("RowKey", QueryComparisons.Equal, GamerListClodTableDataClass.RowKeyValue))).Select({"UserName"}) Dim resolver As EntityResolver(Of String) = Function(pk, rk, ts, props, etag) Return props("UserName").StringValue End Function Dim result As TableQuerySegment(Of String) = Await table.ExecuteQuerySegmentedAsync(projectionQuery, resolver, Nothing) If result.Count > 0 Then Return result(0) End If End If Catch ex As Exception End Try Return "" End Function

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

इस तरह की क्वेरी के साथ, किसी भी वर्ग के साथ परिणाम की तुलना करने का कोई मतलब नहीं है, इसलिए, IDEDIA का उपयोग वापसी मूल्य के रूप में किया जाता है, जहां कुंजी कॉलम का नाम है, और मूल्य इसकी सामग्री है। चूंकि कार्य ExecuteQuerySegmentedAsync को पता नहीं है कि इसके निष्पादन का क्या परिणाम प्राप्त होगा, यह EntityResolver प्रतिनिधि को पारित करने के लिए संभव है (और इस मामले में आवश्यक है), जो एक फ़ंक्शन को संदर्भित करता है जो शब्दकोश से वांछित मूल्य लेता है। इन सबका परिणाम तालिका सूचकांक में बनता है, जिसमें पहले अनुरोधित उपयोगकर्ता का नाम संग्रहीत होता है।

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

महत्वपूर्ण! लिंक लेख क्लासिक .NET अनुप्रयोगों के लिए कोड का उपयोग करते हैं और UWP कार्यान्वयन से अलग होते हैं। सौभाग्य से, यह अंतर महत्वपूर्ण नहीं है और एनालॉग्स सहज हैं (ज्यादातर अक्सर अंतर Async उपसर्ग में होते हैं)।

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

इसके अलावा, भविष्य में, उपयोगकर्ताओं की सूची वाली एक तालिका खेल में सामाजिक कार्यों में प्रवेश करने के लिए काम आएगी और, अब, मैं इस डेटा के लिए कम से कम एक आवेदन के साथ आया हूं। इस कार्य के कार्यान्वयन में, Azure टूल जैसे Queue Storage और Azure Functions मुझे फिर से मदद करेंगे, लेकिन मैं निम्नलिखित लेखों में से एक में इस बारे में बात करूंगा।

आप डेटा कहाँ संग्रहीत करते हैं?

More articles: