जब आप JMS (या सामान्य रूप से एक कतार) का उपयोग करते हैं तो डेटाबेस

Question

बनाते समय जब आप एक कतार में कोई संदेश संग्रहीत करते हैं, तो यह मेटा डेटा जानकारी से अधिक नहीं है, इसलिए जो कोई भी कतार से खींचता है उसे जानता है कि प्रक्रिया को कैसे संसाधित किया जाए डेटा? कतार में वास्तविक जानकारी हमेशा सभी जानकारी नहीं रखती है।

कहें कि आपके पास ट्विटर जैसा ऐप है, जब भी कोई कोई संदेश पोस्ट करता है, तो आपको अभी भी डेटाबेस में वास्तविक संदेश टेक्स्ट को स्टोर करने की आवश्यकता होगी?

कतार का उपयोग अन्य ग्राहकों को प्रसारित करने के लिए और अधिक उपयोग किया जाएगा कि एक नया संदेश आ गया है, और फिर वे सेवाएं आगे की कार्रवाई कर सकती हैं।

या क्या आप वास्तव में कतार में ट्वीट टेक्स्ट भी स्टोर कर सकते हैं? (या आप कर सकते हैं, लेकिन यह मूर्खतापूर्ण होगा?)

क्या कतार संदेश में स्थिति फ़ील्ड हो सकते हैं, जो ग्राहक काम के प्रवाह के अपने हिस्से को संसाधित करते समय बदल सकते हैं? (या आप डीबी में ऐसा करेंगे?)

बस जब आप कतार बनाम डीबी का उपयोग करेंगे तो कुछ स्पष्टीकरण प्राप्त करने का प्रयास कर रहे हैं।

Answer 1

एक प्रक्रिया खेत डेटा और एक अन्य प्रक्रिया (संभवतः एक अलग मेजबान पर) के लिए बाहर है कि डेटा के प्रसंस्करण के लिए करना चाहता है, वहाँ 2 रणनीतियों हैं: कतार मद में

1. सामग्री सभी अपने डेटा और प्राप्त करने वाले ऐप को डेटाबेस में इसे संग्रहीत करने की चिंता करने दें, जो भी अन्य प्रोसेसिंग के साथ है।

2. अपना डेटाबेस अपडेट करें, और फिर अन्य प्रक्रिया में एक छोटा संदेश कतार दें ताकि यह सूचित किया जा सके कि नया डेटा मालिश किया जा सके।

कारक हैं जो तय करने के लिए इस्तेमाल किया जा सकता का एक संख्या हैं जो रणनीति पर:

• तो अपने डेटाबेस पूरी तरह से एसिड है (एक आशा करता हूं) लेकिन अपने कतार प्रणाली (QS) नहीं है , आपका डेटा डीबी में सुरक्षित होगा। यहां तक ​​कि यदि सर्वर क्रैश में कतार संदेश गुम हो जाता है, तो आप डीबी में पाए गए असुरक्षित डेटा को संसाधित करने के लिए एक स्क्रिप्ट चला सकते हैं। यह विकल्प 2 के लिए एक मामला होगा।

• यदि आपका डेटा काफी बड़ा है (कहें, 1 एमबी या अधिक) तो यह आपके क्यूएस को बोझ करने के लिए क्रूर हो सकता है। यदि यह लगातार है, तो आप डेटा को दो बार लिखेंगे, पहले क्यूएस के उत्थान के लिए और बाद में डीबी में। यह प्रदर्शन पर एक ड्रैग हो सकता है और आपको विकल्प 1 के लिए जाने के लिए प्रभावित कर सकता है।

• यदि आपका डीबी धीमा है या आपके ऐप के फ्रंट एंड तक भी पहुंच योग्य नहीं है, तो विकल्प 1 यह है।

• अपने दूसरे प्रक्रिया डेटा के साथ कुछ करने के लिए, लेकिन एक DB में संग्रहीत नहीं जा रहा है, तो फिर विकल्प 1 जाने का रास्ता हो सकता है।

अब और नहीं सोच सकता, लेकिन मुझे उम्मीद है कि आपको यह विचार मिल जाएगा।

Answer 2

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

ऐसा नहीं है कि आप जेएमएस में ट्वीट नहीं डाल सकते हैं कि आपको इसे डेटाबेस में किसी भी तरह से रखना होगा।

Answer 3

मैं अनुशंसा करता हूं कि आप ग्रेगोर होप की पुस्तक, Enterprise Integration Patterns देखें, जो मैसेजिंग-आधारित दृष्टिकोणों के लिए कई अलग-अलग पैटर्न बताती है।

Answer 4

आम तौर पर, आने वाली अनुरोधों को बफर करके, आने वाली अनुरोधों को बफर करके, कतार दर बनाम प्रकाशित दर को 'चिकनी' करने के लिए एक कतार का उपयोग किया जाता है जिसे तुरंत संभाला नहीं जा सकता है। एक कतार आमतौर पर किसी प्रकार के गैर-अस्थिर भंडारण (जैसे डेटाबेस तालिका) द्वारा समर्थित होती है। तो भेद इतना स्पष्ट कट नहीं है।

जब आप अपनी 'कतार' के खिलाफ कई खोज करना चाहते हैं, या समृद्ध रिपोर्टिंग प्रदान करना चाहते हैं तो डेटाबेस का उपयोग करें।

Answer 5

जब भी आप "आग-और-भूल" पैटर्न का उपयोग कर सकते हैं तो मैं कतार का उपयोग करूंगा। आपके ट्विटर उदाहरण में, मैं क्लाइंट से संदेश पोस्ट करने के लिए कतार का उपयोग करूंगा। कतार प्रोसेसर इसे तब डेटाबेस में संग्रहीत कर सकता है जब यह हो जाता है।

यदि आपको किसी प्रकार की तत्काल सफलता/विफलता स्थिति की आवश्यकता है, तो संदेश कतार आपके लिए नहीं है।

Answer 6

हम बड़े पैमाने पर मेरा आखिरी काम जहाँ हम मशीन के लिए मशीन से चारों ओर डेटा गुजर रहे थे पर JMS इस्तेमाल किया। अंत में, हम दोनों एक ही समय में डेटा भेज और संग्रहित कर रहे थे; हालांकि, हमने भेजे गए से बहुत कम डेटा संग्रहीत किया है। हमारे पास असली मूल्यों के आस-पास बहुत सारे मेटाडेटा थे।

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

मुख्य लाभ यह है कि JMS आप देता है में से एक सही और उचित क्रम में अपने संदेश बाहर भेजने और सुनिश्चित करें कि हर कोई उन्हें इसी क्रम में प्राप्त करता है की क्षमता है। इससे सिंक्रनाइज़ेशन आसान हो जाता है क्योंकि अधिकांश संदेश हैंडलिंग आपके लिए किया जाता है।

Answer 7

मेरे समझ ट्विटर संयोजन के रूप में दोनों DB और JMS का उपयोग किया जाएगा। सबसे पहले जब ट्वीट लिखे जाते हैं तो यह इसे डेटाबेस में संग्रहीत करेगा और इस तरह यह संदेश बोर्ड में प्रदर्शित होगा। हालांकि चूंकि यह एक प्रकाशक/ग्राहक मॉडल है जब ट्वीट प्रकाशित होते हैं तो इसे ग्राहकों को भेजा जाएगा। तो दोनों वस्तुओं का उपयोग किया जाएगा।