We built a new DynamoDB cost analyzer that helps developers understand what their workloads will really cost DynamoDB costs can blindside you. Teams regularly face “bill shock”: that sinking feeling when you look at a shockingly high bill and realize that you haven’t paid enough attention to your usage, especially with on-demand pricing. Provisioned capacity brings a different risk: performance. If you can’t accurately predict capacity or your math is off, requests get throttled. It’s a delicate balancing act. Although , it often misses the nuances of real-world workloads (e.g., bursty traffic or uneven access patterns, or using global tables or caching). AWS offers a DynamoDB pricing calculator Chtěli jsme něco lepšího.V plné transparentnosti jsme chtěli něco lepšího, abychom týmům pomohli zvážit . So we built a new DynamoDB cost calculator that helps developers understand what their workloads will really cost. Although we designed it for teams comparing DynamoDB with ScyllaDB, we believe it’s useful for anyone looking to more accurately estimate their DynamoDB costs, for any reason. You can see the live version at: ScyllaDB as a DynamoDB alternative calculator.scylladb.com How We Built It Chtěli jsme vytvořit něco, co by fungovalo na straně klienta, bez potřeby jakýchkoliv komponent serveru.Je to jednoduchá aplikace na jednu stránku JavaScript, kterou v současné době hostujeme na stránkách GitHub. https://github.com/scylladb/calculator To be honest, working with the examples at Byla to trochu noční můra, a když „ukážete výpočty“, dostanete tyto stěny textu: https://calculator.aws/ I was tempted to take a shorter approach, like: Monthly WCU Cost = WCUs × Price_per_WCU_per_hour × 730 hours/month Ale pokaždé, když jsem to zjednodušil, zjistil jsem, že je obtížnější získat paritu mezi tím, co jsem vypočítal a konečnou cenou v výpočtu AWS. Někdy byl rozdíl způsoben zaokrouhlením, jindy to bylo způsobeno směsí rezervované + kapacity pro poskytování, a tak dále. https://github.com/scylladb/calculator/blob/main/src/calculator.js I may still refactor this into smaller functions. But for now, I wanted to get parity between theirs and ours. You’ll see that there are also some end-to-end tests for these calculations — I use those to test for a bunch of different configurations. I will probably expand on these in time as well. So that gets the job done for On Demand, Provisioned (and Reserved) capacity models. If you’ve used AWS’s calculator, you know that you can’t specify things like a peak (or peak width) in On Demand. I’m not sure about their reasoning. I decided it would be easier for users to specify both the baseline and peak for reads and writes (respectively) in On Demand, much like Provisioned capacity. Another design decision was to represent the traffic using a chart. I do better with visuals, so seeing the peaks and troughs makes it easier for me to understand – and I hope it does for you as well. Také si všimnete, že při změně vstupů se parametry dotazu URL změní tak, aby odrážely tyto vstupy. Tam je nějaká jiná matematika, jako je zjištění skutečné náklady globálních tabulek a pochopení odvozených nákladů věcí, jako je přenos sítě nebo DynamoDB Accelerator (DAX). nicméně, vysvětlení všeho, co je trochu příliš husté pro tento formát. The good news is that you can estimate these costs in addition to your workload, as they can be big cost multipliers when planning out your usage of DynamoDB. Prozkoumejte scénáře „co když“ pro vlastní pracovní zatížení Analyzing Costs in Real-World Scenarios The ultimate goal of all this tinkering and tuning is to help you explore various “what-if” scenarios from a DynamoDB cost perspective. To get started, we’re sharing the cost impacts of some of the more interesting DynamoDB user scenarios we’ve come across at ScyllaDB. Můj kolega Gui a já jsme se právě spojili, abychom se hluboce ponořili do toho, jak faktory jako nárůst provozu, rozšíření více datových center a zavedení vyrovnávací paměti (např. DAX) ovlivňují náklady DynamoDB. Watch the DynamoDB costs chat now O společnosti Tim Koopmans Tim has had his hands in all forms of engineering for the past couple of decades with a penchant for reliability and security. In 2013 he founded Flood IO; a distributed performance testing platform. After it was acquired, he enjoyed scaling the product, business and team before moving on to other performance-related endeavors.
