हमें PostgreSQL जैसे डेटाबेस पर RabbitMQ जैसे संदेश दलालों की आवश्यकता क्यों है?

Question

मैं मेसेज ब्रोकरों के लिए नया हूं जैसे कि RabbitMQ जिसे हम सेलेरी जैसे शेड्यूलिंग सिस्टम के लिए कार्य / संदेश कतार बनाने के लिए उपयोग कर सकते हैं ।

अब, यहाँ प्रश्न है:

• मैं PostgreSQL में एक तालिका बना सकता हूं जिसे नए कार्यों के साथ जोड़ा जा सकता है और अजवाइन जैसे उपभोक्ता कार्यक्रम द्वारा उपभोग किया जा सकता है।

• पृथ्वी पर मैं इसके लिए एक नया तकनीकी सेटअप क्यों करना चाहूंगा जैसे कि RabbitMQ?

अब, मेरा मानना ​​है कि स्केलिंग उत्तर नहीं हो सकता है क्योंकि हमारे पोस्टग्रेक्यूएल जैसे डेटाबेस वितरित वातावरण में काम कर सकते हैं।

मैंने जाना कि डेटाबेस विशेष समस्या के लिए क्या समस्याएँ खड़ी करता है, और मैंने पाया:

• मतदान डेटाबेस को व्यस्त और कम प्रदर्शन करता है
• तालिका का लॉकिंग -> फिर से कम प्रदर्शन
• कार्यों की लाखों पंक्तियाँ -> फिर से, मतदान कम प्रदर्शन है

अब, RabbitMQ या कोई अन्य मैसेज ब्रोकर कैसे इन समस्याओं को हल करता है?

इसके अलावा, मुझे पता चला कि AMQPप्रोटोकॉल वह है जो इसका अनुसरण करता है। उसमें महान क्या है?

क्या रेडिस का उपयोग एक संदेश दलाल के रूप में भी किया जा सकता है? मुझे यह RabbitMQ की तुलना में Memcached के लिए अधिक अनुरूप लगता है।

कृपया इस पर कुछ प्रकाश डालें!

Comments

लॉकिंग का प्रभाव PostgreSQL के साथ बहुत कम होना चाहिए क्योंकि यह MVCC को लागू करता है जहां पाठकों को लेखकों द्वारा अवरुद्ध नहीं किया जाता है और इसके विपरीत। अधिकांश लेखों में मैंने डेटाबेस के उपयोग की आलोचना की है क्योंकि संदेश कतारों में MySQL को ध्यान में रखा गया है।

— CadentOrange

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

— theMayer

"शेड्यूलिंग सिस्टम जैसे celery" - मैंने बस कुछ सीखा जो मेरे डिजाइन में उपयोगी होगा, सवाल से । अब जवाब पढ़ने के लिए ...

— मार्क के कोवान

मैसेज ब्रोकर प्रोड्यूसर और कंज्यूमर को इस्तेमाल करने से डिकॉय किया जाता है।

— जियोर्गी दैविशविली

आप bellow लिंक देख सकते हैं। इसका विस्तृत वर्णन है: stackoverflow.com/a/51377756/3073945

— Md। सजदुल करीम

Answer 1

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

आपके द्वारा बताई गई समस्याओं के लिए:

• मतदान डेटाबेस buzy और खराब प्रदर्शन करने रखते हुए : RabbitMQ का उपयोग करना, उत्पादकों कर सकते हैं धक्का उपभोक्ताओं के लिए अद्यतन जो कहीं अधिक मतदान से performant। डेटा को उपभोक्ता को बस तब भेजा जाता है जब उसे ज़रूरत पड़ने पर बेकार की जाँच की आवश्यकता को समाप्त कर दिया जाता है।

• तालिका का लॉकिंग -> फिर से कम प्रदर्शन: लॉक करने के लिए कोई तालिका नहीं है: पी

• कार्य की लाखों पंक्तियाँ -> फिर से मतदान कम प्रदर्शन कर रहा है: जैसा कि ऊपर बताया गया है, रैबिटमैक तेजी से संचालित होगा क्योंकि यह रैम का निवास करता है, और प्रवाह नियंत्रण प्रदान करता है। यदि आवश्यक हो, तो यह रैम से बाहर चलने पर संदेशों को अस्थायी रूप से संग्रहीत करने के लिए डिस्क का उपयोग भी कर सकता है। 2.0 के बाद, खरगोश ने अपने रैम उपयोग पर काफी सुधार किया है। क्लस्टरिंग विकल्प भी उपलब्ध हैं।

एएमक्यूपी के संबंध में, मैं कहूंगा कि वास्तव में एक अच्छी सुविधा "एक्सचेंज" है, और इसके लिए अन्य एक्सचेंजों के लिए मार्ग की क्षमता है। यह आपको अधिक लचीलापन देता है और आपको विस्तृत मार्ग टाइपिंग की एक विस्तृत सरणी बनाने में सक्षम बनाता है जो स्केलिंग करते समय बहुत काम आ सकता है। एक अच्छे उदाहरण के लिए, देखें:

