मुझे अमेजन किनिस का इस्तेमाल क्यों करना चाहिए और एसएनएस-एसक्यूएस का नहीं?

164

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

amazon-web-services  amazon-sqs  amazon-kinesis 
— अपूर्व
स्रोत

जवाबों:

59

सतह पर वे अस्पष्ट रूप से समान हैं, लेकिन आपका उपयोग मामला निर्धारित करेगा कि कौन सा उपकरण उपयुक्त है। IMO, यदि आप SQS से प्राप्त कर सकते हैं तो आपको चाहिए - यदि यह वही करेगा जो आप चाहते हैं, तो यह सरल और सस्ता होगा, लेकिन यहाँ AWS FAQ से बेहतर विवरण दिया गया है जो दोनों उपकरणों के लिए उपयुक्त उपयोग-मामलों का उदाहरण देता है निर्णय लेने में आपकी सहायता करें:

पूछे जाने वाले प्रश्न के

— ईजे ब्रेनन
स्रोत
7
FYI करें docs.aws.amazon.com/AWSSimpleQueueService/latest/… SQS FIFO SNS के साथ काम नहीं करता है
— सब कुछ नष्ट कर
80

ध्यान रहे यह उत्तर जून 2015 के लिए सही था

कुछ समय के लिए समस्या का अध्ययन करने के बाद, उसी प्रश्न को ध्यान में रखते हुए, मैंने पाया कि SQS (SNS के साथ) को सबसे अधिक उपयोग के मामलों के लिए पसंद किया जाता है जब तक कि संदेशों का क्रम आपके लिए महत्वपूर्ण नहीं होता (SQS संदेशों पर FIFO की गारंटी नहीं देता)।

Kinesis के 2 मुख्य लाभ हैं:

  1. आप कई अनुप्रयोगों से एक ही संदेश पढ़ सकते हैं
  2. यदि आपको आवश्यक हो तो आप संदेशों को फिर से पढ़ सकते हैं।

SQS के प्रशंसक के रूप में SNS का उपयोग करके दोनों लाभ प्राप्त किए जा सकते हैं। इसका मतलब है कि संदेश का निर्माता एसएनएस को केवल एक संदेश भेजता है, फिर एसएनएस प्रशंसकों को कई एसक्यूएस के लिए संदेश भेजता है, प्रत्येक उपभोक्ता आवेदन के लिए। इस तरह से आपके पास उतने उपभोक्ता हो सकते हैं, जितने आप शार्पिंग क्षमता के बारे में सोचे बिना चाहते हैं।

इसके अलावा, हमने एक और SQS जोड़ा जो SNS की सदस्यता लेता है जो 14 दिनों के लिए संदेश रखेगा। सामान्य स्थिति में कोई भी इस SQS से नहीं पढ़ता है, लेकिन बग के मामले में, जो हमें उस डेटा को रिवाइंड करना चाहता है जिससे हम इस SQS के सभी संदेशों को आसानी से पढ़ सकते हैं और उन्हें SNS में पुनः भेज सकते हैं। जबकि काइनिस केवल 7 दिनों का प्रतिधारण प्रदान करता है।

निष्कर्ष में, SNS + SQS बहुत आसान है और अधिकांश क्षमताओं को प्रदान करता है। IMO आपको उस पर काइनेसिस चुनने के लिए वास्तव में मजबूत मामले की आवश्यकता है।

