मैसेजिंग सिस्टम में टेबल्स के खिलाफ कतार

Question

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

1. डेटा स्थायी रूप से किसी तालिका पर संग्रहीत किया जाता है। मैंने इतने सारे जावा (जेएमएस) अनुप्रयोगों को देखा है जो बिना किसी अपवाद या अन्य बग के लिए संदेशों को खो देते हैं या गायब कर देते हैं।
2. पंक्तियां भरने लगती हैं। डीबी भंडारण इसके बजाय लगभग अनंत है।
3. टेबल्स आसानी से सुलभ हैं, जबकि आपको कतार से पढ़ने के लिए ईसाई उपकरणों का उपयोग करना है।

प्रत्येक दृष्टिकोण पर आपकी राय क्या है?

Answer 1

वाक्यांश हर बार धड़कता है पूरी तरह से आपकी आवश्यकताओं के साथ क्या शुरू करना था इस पर निर्भर करता है। निश्चित रूप से यह हर किसी के लिए हर बार हरा नहीं जा रहा है।

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

सरल, कम यद्यपि, अधिकतर थ्रेडेड सामान के लिए, डेटाबेस संदेश कतारों का एक बिल्कुल सही विकल्प है। (एक डेटाबेस का उपयोग

जहां एक संदेश कतार चमकता है जब

• आप एक उच्च प्रदर्शन, अत्यधिक समवर्ती और स्केलेबल लोड संतुलन ताकि आप प्रति सेकंड संदेशों के हजारों समवर्ती कई सर्वरों/प्रक्रियाओं में संसाधित कर सकते हैं चाहता हूँ टेबल आप कुछ सौ सेकेंड को संसाधित करने के लिए भाग्यशाली होंगे और एकाधिक धागे के साथ प्रोसेसिंग बहुत कठिन है क्योंकि एक प्रक्रिया संदेश कतार तालिका को लॉक करने के लिए प्रवृत्त होगी)
• आपको विभिन्न डेटाबेस का उपयोग करके विभिन्न प्रणालियों के बीच संवाद करने की आवश्यकता है (इसलिए डॉन ' टी को अलग-अलग टीमों में अन्य लोगों के लिए अपने सिस्टम डेटाबेस में लेखन पहुंच को हाथ देना होगा)

एक डेटाबेस, टीम और काफी मामूली प्रदर्शन आवश्यकताओं के साथ सरल प्रणालियों के लिए - निश्चित रूप से डेटाबेस का उपयोग करें। नौकरी इत्यादि के लिए सही उपकरण का उपयोग करें

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

प्रदर्शन के संदर्भ में एक संदेश कतार हमेशा डेटाबेस तालिका को हराएगी - क्योंकि संदेश कतार विशेष रूप से नौकरी के लिए डिज़ाइन की गई हैं और निराशावादी तालिका ताले पर निर्भर नहीं हैं (जो कि कतार के डेटाबेस कार्यान्वयन के लिए आवश्यक हैं - करने के लिए भार संतुलन) और good message queues will perform eager loading of messages to queues to avoid the network overhead of a database।

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

Answer 2

कतार विश्वसनीय संदेश प्रदान करते हैं। स्टोर-एंड-फॉरवर्ड, क्यूइंग की डिस्कनेक्ट की गई प्रकृति डेटाबेस की तुलना में इसे अधिक स्केलेबल बनाती है, अधिक मजबूत नहीं है।

और कतारों का वास्तव में जानकारी के स्थायी भंडारण के लिए उपयोग नहीं किया जाना चाहिए - डेटाबेस के विपरीत, अस्थायी इनबॉक्स के रूप में उनके बारे में सोचना सबसे अच्छा है।

Answer 3

मैंने पहले टेबल का उपयोग किया है, फिर एक पूर्ण संदेश कतार में प्रतिक्रिया दें (और यदि) कारण है - यदि आपका डिज़ाइन उचित है तो यह छोटा है।

सबसे बड़ा लाभ एक है।) यह आसान है, (बी। यह एक बेहतर ऑडिट ट्रेल है क्योंकि आपके पास अन्य टेबल शामिल हैं, सी।) यदि आप डेटाबेस टूल्स को वास्तव में अच्छी तरह से जानते हैं, तो वे उपयोग करना आसान हैं संदेश कतार उपकरण, डी।) आमतौर पर एक ऐसे संदर्भ में एक परीक्षण/देव पर्यावरण स्थापित करना थोड़ा आसान होता है जो आपके ऐप के लिए पहले से मौजूद है (यदि समान परिचितता लागू होती है)।

