क्या एस 3 स्केलिंग की सीमाएं ज्ञात हैं? किसी ने कभी भी इतने सारे पढ़े या लिखते हैं कि एक बाल्टी ने त्रुटियों को वापस करना शुरू कर दिया है? मैं पढ़ने से लिखने में थोड़ा अधिक दिलचस्पी लेता हूं क्योंकि एस 3 को पढ़ने के लिए अनुकूलित किया जा सकता है।क्या कोई भी कभी भी अमेज़ॅन एस 3 बाल्टी के लिए ऊपरी बाउंड पढ़ने या लिखने पर पहुंच गया है?
एरिक की टिप्पणी, पहले से ही यह योग एक वैचारिक स्तर पर पूछे जाने वाले प्रश्न What happens if traffic from my application suddenly spikes? में संबोधित करने के साथ ही:
अमेज़न S3 जमीन से डिजाइन किया गया था किसी भी इंटरनेट अनुप्रयोग के लिए यातायात को संभालने के लिए। [...] अमेज़ॅन एस 3 का बड़े पैमाने पर हमें प्रसार भार को समान रूप से सक्षम बनाता है, ताकि कोई व्यक्तिगत एप्लिकेशन यातायात स्पाइक से प्रभावित न हो।
बेशक, आप अभी भी बार-बार मंदी त्रुटियों (Amazon S3 Error Best Practices देखें) के लिए संभावित समस्याओं और ट्यून [अपने] ऐप्लिकेशन के लिए खाते में करने की जरूरत है:
किसी भी वितरित प्रणाली साथ के रूप में, S3 है सुरक्षा तंत्र जो जानबूझकर या अनजाने संसाधन ओवर-खपत का पता लगाते हैं और तदनुसार प्रतिक्रिया करते हैं। स्लोडाउन त्रुटियां तब हो सकती हैं जब उच्च अनुरोध दर इन तंत्रों में से किसी एक को ट्रिगर करती है। आपकी अनुरोध दर को कम करने से इस प्रकार की त्रुटियों को कम या खत्म कर देगा। आम तौर पर, अधिकांश उपयोगकर्ता नियमित रूप से इन त्रुटियों का अनुभव नहीं करेंगे; हालांकि, आप अधिक जानकारी चाहते हैं या उच्च या अप्रत्याशित मंदी की समस्याएं आ रहे हैं, हमारे अमेज़न S3 डेवलपर फ़ोरम http://developer.amazonwebservices.com/connect/forum.jspa?forumID=24 को पोस्ट करने या एडब्ल्यूएस प्रीमियम सहायता http://aws.amazon.com/premiumsupport/ के लिए साइन अप करें। - [जोर मेरा]
जबकि दुर्लभ, इन धीमी चढ़ाव निश्चित रूप से होता है यहाँ एक AWS team response मुद्दा (सुंदर हालांकि दिनांकित) को दर्शाता हुआ है:
अमेज़न S3 इस त्रुटि वापस आ जाएगी जब अनुरोध दर पर्याप्त है जो अनुरोधों की सेवा करने से अन्य ग्राहकों के लिए अपर्याप्त सेवा होगी। यह त्रुटि बहुत ही कम हो गई है। यदि आपको प्राप्त होता है, तो आपको को तेजी से वापस लेना चाहिए। यदि यह त्रुटि होती है, तो सिस्टम संसाधनों को उच्च अनुरोध दर को बेहतर समर्थन देने के लिए प्रतिक्रियात्मक रूप से पुनर्वितरित/आवंटित किया जाएगा। नतीजतन, समय अवधि जिसके दौरान यह त्रुटि फेंक दी जाएगी अपेक्षाकृत कम होना चाहिए। [जोर मेरा]
के बारे में बनाम लिखने अनुकूलन पढ़ आपका धारणा वहाँ रूप में अच्छी तरह की पुष्टि की है:
सीमा जहां इस त्रुटि भिन्न trigged जाता है और निर्भर करेगा, भाग में, पर अनुरोध प्रकार और पैटर्न। आम तौर पर, आप प्राप्त कर सकते हैं जिसमें बनाम बनाम के साथ उच्च आरपीएस प्राप्त होते हैं और के लिए बहुत सारी चीजें मिलती हैं, कुंजियों की छोटी संख्या बनाम बहुत बड़ी चाबियाँ होती हैं। जब geting या कुंजियों की एक बड़ी संख्या डाल आप उच्च आर पी एस प्राप्त करने के लिए करता है, तो कुंजी अल्फान्यूमेरिक आदेश बनाम यादृच्छिक में हैं सक्षम हो जाएगा/टुकड़ों में बांटा आदेश।
अमेज़ॅन एस 3 प्रति सेकेंड हजारों अनुरोधों को संसाधित करता है (http://aws.typepad.com/aws/amazon_s3/)। बाल्टी प्रति वस्तुओं की संख्या पर कोई सीमा नहीं है, इसलिए मुझे शक है बाल्टी स्तर पर किसी भी संगामिति सीमा नहीं है। –
FYI करें, मैं सिर्फ 10 लाख से अधिक फ़ाइलों को कम से कम 15 दिनों में अपलोड कर दिया है, 30 समवर्ती धागे के साथ। किसी भी सीमा/समस्या का सामना नहीं किया। – Benjamin