— रोई गवरिएल
स्रोत
2
FYI करें: आप Kinesis को 7 दिनों तक बनाए रख सकते हैं।
— डिडियर ए।
30
हाल ही में, AWS ने SQS FIFO [ docs.aws.amazon.com/AWSSimpleQueueService/latest/… की घोषणा की है जो संदेशों के समय-क्रम की सेवा कर सकते हैं।
— विजेशजैन
4
सुपर नाबालिग टिप्पणी - शायद शब्द का उपयोग नहीं होता splitमें SNS split the message to multiple SQSsके बाद से यह टुकड़े, लेकिन यह आपको अनेक स्थानों पर प्रतियों में संदेशों नष्ट नहीं होती है।
— मोबिजिटल
2
पाठकों के प्रति शर्ड / सेकंड की संख्या के आसपास सीमाओं के कारण काइनिस फैन-आउट (पब-उप) उपयोग के मामलों के लिए अनुपयुक्त है। मूल पूछताछ के लिए प्रासंगिक नहीं होने के बावजूद, K- पाठकों पर भरोसा करने वाले किसी भी व्यक्ति को इस तथ्य को ध्यान में रखना चाहिए। forum.aws.amazon.com/message.jspa?messageID=760351
— कोडीनोन
2
काइनिस की ऑर्डर गारंटी प्रति-शार्प है, प्रति-स्ट्रीम नहीं। एक बार आपके पास एक से अधिक शार्क होने पर, पूरी स्ट्रीम के ऑर्डर की कोई गारंटी नहीं होगी। एक SQS कतार के लिए, जब थ्रूपुट अपेक्षाकृत कम होता है, तो यह लगभग फीफो होता है। केवल जब आपका थ्रूपुट अधिक होता है, तो आदेश का पालन कम होता है। यह क्लासिक SQS कतारों के बारे में है, न कि FIFO कतारों के बारे में।
— योरोटो 22
54

काइनिस कई उपभोक्ताओं की क्षमताओं का समर्थन करता है, जिसका अर्थ है कि एक ही डेटा रिकॉर्ड एक ही समय या अलग-अलग समय पर 24 घंटे के भीतर अलग-अलग उपभोक्ताओं पर संसाधित किया जा सकता है, एसक्यूएस में समान व्यवहार कई कतारों में लिखकर प्राप्त किया जा सकता है और उपभोक्ता कई कतारों से पढ़ सकते हैं। हालाँकि फिर से कई कतार में लिखने से उप सेकंड {कुछ मिलीसेकंड} सिस्टम में विलंबता जुड़ जाएगी।

दूसरा, किनिस विभाजन विभाजन कुंजी का उपयोग करके चुनिंदा मार्ग डेटा रिकॉर्ड के लिए रूटिंग क्षमता प्रदान करता है जिसे विशेष EC2 उदाहरणों द्वारा संसाधित किया जा सकता है और सूक्ष्म बैच गणना {काउंटिंग और एकत्रीकरण} को सक्षम कर सकता है।

किसी भी एडब्ल्यूएस सॉफ्टवेयर पर काम करना आसान है लेकिन एसक्यूएस के साथ यह सबसे आसान है। Kinesis के साथ, समय से पहले पर्याप्त मात्रा में शार्क को व्यवस्थित करने की आवश्यकता है, स्पाइक लोड को प्रबंधित करने के लिए गतिशील रूप से बढ़ती संख्या और प्रबंधन करने के लिए आवश्यक लागत को बचाने के लिए कमी। किनेसिस में दर्द होता है, एसक्यूएस के साथ ऐसी चीजों की आवश्यकता नहीं होती है। SQS असीम रूप से स्केलेबल है।

— कार्तिक
स्रोत
11
SQS पर आपके बारे में स्पष्टीकरण। आप उनके समक्ष एक SNS करके कई SQS को एक ही संदेश भेजने का एक आसान तरीका प्राप्त कर सकते हैं।
— रोई गेवरेल
8
ऐप -> एसएनएस विषय ---> sqs1, sqs2, sqs3 ...?
— कार्तिक
4
हां, मैं बिल्कुल इसी दृष्टिकोण का जिक्र कर रहा था।
— रोई गेवरेल
@RoeeGavirel एसपीएस एपी के लिए अनुरोध / दूसरी सीमाओं के बारे में क्या?
— बारब्रोस अल्प
@BarbarosAlp - मुझे केवल एसएमएस (मोबाइल पाठ संदेश) सीमा के बारे में पता है जो यहाँ विषय से दूर है। यह आधिकारिक दस्तावेज है: docs.aws.amazon.com/general/latest/gr/…
— Roee Gavirel
43

इन तकनीकों के शब्दार्थ अलग-अलग हैं क्योंकि वे विभिन्न परिदृश्यों का समर्थन करने के लिए डिज़ाइन किए गए थे:

  • SNS / SQS: स्ट्रीम में आइटम एक दूसरे से संबंधित नहीं हैं
  • किनिस: धारा में आइटम एक दूसरे से संबंधित हैं

आइए उदाहरण के द्वारा अंतर को समझते हैं।

  1. मान लीजिए कि हमारे पास आदेशों की एक धारा है, प्रत्येक आदेश के लिए हमें कुछ स्टॉक आरक्षित करने और डिलीवरी शेड्यूल करने की आवश्यकता है। एक बार यह पूरा हो जाने पर, हम आइटम को सुरक्षित रूप से स्ट्रीम से हटा सकते हैं और अगले ऑर्डर को संसाधित करना शुरू कर सकते हैं। हम पूरी तरह से कर रहे हैं किया पिछले आदेश के साथ इससे पहले कि हम अगले एक शुरू करते हैं।
  2. फिर से, हमारे पास आदेशों की एक ही धारा है, लेकिन अब हमारा लक्ष्य गंतव्यों द्वारा आदेशों का समूह बनाना है। एक बार जब हम कहते हैं, एक ही स्थान पर 10 आदेश, हम उन्हें एक साथ वितरित करना चाहते हैं (वितरण अनुकूलन)। अब कहानी अलग है: जब हम धारा से एक नया आइटम प्राप्त करते हैं, तो हम इसे संसाधित नहीं कर सकते हैं; बल्कि हम अपने लक्ष्य को पूरा करने के लिए और अधिक वस्तुओं के आने की "प्रतीक्षा" करते हैं। इसके अलावा, यदि प्रोसेसर प्रक्रिया क्रैश हो जाती है, तो हमें राज्य को "पुनर्स्थापित" करना होगा (ताकि कोई आदेश न खो जाए)।

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

— कॉन्स्टेंटिन ट्राइगर
स्रोत
SQS FIFO कतार के साथ, हमारे पास भेजे गए संदेशों के रूप में आदेश दिए जाएंगे। क्या इस पहलू पर एसक्यूएस किनिस के समान है?
— एंडी डुफ्रेसने
1
@AndyDufresne: यह उस परिदृश्य को अच्छी तरह से कवर करता है जहां ऑर्डर महत्वपूर्ण है। उपरोक्त मामले में (1), आप "ऑर्डर में" ऑर्डर संभालना चाह सकते हैं। इसलिए यदि आप स्टॉक से बाहर निकलते हैं, तो बाद में ऑर्डर खारिज या विलंबित हो जाते हैं। FIFO शब्दार्थ मूल सापेक्षता (समूहन) समस्या का समाधान नहीं करता है।
— कॉन्सटेंटिन ट्राइगर
35

AWS डॉक्यूमेंटेशन के कुछ अंश :

हम निम्नलिखित के समान आवश्यकताओं वाले मामलों के उपयोग के लिए Amazon Kinesis स्ट्रीम की सलाह देते हैं:

  • संबंधित रिकॉर्ड को एक ही रिकॉर्ड प्रोसेसर पर (जैसा कि MapReduce स्ट्रीमिंग में)। उदाहरण के लिए, गिनती और एकत्रीकरण सरल है जब किसी दिए गए कुंजी के सभी रिकॉर्ड एक ही रिकॉर्ड प्रोसेसर पर रूट किए जाते हैं।

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

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

  • कुछ घंटों बाद उसी क्रम में रिकॉर्ड का उपभोग करने की क्षमता। उदाहरण के लिए, आपके पास बिलिंग एप्लिकेशन और एक ऑडिट एप्लिकेशन है जो बिलिंग एप्लिकेशन से कुछ घंटे पहले चलती है। क्योंकि Amazon Kinesis Streams 7 दिनों तक के लिए डेटा स्टोर करता है, आप बिलिंग एप्लिकेशन के 7 दिन पहले तक ऑडिट एप्लिकेशन चला सकते हैं।

हम निम्नलिखित के समान आवश्यकताओं वाले मामलों के उपयोग के लिए Amazon SQS की सलाह देते हैं:

  • मैसेजिंग शब्दार्थ (जैसे संदेश-स्तर ack / fail) और दृश्यता का समय। उदाहरण के लिए, आपके पास काम की वस्तुओं की कतार है और स्वतंत्र रूप से प्रत्येक आइटम के सफल समापन को ट्रैक करना चाहते हैं। अमेज़न SQS ack / fail को ट्रैक करता है, इसलिए एप्लिकेशन को लगातार चेकपॉइंट / कर्सर को बनाए रखने की आवश्यकता नहीं है। अमेज़ॅन SQS एक कॉन्फ़िगर दृश्यता समय समाप्त होने के बाद प्रसारित संदेशों को हटा देगा और विफल संदेशों को फिर से प्रकाशित करेगा।

  • व्यक्तिगत संदेश देरी। उदाहरण के लिए, आपके पास एक नौकरी की कतार है और एक देरी के साथ व्यक्तिगत नौकरियों को शेड्यूल करने की आवश्यकता है। अमेज़ॅन एसक्यूएस के साथ, आप 15 मिनट तक की देरी के लिए व्यक्तिगत संदेशों को कॉन्फ़िगर कर सकते हैं।

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

  • पारदर्शी रूप से पैमाने पर करने की अमेज़न SQS की क्षमता का लाभ उठाना। उदाहरण के लिए, आप कभी-कभी लोड स्पाइक्स या आपके व्यवसाय की प्राकृतिक वृद्धि के परिणामस्वरूप अनुरोधों को बफर करते हैं और लोड बदल जाता है। क्योंकि प्रत्येक बफ़र किए गए अनुरोध को स्वतंत्र रूप से संसाधित किया जा सकता है, इसलिए अमेज़ॅन एसक्यूएस पारदर्शी रूप से आपके द्वारा किसी भी प्रावधान के निर्देशों के बिना लोड को संभालने के लिए स्केल कर सकता है।

— cloudtechnician
स्रोत
34

मेरे लिए सबसे बड़ा फायदा यह है कि किनेसिस एक रिप्लेसेबल कतार है, और एसक्यूएस नहीं है। तो आपके पास Kinesis (या अलग-अलग समय में एक ही उपभोक्ता) के एक ही संदेश के कई उपभोक्ता हो सकते हैं, जहां SQS के साथ, एक बार संदेश ack'd हो जाने के बाद, वह उस कतार से चला जाता है। एसक्यूएस उस वजह से श्रमिक कतारों के लिए बेहतर है।

— मैथ्यू करी
स्रोत
आप संदेश कैसे भेज सकते हैं? क्या आपका मतलब था डिलीट?
— NeverEndingQueue
हाँ, अनिवार्य रूप से। यह कहते हुए कि आप इस संदेश के साथ कर रहे हैं
— मैथ्यू करी
15

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

संपादित करें: यह उत्तर अब सही नहीं है। SQS सीधे लैम्बडा को जून 2018 तक ट्रिगर कर सकता है

https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html

— DenNukem
स्रोत
1
-1 असहमत। हालांकि काइन्सिस लैम्ब्डा को ट्रिगर कर सकता है, लेकिन शेड शेड्यूल्ड लैम्ब्डा पर इसका कोई फायदा नहीं है। उत्तरार्द्ध मूल रूप से पैमाने पर होगा (यानी अगर एक मिनट से अधिक समय लगता है तो एक दूसरा लंबोदर उछल जाएगा)। मूल्य प्रति गणना समय है इसलिए कोई प्रशंसनीय अंतर नहीं है। और अगर आपको 5 से अधिक समवर्ती लैंबडास की आवश्यकता है, तो बस कुछ सेकंड के अलावा अनुसूचित कई ट्रिगर्स जोड़ें (क्रोन का उपयोग करके)। यह SNS / SQS पर Kinesis का उपयोग करने का एक कारण नहीं है।
— स्टीवन डी सालास
5
मुझे यकीन नहीं है कि मैं असहमति से सहमत हूं;] - आप एक लैम्ब्डा / मिनट का समय निर्धारित कर सकते हैं, जो आपको उन संदेशों को बैचने की प्रक्रिया को सीमित कर देगा जो उस अंतराल में आए थे। Kinesis आपको संदेशों को तुरंत पढ़ने की अनुमति देगा। या कुछ मैं गलत समझा हूँ?
— मोसजी
SQS के खिलाफ खींचने वाले भेड़ के बच्चे को आह्वान करने की आवश्यकता होने पर क्लाउडवॉच ट्रिगर करने वाले और सैकड़ों के बीच एक बड़ा अंतर है।
— पिग
14
लैंबडा अब ट्रिगर के रूप में SQS का समर्थन करता है!
— साठ4
11

