रेडिस दुनिया में आम तौर पर स्वीकृत सम्मेलन विकल्प 1 है - यानी कॉलन जैसे चरित्र से अलग नामस्थान। उस ने कहा, नामस्थान लगभग हमेशा एक स्तर गहरे हैं। उदाहरण के लिए: के बजाय person:12321।
यह आपके द्वारा निर्धारित 4 दिशानिर्देशों के साथ कैसे काम करता है?
शार्डेबल - यह दृष्टिकोण shardable है। आप इसे कैसे सेट अप करते हैं, इस पर निर्भर करते हुए प्रत्येक कुंजी एक अलग शार्ड या एक ही शार्ड में जा सकती है।
नामांकित इस दृष्टिकोण के साथ टकराव से बचने के लिए नामस्थान के रूप में नामस्थान। हालांकि, समूह कुंजी के लिए नाम के रूप में नामस्थान काम नहीं करते हैं। आम तौर पर, समूह डेटा के तरीके के रूप में कुंजी का उपयोग करना एक बुरा विचार है। उदाहरण के लिए, क्या होगा यदि व्यक्ति विभाग से दूसरे स्थान पर जाता है? यदि आप कुंजी बदलते हैं, तो आपको सभी संदर्भों को अपडेट करना होगा - और यह मुश्किल हो जाता है।
यह सुनिश्चित करने के लिए सबसे अच्छा है कि कुंजी किसी वस्तु के लिए कभी भी परिवर्तित न हो।ग्रुपिंग को अलग इंडेक्स बनाकर बाहरी रूप से संभाला जा सकता है।
उदाहरण के लिए, मान लीजिए कि आप लोगों द्वारा विभाग द्वारा वेतन श्रेणी के अनुसार, समूह द्वारा समूह बनाना चाहते हैं। यहाँ कैसे आप यह कर होता है -
- व्यक्तिगत लोगों चाबियाँ
persons:12321
- साथ अलग हैश में जाना द्वारा प्रत्येक समूह के लिए एक
set बनाएँ - उदाहरण के लिए: persons_by:department - और केवल इस में प्रत्येक व्यक्ति के लिए संख्यात्मक पहचानकर्ता स्टोर सेट। उदाहरण के लिए [12321, 43432]। इस तरह, आप Redis 'पूर्णांक सेट के फायदे मिल
कुशल विधि ऊपर बताया गया है बहुत कुशल स्मृति बुद्धिमान है। कुछ और मेमोरी को बचाने के लिए, आप एप्लिकेशन की तरफ आगे की चाबियों को संपीड़ित कर सकते हैं। उदाहरण के लिए, आप persons:12321 के बजाय p:12321 स्टोर कर सकते हैं। आपको यह केवल तभी करना चाहिए यदि आपने प्रोफाइलिंग के माध्यम से निर्धारित किया है कि आपको ऐसी स्मृति बचत की आवश्यकता है। आम तौर पर, यह लागत के लायक नहीं है।
टकराव मुक्त यह आपके आवेदन पर निर्भर करता है। प्रत्येक उपयोगकर्ता या व्यक्ति के पास प्राथमिक कुंजी होनी चाहिए जो कभी नहीं बदले। इसे अपनी रेडिस कुंजी में प्रयोग करें, और आपके पास टकराव नहीं होगा।
आप इस दृष्टिकोण के साथ दो समस्याओं उल्लेख किया है, और मैं उन्हें
आईडी एक कॉलन है क्या होगा अगर पता करने के लिए कोशिश करेंगे?
यह निश्चित रूप से संभव है, लेकिन आपके एप्लिकेशन के डिज़ाइन को इसे रोकना चाहिए। इसका सबसे अच्छा पहचानकर्ताओं में विशेष पात्रों को अनुमति नहीं देना है - क्योंकि वे कई प्रणालियों में उपयोग किए जाएंगे। उदाहरण के लिए, पहचानकर्ता यूआरएल का हिस्सा होगा, और कॉलन यूआरएल के लिए भी एक आरक्षित चरित्र है।
यदि आपको वास्तव में अपने पहचानकर्ता में विशेष वर्णों की अनुमति देनी है, तो आपको विशेष कोड को एन्कोड करने वाले आपके कोड में एक छोटा रैपर लिखना होगा। यूआरएल एन्कोडिंग इसे संभालने में पूरी तरह से सक्षम है।
आकार क्षमता
नहीं है लंबे चाबियाँ करने के लिए एक लागत, लेकिन यह बहुत ज्यादा नहीं है। आम तौर पर, आपको चाबियों के बजाए अपने मूल्यों के डेटा आकार के बारे में चिंता करनी चाहिए। यदि आपको लगता है कि चाबियाँ बहुत अधिक मेमोरी का उपभोग कर रही हैं, तो redis-rdb-tools जैसे टूल का उपयोग करके डेटाबेस को प्रोफाइल करें।
यदि आप यह निर्धारित करते हैं कि कुंजी आकार एक समस्या है और स्मृति को सहेजना चाहते हैं, तो आप एक छोटे से रैपर को लिख सकते हैं जो कि उपनाम का उपयोग करके कुंजी को फिर से लिखता है।
अद्भुत जवाब। समय लेने और इस मुद्दे को संबोधित करने के लिए बहुत बहुत धन्यवाद। मैं आपके लिए पहले "बाउंटी" बटन पर क्लिक न करने के लिए क्षमा चाहता हूं, लेकिन यह पहली बार मैंने इसका इस्तेमाल किया है। धन्यवाद! –