2011-03-18 18 views
8

मैं कुछ नमूना परियोजनाओं पर काम करने के लिए मोंगोडीबी, सी # और NoRM का उपयोग करने की कोशिश कर रहा हूं, लेकिन इस बिंदु पर मुझे डेटा मॉडल के चारों ओर अपने सिर को लपेटने में काफी कठिन समय है। आरडीबीएमएस के संबंधित डेटा के साथ कोई समस्या नहीं है। हालांकि, मोंगोडीबी में, मुझे यह तय करने में मुश्किल हो रही है कि उनके साथ क्या किया जाए।मोंगो डीबी, सी # और नोआरएम + डेनोर्मलाइजेशन

चलिए एक उदाहरण के रूप में StackOverflow का उपयोग करते हैं ... मुझे कोई समस्या नहीं है कि एक प्रश्न पृष्ठ पर अधिकांश डेटा को एक दस्तावेज़ में शामिल किया जाना चाहिए। शीर्षक, प्रश्न पाठ, संशोधन, टिप्पणियां ... सभी एक दस्तावेज़ ऑब्जेक्ट में अच्छा है।

मैं कहां से धुंधला पाने के लिए शुरू उपयोगकर्ता डेटा उपयोगकर्ता नाम, अवतार, प्रतिष्ठा (जो विशेष रूप से अक्सर बदल जाती) की तरह के सवाल पर है ... आप denormalize और दस्तावेज़ के हजारों को अद्यतन करते हैं कि हर बार जब कोई उपयोगकर्ता बदलाव नहीं आया है रिकॉर्ड या आप किसी भी तरह से डेटा को एक साथ जोड़ते हैं?

प्रत्येक पृष्ठ लोड पर कई प्रश्नों के बिना उपयोगकर्ता संबंध को पूरा करने का सबसे प्रभावी तरीका क्या है? मैंने DbReference<T> नोएआरएम में टाइप किया है, लेकिन अभी तक इसका उपयोग करने का एक शानदार तरीका नहीं मिला है। अगर मेरे पास वैकल्पिक वैकल्पिक संबंध हैं तो क्या होगा?

आपकी अंतर्दृष्टि के लिए धन्यवाद!

+0

+1, मैंने वही बात सोच ली है। – jgauffin

उत्तर

1

मुझे लगता है कि आपको संतुलन को रोकने की आवश्यकता है।

यदि मैं आप थे, तो मैं प्रत्येक पोस्ट में उनके नाम/प्रतिष्ठा के बजाय उपयोगकर्ता आईडी का संदर्भ दूंगा।

हालांकि आरडीबीएमएस के विपरीत, आप दस्तावेज़ में एम्बेड की गई टिप्पणियां चुनने का विकल्प चुनते हैं।

+0

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

1

क्यों आप denormalization से बचने और 'हजारों दस्तावेज़ रिकॉर्ड' को अपडेट करना चाहते हैं? Mongodb डीबी denormalization के लिए बनाया गया है। Stackoverlow पृष्ठभूमि में लाखों अलग-अलग डेटा संभालते हैं। और कुछ डेटा कुछ छोटी अवधि के लिए बालों का हो सकता है और यह ठीक है।

तो उपरोक्त का मुख्य विचार यह है कि आपको उई में तेज़ी से प्रदर्शित करने के लिए असामान्य दस्तावेज होना चाहिए।

आप संदर्भित दस्तावेज़ द्वारा क्वेरी नहीं कर सकते हैं, किसी भी तरह से आपको denormalization की आवश्यकता है।

इसके अलावा मुझे सलाह है कि cqrs आर्किटेक्चर में देखें।

+0

ऐसा नहीं है कि मैं denormalization से बचना चाहता हूँ, लेकिन मैं स्वाभाविक रूप से खराब डिजाइन से बचना चाहता हूँ। उस बिंदु पर उपयोगकर्ता रिकॉर्ड के रूप में कुछ सामान्य को अलग करना जहां मैं प्रति सेकंड हजारों उपयोगकर्ता रिकॉर्ड अपडेट कर सकता हूं, लगातार लगता है 1. ओवरकिल की तरह 2. डिस्क स्थान के खराब उपयोग की तरह। क्या कोई अन्य विकल्प नहीं है? – jocull

+0

यह आपके इच्छित चीजों पर निर्भर करता है: यदि आप 'डिस्क स्पेस' और डिमर्मलाइजेशन की परवाह करते हैं, तो शायद आपके लिए मेरे उत्तर की तुलना में अधिक नहीं है, लेकिन यदि आप प्रदर्शन की परवाह करते हैं और आप ऊपर की ओर जाना चाहते हैं - मार्ग। –

+2

उल्लेख नहीं है, डिस्क स्पेस * सस्ता * –

1

cqrs and event sourcing आर्किटेक्चर की जांच करने का प्रयास करें। यह आपको कतार द्वारा इस डेटा को अपडेट करने की अनुमति देगा।

2

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

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

** संपादित करें ** मैंने अभी आपके प्रश्न को फिर से पढ़ लिया और महसूस किया कि आप वास्तव में क्या पूछ रहे थे। अगर मैं इसके सहायक हो तो मैं अपना मूल उत्तर छोड़ रहा हूं।

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

फिर आप टिप्पणी डेटा को पार करेंगे और उपयोगकर्ता आईडी की एक सरणी खींच लेंगे जिसे आपको लोड करने की आवश्यकता है। फिर उन्हें बैच क्वेरी के रूप में लोड करें (Q.In() क्वेरी ऑपरेटर का उपयोग करके)। कुल दो प्रश्न पूछता है। इसके बाद आपको डेटा को एक अंतिम रूप में मर्ज करने की आवश्यकता होगी। एक संतुलन है जिसे आपको इस तरह करने के दौरान और प्रत्येक दस्तावेज़ को मैन्युअल रूप से अपडेट करने के लिए ईएसबी की तरह कुछ उपयोग करने के बीच हमला करने की आवश्यकता होती है। अपनी डेटा संरचना के प्रत्येक व्यक्तिगत परिदृश्य के लिए सबसे अच्छा काम करता है।

+0

मुझे यह समाधान पसंद है। उपयोगकर्ता आईडी के बैच को लोड करना और फिर डेटा को इकट्ठा करना एक अच्छा विचार है। – jocull