ओह, और ई।) शायद आप और दूसरों के लिए, यह सीखने, स्थापित करने, कॉन्फ़िगर करने, प्रशासन करने और समर्थन करने के लिए एक और उत्पाद नहीं है।

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

Answer 4

1. डेटा स्थायी रूप से किसी तालिका पर संग्रहीत किया जाता है। मैंने इतने सारे जावा (जेएमएस) अनुप्रयोगों को देखा है जो बिना किसी अपवाद या अन्य बग के लिए संदेशों को ढीला या गायब कर देते हैं।

   कौन सा जेएमएस कार्यान्वयन? सूर्य विश्वसनीय कतार बेचता है जो संदेश खो नहीं सकता है। शायद आपने अभी एक शर्मीली जेएमएस-अनुरूप उत्पाद खरीदा है। आईबीएम का एमक्यू बेहद विश्वसनीय है, और इसमें पहुंचने के लिए जेएमएस पुस्तकालय हैं।

2. पंक्तियां भरने लगती हैं। डीबी भंडारण इसके बजाय लगभग अनंत है।

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

3. टेबल्स आसानी से सुलभ हैं, जबकि आपको कतार से पढ़ने के लिए ईसाई उपकरणों का उपयोग करना है।

   यह मेरे अनुभव के अनुरूप नहीं है।टेबल्स को इस असाधारण "अन्य भाषा" (एसक्यूएल) के माध्यम से एक्सेस किया जाता है, और यह आवश्यक है कि मैं टेबल से ऑब्जेक्ट्स और डेटा प्रकार मैपिंग्स से VARCHAR2 से स्ट्रिंग तक संरचना मैपिंग से अवगत रहूं। इसके अलावा, मुझे किसी प्रकार की एक्सेस लेयर (जेडीबीसी या ओआरएम का उपयोग करना है जो जेडीबीसी का उपयोग करता है)। यह बहुत जटिल लगता है। संदेश कंसुमर्स और संदेश प्रोड्यूसर के माध्यम से सरल कमान और प्राप्त करने के माध्यम से एक कतार का उपयोग किया जाता है।

Answer 5

ऐसा लगता है जैसे कि समस्याओं को आप अनुभव किया है मैसेजिंग के लिए निहित नहीं हैं, बल्कि खराब कार्यान्वित संदेश प्रणाली की कलाकृतियों हैं। क्या डाटाबेस सिस्टम बनाने से हार्ड मैसेजिंग सिस्टम बनाना कठिन है? हां, अगर आप कभी भी डेटाबेस सिस्टम बनाते हैं।

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

पहलुओं:

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

यदि आपको इन चीजों की आवश्यकता नहीं है, तो आपको शायद संदेश की आवश्यकता नहीं है।

संदेश के लिए आवेदन का एक सरल उदाहरण यहां दिया गया है: मैं अभी एक सिस्टम बना रहा हूं जहां कई नेटवर्कों में वितरित उपयोगकर्ता, लेनदेन के काफी जटिल सेट दर्ज कर रहे हैं जिनका उपयोग मुद्रित आउटपुट के उत्पादन के लिए किया जाता है। आउटपुट पीढ़ी कम्प्यूटेशनल रूप से महंगा है और उनके वर्कफ़्लो का हिस्सा नहीं है; यानी जब उपयोगकर्ता उत्पन्न होता है तो उपयोगकर्ता परवाह नहीं होता है, बस यह करता है।

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

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