2010-05-26 7 views
7

ampq या xmpp (rabbitmq या ejabbered जिसका उपयोग बैकएंड के रूप में couchdb हो सकता है) का उपयोग करते हुए एक सामाजिक गेमिंग प्लेटफ़ॉर्म में मित्र राज्य के बारे में वास्तविक समय अपडेट देने के लिए एक अच्छा फिट लगता है जहां अपडेट छोटे होते हैं लेकिन अक्सर, मैं मदद नहीं कर सकता लेकिन सोच सकता हूं ऐसे अपडेट देने के लिए couchdb एक अच्छा मंच क्यों नहीं होगा?किसी भी कारण से मुझे संदेश गुजरने या रीयलटाइम गतिविधि धाराओं के लिए couchdb का उपयोग नहीं करना चाहिए?

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

हालांकि, मैं मदद नहीं कर सकता लेकिन लगता है कि यह सच होने के लिए बहुत अच्छा है, मुझे सोफेडब की कमियों के बारे में जानकारी नहीं मिल रही है। किसी भी तरह, यह संदेश पास करने के लिए MySQL का उपयोग करने जैसा लगता है, यही कारण है कि मैं इसका उपयोग करने में संकोच करता हूं।

किसी को भी ऐसे अनुप्रयोगों के लिए couchdb का उपयोग करने में कोई अनुभव है? क्या आप उपयोग करने के लिए एक और मंच की सिफारिश करेंगे?

उत्तर

6

यहां कुछ समस्याएं हैं जिन्हें आप "छोटे लेकिन लगातार" अपडेट और कॉच डीबी के साथ चलाएंगे।

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

फ़िल्टर किए गए परिवर्तनों का उपयोग करके आपके पास एक और समस्या यह हो सकती है कि फ़िल्टर फ़ंक्शन अनुरोध ऑब्जेक्ट प्राप्त करता है, जिसका अर्थ यह है कि कनेक्शन की संख्या से गुणा प्रत्येक दस्तावेज़ के लिए दृश्य सर्वर पर एक अलग कॉल है। आप फ़िल्टरिंग को बदलने के लिए "चैनल" दृष्टिकोण को लागू करने के लिए node.js या erlang सर्वर का उपयोग करना चाह सकते हैं और इसे एक एकल फ़िल्टर किए गए परिवर्तन फ़ीड पर बैठ सकते हैं।

सारांशित करने के लिए, आप जो करना चाहते हैं, वह अच्छी तरह से काम करेगा यदि आपके पास उच्च आवृत्ति पर एक ही दस्तावेज़ को अपडेट करने का प्रयास करने वाले एकाधिक ग्राहक नहीं हैं और यदि आप एक बड़ी संख्या में समवर्ती ग्राहकों पर परिवर्तन फ़िल्टर का उपयोग नहीं करते हैं एक उच्च डेटाबेस अद्यतन आवृत्ति के साथ। इसके अलावा, यह बहुत अच्छा काम करेगा। @jchris ने केवल नंगे परिवर्तन फ़ीड का उपयोग करके रीयल-टाइम एप्लिकेशन का एक टन किया है और वे बहुत अच्छा काम करते हैं।

+0

इसलिए यदि मैं node.js का उपयोग करके अद्यतनों को एकत्रित करना चाहता हूं और नोड के केवल एक ही उदाहरण का उपयोग करके थोक अद्यतनों के साथ समय-समय पर (प्रत्येक कुछ मिनट) को अद्यतन कर सकता हूं।जेएस, तो अद्यतन करना मेरी सबसे बड़ी समस्या नहीं होगी। मेरी चिंता तब होगी, जो कॉचडब से कनेक्ट होने वाले कई ग्राहकों के विचारों का उपयोग करके अद्यतनों को फ़िल्टर कर रही है। यह किसी भी तरह से कम किया जा सकता है यदि मैं डिस्क स्थान की कीमत पर प्रति उपयोगकर्ता डेटाबेस बना देता हूं, और बस उस डेटाबेस में अपने अपडेट पोस्ट करता हूं जैसे कि प्रत्येक क्लाइंट को फ़िल्टर किए गए अपडेट मिलते हैं, जहां वास्तविकता में फ़िल्टरिंग संदेशों को डीबीएस –

+0

पर रूट करके किया जाता है हाँ, यह एक तरीका है। आप केवल एक नोड प्रक्रिया को सभी परिवर्तनों को सुन सकते हैं और परिवर्तनों पर फ़िल्टरिंग प्रदान कर सकते हैं जो दृश्य सर्वर कॉल प्रति परिवर्तन श्रोता पर सभी अतिरिक्त आईओ विलंबता को हटा देगा। सोफेडब के साथ "फर्जी" परमाणु अपडेट के तरीके भी हैं जो संशोधन मुद्दों को कम कर सकते हैं http://www.mikealrogers.com/archives/737 – mikeal

+1

मुझे लगता है कि यहां 'अपडेट' शब्द के बारे में कुछ भ्रम है। यह मुझे लगता है जैसे प्रश्नकर्ता कई संदेशों के निर्माण के बारे में और बात कर रहा है, जरूरी नहीं कि प्रत्येक को अपडेट किया जाए। तो "हर अद्यतन संशोधन में परिवर्तन" के बारे में आपत्ति यहां लागू नहीं हो सकती है। संभवतः प्रत्येक संदेश एक नया "दस्तावेज़" बनायेगा, और बाद में "विचार" उस जानकारी को आवश्यकतानुसार प्रस्तुत करेगा। –

1

मैं एक बहुत ही सरल कारण के बारे में सोच सकता हूं ... क्योंकि डेटाबेस को ऐसा करने के लिए डिज़ाइन नहीं किया गया था!

एक संदेश कतार बिल्कुल इस तरह के काम प्रवाह की जरूरत है। क्या आपने कुछ एएमक्यूपी आधारित उत्पादों या सेवाओं को देखा है? इनमें RabbitMQ (स्थानीय रूप से स्थापित) और स्टॉर्मएमक्यू (क्लाउड आधारित सेवा) शामिल हैं। अधिक यहाँ: http://www.amqp.org

2

हालांकि, मैं मदद नहीं कर सकते लेकिन लगता है कि यह वास्तव में बहुत ही अच्छा है, मैं क्या CouchDB के कमियों हैं के बारे में जानकारी नहीं मिल रहा कर सकते हैं। किसी भी तरह, यह संदेश संदेश के लिए MySQL का उपयोग करने जैसा लगता है, यही कारण है कि मैं इसका उपयोग कर पर संकोच करता हूं।

कोशिश क्यों Databases suck for Messaging प्रस्तुति को देखने के लिए। हालांकि यह मुख्य रूप से MySQL जैसे डेटाबेस के खिलाफ लक्षित है, यह आपको इस विषय पर एक बड़ा चित्रकार दे सकता है।

+0

मुझे यकीन नहीं है कि यह लागू होता है। वह डेटाबेस मतदान के बारे में बात नहीं कर रहा है। रीचटाइम निरंतर अधिसूचनाओं के लिए कॉच डीबी के पास एक विशिष्ट एपीआई है। –

संबंधित मुद्दे

 संबंधित मुद्दे