मूल्य निर्धारण मॉडल अलग-अलग हैं, इसलिए आपके उपयोग के मामले के आधार पर एक या दूसरे सस्ता हो सकता है। सरलतम मामले का उपयोग करना (SNS सहित नहीं):

  • संदेश प्रति SQS शुल्क (प्रत्येक 64 केबी एक अनुरोध के रूप में गिना जाता है)।
  • किन्सिस प्रति घंटे प्रति शर्ड चार्ज (1 शर्ड 1000 मैसेज या 1 एमबी / सेकेंड तक संभाल सकता है) और साथ ही आपके द्वारा (हर 25 केबी) में डाले जाने वाले डेटा की मात्रा के लिए भी।

वर्तमान कीमतों में प्लगिंग और फ्री टियर को ध्यान में न रखते हुए, यदि आप अधिकतम संदेश आकार में प्रति दिन 1 जीबी संदेश भेजते हैं, तो किनेसिस SQS (Kinesis के लिए $ 10.82 / महीना / SQS के लिए $ 0.20 / माह से अधिक) खर्च करेगा। । लेकिन अगर आप प्रति दिन 1 टीबी भेजते हैं, तो किनेसिस कुछ हद तक सस्ता है (एसक्यूएस के लिए $ 158 / माह बनाम $ 201 / महीना)।