_{(स्रोत: springsource.com )}

और: http://blog.springsource.org/2011/04/01/rout-topologies-for-performance-and-scalability-with-rabbitmq/

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

यहां एक लंबी-मतदान चैट कार्यान्वयन में उपयोग की जाने वाली रेडियों का एक उदाहरण दिया गया है: http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/

Comments

मैंने एक डेटाबेस के शीर्ष पर एक जेएमएस कार्यान्वयन (यानी एक संदेश पासिंग सिस्टम) लागू किया है। मैं आपको बता सकता है कि यह है संभव है, लेकिन यह मजेदार नहीं है और यह आमतौर पर बंद का भुगतान नहीं करता यह करने के लिए। आपके द्वारा बताई गई कुछ समस्याओं पर काम किया जा सकता है, लेकिन यह जटिलता को काफी बढ़ा देती है। सभी सभी मैं सहमत हूं: यदि आपको एक की आवश्यकता है, तो एक समर्पित MQ प्रणाली का उपयोग करें। कम वर्कलोड के लिए, आप इसे डीबी में होने के साथ दूर कर सकते हैं, हालांकि।

— जोकिम सॉयर

आपने बस सभी चिंताओं / संदेहों को कवर किया है। बहुत बढ़िया जवाब!

— युगल जिंदल

यह तो दिलचस्प है। किस तरह से स्थिरता के बारे में? क्या होगा अगर एक कतार में सैकड़ों काम हैं और नोड उन्हें राम दुर्घटनाओं में पकड़े हुए हैं?

— महन

दरअसल, PostgreSQL के साथ कोई मतदान नहीं होता है (NOTIFY देखें) और न ही टेबल लॉक होते हैं (MVCC देखें)। हालांकि PostgreSQL अभी भी संदेश कतार के लिए डिज़ाइन नहीं किया गया है, यह पूरी तरह से अनुपयुक्त नहीं है।

— 18

@Jkj ने जो कहा, जैसे कि NOTIFY और कोई टेबल लॉक नहीं है। एकमात्र मुद्दा संदेशों की उच्च बैंडविड्थ की तरह लगता है। आपके पास खरगोश की तरह एक पूरी तरह से नई प्रणाली को बनाए रखने के बजाय एक समर्पित पोस्टग्रेक्यूएल उदाहरण नहीं हो सकता है? आप 1) एक सिंगल PostgreSQL उदाहरण का उपयोग कर सकते हैं जब तक कि आप एक अड़चन तक नहीं पहुंचते हैं, तब 2) एक समर्पित पोस्टग्रेज का उपयोग करें, फिर अंत में 3) आसानी से अपने ब्रोकर के रूप में खरगोश पर स्विच करें। खरगोश के साथ शुरू होने जैसा लगता है पूर्व-अनुकूलन।

— जो '

Answer 2

PostgreSQL 9.5

PostgreSQL 9.5 शामिल है SELECT ... FOR UPDATE ... SKIP LOCKED। यह कार्यशील कतार प्रणाली को बहुत सरल और आसान बनाता है। अब आपको किसी बाहरी पंक्तिबद्ध प्रणाली की आवश्यकता नहीं हो सकती है क्योंकि अब 'n' पंक्तियों को प्राप्त करना सरल है जिसे किसी अन्य सत्र ने लॉक नहीं किया है, और जब तक आप यह पुष्टि नहीं कर लेते हैं कि काम पूरा हो चुका है, तब तक उन्हें लॉक रखें। यहां तक ​​कि बाहरी समन्वय के लिए दो-चरण के लेन-देन के साथ भी काम करना पड़ता है।

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

पुराने संस्करण

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

इसीलिए PGQ जैसे उपकरण मौजूद हैं।

आप का उपयोग करके PostgreSQL में मतदान से छुटकारा पा सकते LISTENहैं और NOTIFY, लेकिन, जबकि अत्यधिक समवर्ती ऑपरेशन के संरक्षण और आवेषण अवरुद्ध नहीं है कि ठीक एक उपभोक्ता के लिए कतार के ऊपर से बाहर प्रविष्टियों मज़बूती से सौंपने की समस्या का समाधान नहीं होगा। आपके द्वारा सोचा गया सभी सरल और स्पष्ट समाधान वास्तव में वास्तविक दुनिया में नहीं होने वाली समस्या को हल करेंगे, और एकल-कार्यकर्ता कतार लाने के कम कुशल संस्करणों में पतित होंगे।

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

Comments

रेखा reliably handing out entries off the top of the queue to exactly one consumer while preserving highly concurrent operation and not blocking inserts. इसे संक्षेप में बताती है - सही है?

— युगल जिंदल