जंगली में मौजूद कई अन्य दस्तावेज़ों को फिर से हैश करने के बजाय, मैं रेडिस + सर्विसस्टैक के रेडिस क्लाइंट के आसपास कुछ पृष्ठभूमि जानकारी के लिए एक जोड़े को सूचीबद्ध करूंगा:
- नोएसक्यूएल रेडिस एप्लिकेशन को डिजाइन करते समय क्या सोचना चाहिए
- Redis का उपयोग करके NoSQL डेटाबेस डिज़ाइन करना
- Redis और .NET का सामान्य अवलोकन
- सी # रेडिस क्लाइंट के साथ योजनाबद्ध संस्करण और डेटा माइग्रेशन
कोई जादू नहीं है - रेडिस एक खाली कैनवास है
सबसे पहले मैं यह बताना चाहता हूं कि डेटा स्टोर के रूप में रेडिस का उपयोग केवल एक खाली कैनवास प्रदान करता है और इसमें संबंधित संस्थाओं की कोई अवधारणा नहीं होती है। यानी यह सिर्फ वितरित COMP-Sci डेटा संरचनाओं तक पहुंच प्रदान करता है। रेडिस के आदिम डेटा संरचना संचालन का उपयोग करके रिश्तों को कैसे संग्रहीत किया जाता है, यह अंततः क्लाइंट ड्राइवर (यानी सर्विसस्टैक सी # रेडिस क्लाइंट) या ऐप डेवलपर पर निर्भर करता है। चूंकि सभी प्रमुख डेटा संरचनाएं रेडिस में कार्यान्वित की जाती हैं, इसलिए आपको मूल रूप से इस बात की पूरी स्वतंत्रता है कि आप अपने डेटा को कैसे संरचित और संग्रहीत करना चाहते हैं।
सोचें कि आप कोड में संबंधों की संरचना कैसे करेंगे
तो रेडिस में सामान स्टोर करने के तरीके के बारे में सोचने का सबसे अच्छा तरीका यह है कि आरडीबीएमएस तालिका में डेटा कैसे संग्रहीत किया जाता है और इस बारे में सोचें कि यह आपके कोड में कैसे संग्रहीत किया जाता है, यानी स्मृति में अंतर्निहित सी # संग्रह कक्षाओं का उपयोग करना - जो Redis अपने सर्वर-साइड डेटा-संरचनाओं के साथ व्यवहार में प्रतिबिम्बित करता है।
संबंधित संस्थाओं की अवधारणा न होने के बावजूद, Redis का अंतर्निहित सेट और सॉर्टेडसेट डेटा संरचनाएं इंडेक्स को स्टोर करने का आदर्श तरीका प्रदान करती हैं। उदा. रेडिस का सेट संग्रह केवल एक तत्व की अधिकतम 1 घटना को संग्रहीत करता है। इसका मतलब है कि आप इसमें सुरक्षित रूप से आइटम/कुंजी/आईडी जोड़ सकते हैं और परवाह नहीं है कि आइटम पहले से मौजूद है क्योंकि अंतिम परिणाम वही होगा जिसे आपने इसे 1 या 100 बार बुलाया था - यानी यह बेकार है, और आखिरकार केवल 1 तत्व संग्रहीत रहता है सेट। तो एक सामान्य उपयोग-मामला तब होता है जब ऑब्जेक्ट ग्राफ़ (कुल रूट) को संग्रहीत करते समय चाइल्ड एंटिटी आईडी (उर्फ विदेशी कुंजी) को हर बार मॉडल को सहेजते समय एक सेट में संग्रहीत करना होता है।
अपना डेटा विज़ुअलाइज़ करना
रेडिस में संस्थाओं को कैसे संग्रहीत किया जाता है, इसके एक अच्छे दृश्य के लिए मैं रेडिस एडमिन यूआई स्थापित करने की सलाह देता हूं जो सर्विसस्टैक के सी # रेडिस क्लाइंट के साथ अच्छी तरह से काम करता है क्योंकि यह एक अच्छा पदानुक्रमित दृश्य प्रदान करने के लिए नीचे दिए गए कुंजी नामकरण सम्मेलन का उपयोग करता है, आपकी टाइप की गई इकाइयों को एक साथ समूहित करता है (सभी चाबियों के बावजूद) एक ही वैश्विक कीस्पेस में विद्यमान)।
किसी निकाय को देखने और संपादित करने के लिए, संपादित करें . पर क्लिक करें चयनित इकाई के आंतरिक JSON प्रतिनिधित्व को देखने और संशोधित करने के लिए लिंक। उम्मीद है कि एक बार जब आप देख लेंगे कि वे कैसे संग्रहीत हैं, तो आप अपने मॉडल को डिज़ाइन करने के तरीके के बारे में बेहतर निर्णय लेने में सक्षम होंगे।
POCO / संस्थाओं को कैसे संग्रहीत किया जाता है
सी # रेडिस क्लाइंट किसी भी पीओसीओ के साथ काम करता है जिसमें एक ही प्राथमिक कुंजी होती है - जो डिफ़ॉल्ट रूप से Id होने की उम्मीद है (हालांकि यह कन्वेंशन मॉडलकॉन्फिग के साथ ओवरराइड करने योग्य है)। अनिवार्य रूप से पीओसीओ को रेडिस में क्रमबद्ध JSON के रूप में typeof(Poco).Name दोनों के साथ संग्रहीत किया जाता है। और Id उस उदाहरण के लिए एक अद्वितीय कुंजी बनाने के लिए उपयोग किया जाता है। उदा:
urn:Poco:{Id} => '{"Id":1,"Foo":"Bar"}'
सी # क्लाइंट में पीओसीओ पारंपरिक रूप से सर्विसस्टैक के तेज़ जेसन सीरियलाइज़र का उपयोग करके क्रमबद्ध होते हैं जहां केवल सार्वजनिक गेटर्स वाले गुणों को क्रमबद्ध किया जाता है (और सार्वजनिक सेटर्स को डी-सीरियलाइज्ड वापस पाने के लिए)।
डिफ़ॉल्ट [DataMember] . के साथ ओवरराइड करने योग्य हैं attrs लेकिन अनुशंसित नहीं है क्योंकि यह आपके POCO को बदनाम करता है।
इकाइयां ब्लॉब की गई हैं
इसलिए यह जानते हुए कि रेडिस में पीओसीओ सिर्फ ब्लॉब किए गए हैं, आप केवल अपने पीओसीओ पर सार्वजनिक संपत्तियों के रूप में गैर-कुल रूट डेटा रखना चाहते हैं (जब तक कि आप जानबूझकर अनावश्यक डेटा स्टोर नहीं करना चाहते)। संबंधित डेटा प्राप्त करने के लिए विधियों का उपयोग करना एक अच्छा सम्मेलन है (क्योंकि यह क्रमबद्ध नहीं होगा), लेकिन यह आपके ऐप को यह भी बताता है कि डेटा पढ़ने के लिए कौन से तरीके दूरस्थ कॉल करते हैं।
तो सवाल यह है कि क्या फ़ीड उपयोगकर्ता . के साथ संगृहीत होना चाहिए क्या यह गैर-समग्र रूट डेटा है या नहीं, यानी आप उपयोगकर्ता के संदर्भ के बाहर उपयोगकर्ता फ़ीड तक पहुंच बनाना चाहते हैं या नहीं? यदि नहीं, तो List<Feed> Feeds छोड़ दें User . पर संपत्ति टाइप करें।
कस्टम अनुक्रमणिका बनाए रखना
यदि फिर भी आप सभी फ़ीड को स्वतंत्र रूप से एक्सेस करने योग्य रखना चाहते हैं, अर्थात redisFeeds.GetById(1) के साथ तो आप इसे उपयोगकर्ता के बाहर स्टोर करना चाहेंगे और 2 इकाइयों को जोड़ने वाली अनुक्रमणिका बनाए रखेंगे।
जैसा कि आपने देखा है कि संस्थाओं के बीच संबंधों को संग्रहीत करने के कई तरीके हैं और आप इसे कैसे करते हैं यह काफी हद तक वरीयता का मामला है। अभिभावक>बच्चे . में चाइल्ड इकाई के लिए संबंध आप हमेशा ParentId . को संगृहीत करना चाहेंगे बच्चे इकाई के साथ। अभिभावक के लिए आप या तो ChildIds . का संग्रह संग्रहित करना चुन सकते हैं मॉडल के साथ और फिर मॉडल को फिर से हाइड्रेट करने के लिए सभी बाल संस्थाओं के लिए एक ही फ़ेच करें।
दूसरा तरीका यह है कि इंडेक्स को पैरेंट डीटीओ के बाहर अपने सेट . में बनाए रखा जाए प्रत्येक अभिभावक उदाहरण के लिए। इसके कुछ अच्छे उदाहरण Redis StackOverflow डेमो के C# स्रोत कोड में हैं जहाँ Users > Questions का संबंध है और Users > Answers में संग्रहीत है:
idx:user>q:{UserId} => [{QuestionId1},{QuestionId2},etc]
idx:user>a:{UserId} => [{AnswerId1},{AnswerId2},etc]
हालांकि C# RedisClient में अपने TParent.StoreRelatedEntities(), TParent.GetRelatedEntities<TChild>() के माध्यम से एक डिफ़ॉल्ट अभिभावक/बाल सम्मेलन के लिए समर्थन शामिल है। और TParent.DeleteRelatedEntities() एपीआई जहां एक इंडेक्स को उस दृश्य के पीछे रखा जाता है जो इस तरह दिखता है:
ref:Question/Answer:{QuestionId} => [{answerIds},..]
प्रभावी रूप से ये आपके कुछ संभावित विकल्प हैं, जहां एक ही लक्ष्य को प्राप्त करने के कई अलग-अलग तरीके हैं और जिसमें आपको अपना खुद का रोल करने की स्वतंत्रता भी है।
नोएसक्यूएल की स्कीमा-रहित, ढीली-टाइपिंग स्वतंत्रताओं को अपनाया जाना चाहिए और आपको एक कठोर, पूर्व-निर्धारित संरचना का पालन करने की कोशिश करने के बारे में चिंतित नहीं होना चाहिए जिससे आप आरडीबीएमएस का उपयोग करते समय परिचित हो सकते हैं।
अंत में, कोई वास्तविक सही तरीका नहीं है रेडिस में डेटा स्टोर करने के लिए, उदा। सी # रेडिस क्लाइंट पीओसीओ के आसपास एक उच्च स्तरीय एपीआई प्रदान करने के लिए कुछ धारणाएं बनाता है और यह रेडिस के बाइनरी-सुरक्षित स्ट्रिंग मानों में पीओसीओ को ब्लॉब करता है - हालांकि अन्य क्लाइंट रेडिस हैश (शब्दकोश) में एक इकाई गुणों को स्टोर करना पसंद करेंगे। . दोनों काम करेंगे।
