From inevitable overprovisioning to the “on-demand” tax: why DynamoDB is bloody hard to cost-control हाल में संभावित ScyllaDB ग्राहकों को DynamoDB चलाने की वास्तविक लागत को समझने में मदद करने के विशिष्ट लक्ष्य के साथ. अब, यदि आप एक कदम पीछे हटते हैं और मेरे लक्ष्य को देखते हैं, तो यह बहुत मायने नहीं रखता है, सही? DynamoDB लागत गणना बेवकूफ रूप से, मैं भी यही सोचता था, शुरुआत में. लेकिन फिर, मैंने DynamoDB लागत गणना के आंतरिक कामकाज को खोलना शुरू कर दिया. उस बिंदु पर, मुझे एहसास हुआ कि कई कारण हैं कि क्यों टीमें DynamoDB को बड़े पैमाने पर चलाने के लिए सैकड़ों हजारों (यदि लाखों नहीं) डॉलर का भुगतान करते हैं। मुख्य बात जो मैंने पाई है: DynamoDB को अपनाना आसान है, लेकिन लागत नियंत्रित करने के लिए खूनी कठिन है। मेरे कामकाज के साथी Guilherme और मैं , लेकिन यदि आपके पास देखने का समय नहीं है, तो मुख्य निष्कर्षों को खोजने के लिए पढ़ें। इन पंक्तियों के साथ एक वेबमिनार जारी किया गया पहली आम गलतफहमी यह है कि DynamoDB आपको क्या शुल्क देता है. आप शायद पहले से ही Read Capacity Units और Write Capacity Units जैसे शब्दों को सुन चुके हैं, और पढ़ने और लिखने की संख्या के संदर्भ में "आप जो उपयोग करते हैं उसके लिए भुगतान करते हैं" का जिक्र प्राप्त करते हैं. लेकिन आइए मूल बातें से शुरू करते हैं. DynamoDB लेखन महंगा है ... यदि आप देखते , आप देखेंगे कि एक पढ़ने के अनुरोध इकाई (आरआरयू) $ 0.125 प्रति मिलियन इकाइयों की लागत है, और एक लिखने के अनुरोध इकाई (डब्ल्यूआरयू) $ 0.625 प्रति मिलियन इकाइयों की लागत है. तो, लिखना पढ़ने की तुलना में 5 गुना अधिक महंगा है. मैं सटीक तकनीकी कारण नहीं जानता, लेकिन इसमें कोई संदेह नहीं है कि लिखने के पथ के साथ कुछ करना है अधिक भारी (बहुत लंबाई, स्थिरता, सूचकांकन आदि) और शायद कुछ हेडroom. 5x डेटाबेस के लिए धीरे-धीरे और लागत परिप्रेक्ष्य से पहले फ्लैट में से एक लग रहा है. आप आसानी से खुद को अधिक आकार का एक आदेश खर्च कर सकते हैं यदि अनुरोध पर क्षमता के लिए मूल्य निर्धारण जिसके बारे में बात करते हुए ... वहाँ दूसरा तरीका है: . जैसा कि नाम से पता चलता है, इसका मतलब है कि आप निर्दिष्ट कर सकते हैं कि आप कितना उपयोग करेंगे (यदि आप इसका उपयोग नहीं करेंगे), और उम्मीद है कि आप थोड़ा कम भुगतान करेंगे. हालांकि, अनुपात की जाँच करें. एक पढ़ने की क्षमता इकाई (आरसीयू) प्रति आरसीयू $0,00013 और एक लिखने की क्षमता इकाई (डब्ल्यूसीयू) $0,00065 की लागत है, इसलिए लिखना पढ़ने की तुलना में आश्चर्यजनक रूप से 5 गुना अधिक महंगा है। संभावित क्षमता आप अनुरोध प्रदान नहीं कर रहे हैं, आप दरें प्रदान कर रहे हैं ... यहां पकड़ है: प्रदान की गई क्षमता इकाइयों को प्रति सेकंड मापा जाता है, न कि प्रति मिलियन अनुरोध, जैसा कि on-demand में होता है। जिसने मुझे शुरुआत में पकड़ लिया. क्यों न सिर्फ अनुरोधों की कुल संख्या प्रदान करें? लेकिन एडब्ल्यूएस की परिप्रेक्ष्य से, यह एकदम सही व्यावसायिक अर्थ है. आप भुगतान कर रहे हैं प्रति सेकंड N ऑपरेशन, चाहे आप उस क्षमता का उपयोग करें या नहीं। संभालने की क्षमता इसलिए यदि आपका ट्रैफ़िक विस्फोट हुआ है, या आप अनुरोध ग्रोथिंग से बचने के लिए आपूर्ति कर रहे हैं (इस पर थोड़ी देर में अधिक), आप मूल रूप से बेकार क्षमता के लिए भुगतान कर रहे हैं। संभावित क्षमता... तो यहां सौदा है: यदि आप क्षमता आरक्षित करते हैं, तो आप थोड़ा बाद में बचत करने के लिए उम्मीद करते हैं। यदि आप अपनी मूल लाइन उपयोग में आश्वस्त हैं, तो एडब्ल्यूएस आपको DynamoDB क्षमता को आरक्षण करने का विकल्प देता है, जैसे कि EC2 या RDS के साथ। यह 1 या 3 साल की पूर्व-पैक प्रतिबद्धता है, जहां आप प्रति सेकंड एक निश्चित दर में पढ़ते हैं और लिखते हैं. और हाँ, यह अभी भी एक दर है, अनुरोधों की कुल संख्या नहीं। एक गोचिया: कोई आंशिक पूर्व विकल्प नहीं है; यह पूरी तरह से भुगतान करता है या दूर जाता है। आइए कीमत मॉडल की तुलना करने के लिए एक सरल उपयोग केस देखें ... एक घंटे के दौरान अपने कार्य भार के औसत 10,000 read/sec और 10,000 writes/sec कहते हैं। On-Demand की कीमतें : लेखन: $ 22.50 / घंटा ... 10,000 * 3600 * 0.625 / 1M पढ़ता है: $ 4.50 / घंटा ... 10,000 * 3600 * 0.125 / 1M (आमतौर पर लिखने की तुलना में 5x सस्ता) प्रावधानित मूल्य (निरपेक्ष नहीं): लेखन: $ 6.50 / घंटा ... 10,000 * $ 0.00065 पढ़ता है: $1.30 / घंटा ... 10,000 * $0.00013 1 वर्ष की अवधि के लिए आरक्षित: लेखन: ~ $ 2.99 / घंटा पढ़ाई: ~$0.59 / घंटा “हाय, आरक्षित गणित कहां है?” मैं आपको सुनता हूं। आप 100 WCUs ($ 0,0128 / घंटा) और RCUs ($ 0,0025 / घंटा) के लिए आरक्षित मूल्य निर्धारण लेते हैं, एक महीने में 730 घंटे से विभाजित करते हैं, एक वर्ष में 12 महीने से विभाजित करते हैं, फिर से 100 इकाइयों से विभाजित करते हैं, अपनी आवश्यक दर से गुणा करते हैं ... फिर इसे गोल करते हैं, थोड़ा रोते हैं, और "मैथेटी महिला" मेम में लगाते हैं। मेरा बिंदु है: Provisioned ~3.4x on-demand की तुलना में सस्ता आरक्षित है ~7.5x on-demand की तुलना में सस्ता अनुरोध पर उन लोगों के लिए है जो अधिक भुगतान करना पसंद करते हैं, या पूर्वानुमान से नफरत करते हैं बीटीवी, के लिए : AWS अनुरोध पर अनुशंसा करता है ट्रैफ़िक पैटर्न जो समय के साथ विकसित होते हैं Spiky या batchy कार्य भार कम उपयोग (शून्य या 30% से नीचे गिरावट) जो मूल रूप से हर वास्तविक जीवन कार्य भार है - कम से कम ScyllaDB के ग्राहकों के लिए। यह वस्तु का आकार नहीं है, लेकिन यह है ... यह एक ऐसा है जिसे आप तब तक नहीं हिट कर सकते हैं जब तक कि आप वास्तविक आवेदन डेटा का उपयोग न करें ... जिस बिंदु पर आप तुरंत इसे अनदेखा करने के लिए पछतावा करेंगे। DynamoDB में, आप केवल ऑपरेशन प्रति भुगतान नहीं करते हैं; आप स्थानांतरित डेटा के टुकड़े प्रति भुगतान करते हैं। Writes प्रति 1KB (Write Request Units या WRUs) की गणना की जाती है 4KB (Read Request Units या RRUs) तो यदि आप 1.1KB आइटम लिखते हैं, तो यह 2 WRUs है. 3KB आइटम लिखें? फिर भी 3 WRUs, प्रत्येक 1KB (या इसके हिस्से) को गिना जाता है। रीड्स समान तरीके से काम करते हैं, केवल 4KB सीमाओं पर। 1KB आइटम पढ़ें? 1 RRU. 4.1KB आइटम पढ़ें? यह 2 RRUs है। क्या यह मजेदार नहीं है? मुझे यकीन है कि इन सीमाओं के लिए मजबूत तकनीकी कारण हैं. आप यहां गड़बड़ी देख सकते हैं. इसे एक पढ़ने की तुलना में एक लिखने की लागत के 5x लागत के साथ जोड़ें, और चीजें जल्दी से खराब हो सकती हैं, खासकर अगर आपका आइटम आकार उन सीमाओं को पार करता है, जब तक कि आप इसे महसूस नहीं करते हैं। यह शायद ठीक है यदि आपके योजना में एक निश्चित आइटम आकार है, लेकिन निश्चित रूप से ScyllaDB पर हम देखते हैं कि उपयोग के प्रकार के मामलों के साथ ठीक नहीं है. उदाहरण के लिए, ग्राहकों को JSON या blob फ़ील्ड्स शामिल हो सकते हैं जो उपयोग के साथ कम या बढ़ सकते हैं. और याद रखें, यह वास्तविक आइटम आकार है, न केवल यह बहुत अधिक संवेदनशील है, क्योंकि आपको ... एक और दर्दनाक बिंदु, और एडब्ल्यूएस के स्वयं के कैलकुलेटर से विचलित अनुपस्थिति, प्रावधानित क्षमता का उपयोग करते समय अधिग्रहण करने की आवश्यकता है. यह विरोधाभासी लगता है, लेकिन आपको अधिग्रहण करने के लिए मजबूर किया जाता है - इसलिए नहीं क्योंकि आप चाहते हैं, लेकिन क्योंकि डायनामोडब्ल्यू आपको दंडित करता है यदि आप नहीं करते हैं. प्रावधानित मोड में, प्रत्येक अनुरोध सख्त प्रवाह सीमाओं के अधीन है क्योंकि, यदि आप पहले याद करते हैं, तो एक निश्चित दर वह है जो आप भुगतान कर रहे हैं। यदि आप प्रदान की गई क्षमता से परे स्लाइड करते हैं, तो आप मैं इस तरह के अपवाद संदेश की स्पष्टता से प्यार करता हूं. मुझे यह पसंद नहीं है कि यह वास्तव में क्या करता है, हालांकि: अनुरोध ग्रोटलिंग। यह अप्रयुक्त पढ़ने और लिखने की क्षमता को बनाए रखता है. लेकिन इसके अलावा, आपका ऐप बस विफल रहता है. अनुसूचित अनुसूचित अनुसूचित 300s विंडो विस्फोट क्षमता तो, इससे निपटने का सबसे अच्छा तरीका ओवरप्रोफ़िज़ेशन है. कितना? यह एक "यह निर्भर करता है" जवाब की गारंटी देता है. लेकिन यह आपके कार्य भार के प्रकार पर निर्भर करता है. हमने इस कार्यक्षमता को हमारे कैलकुलेटर में जोड़ा ताकि आप गतिशील रूप से एक प्रतिशत के साथ ओवरप्रोफ़िज़ेशन कर सकें, बस अपने कार्य भार के अतिरिक्त लागतों को गणना करने के लिए। आगे बढ़ने से पहले... यदि यहां एक पुनरावृत्ति थीम है, तो यह है: DynamoDB की कीमतें स्वाभाविक रूप से गलत नहीं हैं. आप जो आप उपयोग करते हैं उसके लिए भुगतान करते हैं. हालांकि, यह किसी भी कार्य भार के लिए विचित्र रूप से अपरिहार्य है जो एक आदर्श, पूर्वानुमान योग्य संवेदना की तरह नहीं दिखता है। चाहे वह हो: 5x लिखने की लागत गुणा 7.5x on-demand लागत गुणांक Opaque प्रति सेकंड निर्धारित दर आइटम आकार के दुरुस्त और कृत्रिम सीमाएं या सिर्फ पिक लोड के दौरान चेहरा लगाने से बचने के लिए अतिरिक्त आपूर्ति की आवश्यकता ...आप को लगातार अपनी वास्तुकला को दूसरी बार अनुमान लगाने की जरूरत है, बस लागत विस्फोटों से आगे रहने के लिए। विरोधाभास यह है कि DynamoDB को "सेवरलेस" और "पूर्ण रूप से प्रबंधित" के रूप में ब्रांडित किया गया है, लेकिन आप क्षमता गणित, ग्रोथलिंग त्रुटियों, अराजक मूल्य स्तरों, और अंतहीन पारगमन जिमस्टिस्टिक्स को प्रबंधित करते हैं। यही कारण है कि हमने एक कैलकुलेटर बनाया है जो वास्तविक कार्य भारों को मॉडलिंग करता है, न कि केवल औसत। में , मैं उन ग्राहकों के कुछ वास्तविक दुनिया के उदाहरणों के माध्यम से चलता हूं जिन्होंने ट्रैफ़िक पैटर्न, आइटम आकार, कैश और मल्टी-रेजी टोपोलॉजी के वास्तविक प्रभाव को दिखाने के लिए DynamoDB से ScyllaDB में स्विच किया। में . मेरा अगला ब्लॉग पोस्ट आगे बढ़ें और अपने स्वयं के कार्य भारों को मॉडल करें कैलकुलेटर.scylladb.com हमारे नए लागत कैलकुलेटर पर अपने स्वयं के DynamoDB कार्य भार मॉडल Tim Koopmans के बारे में टिम ने पिछले कुछ दशकों के लिए इंजीनियरिंग के सभी रूपों में हाथ रखे हैं, विश्वसनीयता और सुरक्षा के लिए एक प्रवृत्ति के साथ। 2013 में उन्होंने फ्लोड आईओ की स्थापना की; एक वितरित प्रदर्शन परीक्षण प्लेटफॉर्म।
