मुझे इस स्कीमा को मोंगोडीबी में कैसे कार्यान्वित करना चाहिए?

ठीक है, मुझे लगता है कि आपको इसे बुनियादी "किस्मों" में बांटना होगा।

आपके पास दो "इकाई" -स्टाइल ऑब्जेक्ट हैं:

• User
• Campaign

आपके पास एक "मैपिंग" -स्टाइल ऑब्जेक्ट है:

• UserCampaign

आपके पास एक "लेन-देन संबंधी"-शैली की वस्तु है:

• Click

चरण 1:इकाई

आइए आसान से शुरू करें:User &Campaign . ये वास्तव में दो अलग-अलग वस्तुएं हैं, इनमें से कोई भी वास्तव में अपने अस्तित्व के लिए दूसरे पर निर्भर नहीं है। दोनों के बीच कोई अंतर्निहित वंशानुक्रम भी नहीं है:उपयोगकर्ता अभियानों से संबंधित नहीं हैं, न ही अभियान उपयोगकर्ताओं से संबंधित हैं।

जब आपके पास इस तरह की दो शीर्ष-स्तरीय वस्तुएं होती हैं, तो वे आम तौर पर अपना संग्रह अर्जित करते हैं। तो आपको एक User चाहिए होगा संग्रह और एक Campaign संग्रह।

चरण 2:मानचित्रण

UserCampaign वर्तमान में एन-टू-एम मैपिंग का प्रतिनिधित्व करने के लिए उपयोग किया जाता है। अब, सामान्य तौर पर, जब आपके पास N-to-1 मैपिंग होती है, तो आप N को 1 के अंदर रख सकते हैं। हालाँकि, N-to-M मैपिंग के साथ, आपको आम तौर पर "एक पक्ष चुनना" पड़ता है।

सिद्धांत रूप में, आप निम्न में से कोई एक कार्य कर सकते हैं:

1. Campaign ID की सूची डालें प्रत्येक User . के अंदर s
2. Users ID की एक सूची डालें प्रत्येक Campaign . के अंदर

व्यक्तिगत रूप से, मैं # 1 करूँगा। संभवतः आपके पास अधिक उपयोगकर्ता हैं जो अभियान चलाते हैं, और आप शायद उस सरणी को रखना चाहते हैं जहां यह छोटा होगा।

चरण 3:लेन-देन संबंधी

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

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

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

इसके अतिरिक्त, क्लिक आपके सिस्टम में सबसे अधिक मात्रा में डेटा होने जा रहे हैं। आपको किसी भी चीज़ की तुलना में बहुत अधिक क्लिक मिलने वाले हैं।

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

इसे लपेटना

आप शायद तीन संग्रह चाहते हैं:

1. उपयोगकर्ता -> के पास अभियान की सूची है।_id
2. अभियान
3. क्लिक -> में उपयोगकर्ता._आईडी, अभियान._आईडी शामिल है

यह आपकी सभी क्वेरी आवश्यकताओं को पूरा करना चाहिए:

आईपी, रेफरर, ओएस, आदि जैसे प्रत्येक क्लिक से जानकारी देखें

db.clicks.find()

देखें कि कितनी बार X IP, X Referer, X OS से क्लिक आ रहे हैं

db.clicks.group() या मैप-रिड्यूस चलाएं।

प्रत्येक क्लिक को एक उपयोगकर्ता और एक अभियान के साथ संबद्ध करें

db.clicks.find({user_id : blah}) क्लिक आईडी को उपयोगकर्ताओं और अभियानों दोनों में पुश करना भी संभव है (यदि यह समझ में आता है)।

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