विवरण: SQS $ 0.40 प्रति मिलियन अनुरोध (64 KB प्रत्येक), इसलिए $ 0.00655 प्रति GB का शुल्क लेता है। प्रति दिन 1 जीबी पर, यह प्रति माह केवल 0.20 डॉलर से कम है; प्रति दिन 1 टीबी, यह प्रति माह $ 201 से थोड़ा अधिक आता है।

Kinesis $ 0.014 प्रति मिलियन अनुरोध (25 KB प्रत्येक) का शुल्क लेता है, इसलिए $ 0.00059 प्रति GB है। 1 जीबी प्रति दिन, यह प्रति माह $ 0.02 से कम है; 1 टीबी प्रति दिन, यह लगभग $ 18 प्रति माह है। हालांकि, किनिस प्रति घंटे-प्रति घंटे 0.015 डॉलर चार्ज करता है। आपको प्रति सेकंड कम से कम 1 शार्क प्रति 1 एमबी की आवश्यकता है। प्रति दिन 1 जीबी पर, 1 शार्प काफी होगा, जिससे प्रति दिन $ 10.82 की कुल लागत के लिए प्रति दिन एक और $ 0.36 जुड़ जाएगा। 1 टीबी प्रति दिन, आपको कम से कम 13 शार्क की आवश्यकता होगी, जो प्रति माह $ 158 की लागत के लिए प्रति दिन एक और $ 4.68 जोड़ता है।

