तो बडीमीडिया इसका कुछ उपयोग कर रहा है। गिल्ट ग्रुप ने हमिंगबर्ड के साथ कुछ बहुत अच्छा किया है (नोड.जेएस + मोंगोडीबी)।
सोशल मीडिया स्पेस में एक बड़े ऑनलाइन विज्ञापनदाता के लिए काम करने के बाद, मैं प्रमाणित कर सकता हूं कि रीयल-टाइम रिपोर्टिंग वास्तव में एक दर्द है। एक दिन में 500 मिलियन छापों को "रोल-अप" करने की कोशिश करना पहले से ही एक चुनौती है, लेकिन इसे वास्तविक समय में करने की कोशिश ने काम किया, लेकिन इसमें कुछ महत्वपूर्ण सीमाएं थीं। (जैसे यह वास्तव में 5 मिनट की देरी से हुआ था :)
सच कहूँ तो, इस प्रकार की समस्या एक कारण है कि मैंने MongoDB का उपयोग करना शुरू किया। और मैं अकेला नहीं हूं। लोग सभी प्रकार के रीयल-टाइम विश्लेषण के लिए MongoDB का उपयोग कर रहे हैं:सर्वर मॉनिटरिंग , केंद्रीकृत लॉगिंग , साथ ही साथ डैशबोर्ड रिपोर्टिंग।
इस प्रकार की रिपोर्टिंग करते समय वास्तविक कुंजी यह समझना है कि डेटा संरचना MongoDB के साथ पूरी तरह से अलग है, आप "एकत्रीकरण" प्रश्नों से बचने जा रहे हैं, इसलिए प्रश्न और आउटपुट चार्ट अलग होने जा रहे हैं। क्लाइंट साइड पर कुछ अतिरिक्त कोडिंग कार्य है।
यहाँ वह कुंजी है जो आपको MongoDB के साथ ऐसा करने के लिए सही दिशा में इंगित कर सकती है। निम्न डेटा संरचना पर एक नज़र डालें:
{
date: "20110430",
gender: "M",
age: 1, // 1 is probably a bucket
impression_hour: [ 100, 50, ...], // 24 of these
impression_minute: [ 2, 5, 19, 8, ... ], // 1440 of these
clicks_hour: [ 10, 2, ... ],
...
}
स्पष्ट रूप से यहां कुछ बदलाव हैं, उपयुक्त अनुक्रमणिका, शायद डेटा+लिंग+आयु को _id में बदलना . लेकिन यह मोंगोडीबी के साथ क्लिक एनालिटिक्स की मूल संरचना है। इंप्रेशन और क्लिक को अपडेट करना वाकई आसान है { $inc : { clicks_hour.0 : 1 } } . आपको संपूर्ण दस्तावेज़ को परमाणु रूप से अपडेट करने को मिलता है। और इस पर रिपोर्ट करना वास्तव में बहुत स्वाभाविक है। आपके पास पहले से ही आपकी एक सरणी है जिसमें आपके प्रति घंटा या मिनट-स्तर के डेटा बिंदु हैं।
उम्मीद है कि यह आपको सही दिशा में इंगित कर रहा है।