— जॉन वेलोनिस
स्रोत
मैं इस बात का पूरी तरह पालन नहीं करता कि घातीय वृद्धि आकार, यहाँ, मामलों में क्यों होती है। क्या आप थोड़ा और खोद सकते हैं? ऐसा लगता है कि आपको कुछ अंतर्दृष्टि मिली है, जो मैं करना चाहता हूं। वास्तव में संपादित करें , यूजीन फ़िंगोल्ड के जवाब को देखते हुए, इस (?) पर एक बहुत ठोस बहस होने लगती है।
— थॉमस
क्षमा करें, मैंने अपनी गणना में कुछ गलतियाँ की हैं (अब मुझे उम्मीद है)।
— जॉन वेलोनिस
सही है, लेकिन क्या होगा यदि आपका औसत SQS संदेश का आकार छोटा है, 1kb या कम कहें?
— mcmillab
1
@mcmillab SQS वही शुल्क लेगा जो आपका संदेश 1 KB या 64 KB है - अमेज़न का SQS मूल्य पृष्ठ देखें । इसलिए यदि आपके संदेश केवल 1 केबी के हैं, तो एसक्यूएस की लागत 64x होगी, जो मैंने ऊपर दिए गए आंकड़ों के समान है यदि आप समान कुल डेटा भेज रहे हैं। हालाँकि, एक एकल अनुरोध में 10 संदेश शामिल हो सकते हैं, इसलिए यदि आप संदेशों को एक साथ बैचने में सक्षम हैं, तो यह केवल 6x जितना हो सकता है (यह निर्भर करता है कि आपके बैच कितने पूर्ण हैं)।
— जॉन वेलोनिस
1
SJS मूल्य निर्धारण के लिए @JohnVelonis उपरोक्त गणना एक महत्वपूर्ण टुकड़ा गायब है। एसक्यूएस अनुरोधों को कैसे चार्ज किया जाता है, यह समझने के लिए अतिरिक्त देखभाल की आवश्यकता है। 1 अनुरोध = 1 एपीआई एक्शन। एक एकल "संदेश" को संसाधित करने के लिए, कम से कम 3 एपीआई क्रियाएं करने के लिए आवश्यक है: 1 भेजें + 1 पढ़ा + 1 हटाएं। अन्य SQS सुविधाएँ जैसे दृश्यता बदलना अधिक API क्रियाओं को प्रेरित करेगा। यह अप्रत्याशित गुणक काफी बुरा है और आमतौर पर SQS में परिणाम बड़े डेटा सेट के लिए Kinesis धाराओं की तुलना में 2-10x अधिक महंगा होता है (प्रति माह 100 मिलियन संदेशों को संसाधित करना)।
— व्लाद पॉस्चेचेव
9

Kinesis स्ट्रीमिंग डेटा के लिए एक विशिष्ट मानचित्र-कम परिदृश्य में मानचित्र भाग की समस्या को हल करता है। जबकि SQS यह सुनिश्चित नहीं करता है। यदि आपके पास स्ट्रीमिंग डेटा है जिसे एक कुंजी पर एकत्र करने की आवश्यकता है, तो kinesis यह सुनिश्चित करता है कि उस कुंजी का सारा डेटा एक विशिष्ट शार्द पर जाता है और SQ की तुलना में कुंजी को एकल होस्ट पर शार्क का उपभोग किया जा सकता है।

— भानु तडेपल्ली
स्रोत
5

मैं एक और बात जोड़ूंगा, जिसका किसी और ने उल्लेख नहीं किया है - SQS परिमाण के कई आदेश अधिक महंगे हैं।

— यूजीन फीगोल्ड
स्रोत
3
क्या आपको यकीन है? मेरी गणना से किनेसिस बहुत अधिक महंगा है, लेकिन मैं अमेज़ॅन सरल मूल्य कैलकुलेटर का उपयोग करके कभी भी प्रतिभाशाली नहीं रहा हूं।
— डिडियर ए।
Aws पर वर्तमान मूल्य निर्धारण उदाहरणों को देखते हुए: 267M संदेशों के साथ Kinesis 60 डॉलर के आसपास है, जबकि SQS के माध्यम से संदेशों की उस राशि को डालने पर $ 107 का परिणाम होगा। जाहिर है कि मैंने वास्तव में त्वरित तुलना की थी, और यह अत्यधिक उपयोग के मामलों के साथ भिन्न है, लेकिन इस उत्तर को निश्चित रूप से कुछ क्रेडिट के लायक होना चाहिए।
— मोसजी
1
मान लें कि आप 2 उपभोक्ताओं और एक दिन में 100 मिलियन संदेश कहने के लिए एक प्रशंसक बना रहे हैं। एसएनएस की लागत $ 50 / दिन है। SQS की लागत $ 40 / दिन / उपभोक्ता या $ 80 / दिन कुल है। KUTIS PUTs के लिए $ 1.4 / दिन और $ 0.36 / शार्क है। यहां तक ​​कि 100 शार्क (100 एमबी / एस, 200 एमबी / एस आउट) के साथ यह सिर्फ $ 3.60 / दिन + $ 1.40 / दिन है। तो Kinesis $ 4 / दिन बनाम SNS / SQS $ 130 / दिन पर।
— कार्लोस रेंडन
@Moszi इस गणना पर आप कैसे पहुंचे? प्रति माह 15,000,000 संदेशों के साथ एक मानक SQS कतार और 10GB डेटा ट्रांसफर में डेटा ट्रांसफर की लागत केवल एक औसत रूप से 5.60USD / मो होती है, जबकि 256KB पेलोड (SQS अधिकतम) और ~ 15,000,000 PUT यूनिट्स (mo (130 shards)) काइनिस में 1,638.43 खर्च होते हैं। अमरीकी डालर / मो।
— सिमोनकपु
3
मुझे यह जानने में दिलचस्पी होगी कि इस थ्रेड में लागतों में इतनी असमानता क्यों है।
— थॉमस
2

Kinesis उपयोग मामलों

  • लॉग और इवेंट डेटा संग्रह
  • वास्तविक समय विश्लेषिकी
  • मोबाइल डेटा कैप्चर
  • "इंटरनेट ऑफ़ थिंग्स" डाटा फीड

SQS उपयोग के मामले

  • अनुप्रयोग एकीकरण
  • माइक्रोसर्विसस को कम करना
  • एकाधिक कार्यकर्ता नोड्स को कार्य आवंटित करें
  • गहन बैकग्राउंड वर्क से उपयोगकर्ता के अनुरोध को कम करें
  • भविष्य के प्रसंस्करण के लिए बैच संदेश
— शरबील हमदान
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.