We built a new DynamoDB cost analyzer that helps developers understand what their workloads will really cost DynamoDB izmaksas var būt jums blakus. Komandas regulāri saskaras ar "rēķinu šoku": tas krīt sajūta, kad jūs skatāties uz šokējoši augstu rēķinu un saprotat, ka neesat pievērsuši pietiekamu uzmanību savai lietošanai, jo īpaši ar pēc pieprasījuma cenu noteikšanu. Lai gan , tas bieži vien nepievērš uzmanību reālās pasaules darba slodzes niansēm (piemēram, plosītai satiksmei vai nevienmērīgiem piekļuves modeļiem, vai izmantojot globālās tabulas vai kešatmiņu). AWS piedāvā DynamoDB cenu kalkulatoru Mēs gribējām kaut ko labāku.Pēc pilnīgas pārredzamības mēs gribējām kaut ko labāku, lai palīdzētu komandām Tāpēc mēs izveidojām jaunu DynamoDB izmaksu kalkulatoru, kas palīdz izstrādātājiem saprast, ko viņu darba slodzes faktiski izmaksās.Neskatoties uz to, ka mēs to izstrādājām komandām, kas salīdzina DynamoDB ar ScyllaDB, mēs uzskatām, ka tas ir noderīgs ikvienam, kurš vēlas precīzāk novērtēt savas DynamoDB izmaksas, jebkura iemesla dēļ. ScyllaDB kā DynamoDB alternatīva kalkulators.scylladb.com tīmekļa vietne Kā mēs to izveidojām We wanted to build something that would work client side, without the need for any server components. It’s a simple JavaScript single page application that we currently host on GitHub pages. If you want to check out the source code, feel free to take a look at https://github.com/scylladb/calculator Lai būtu godīgi, strādājot ar piemēriem Tas bija mazliet murgs, un, kad jūs “parādāt aprēķinus”, jūs saņemsiet šādas teksta sienas: https://calculator.aws/ Es biju kārdināts veikt īsāku pieeju, piemēram: Mēneša WCU izmaksas = WCUs × Price_per_WCU_per_hour × 730 stundas mēnesī But every time I simplified this, I found it harder to get parity between what I calculated and the final price in AWS’s calculation. Sometimes the difference was due to rounding, other times it was due to the mixture of reserved + provision capacity, and so on. So to make it easier (for me) to debug, I faithfully followed their calculations line by line and tried to replicate this in my own rather ugly function: 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. Tātad tas dara darbu par On Demand, Provisioned (un rezervētiem) jaudas modeļiem. Ja esat izmantojis AWS kalkulatoru, jūs zināt, ka nevarat norādīt tādas lietas kā pīķa (vai pīķa platums) On Demand. es neesmu pārliecināts par to pamatojumu. 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. You’ll also notice that as you change the inputs, the URL query parameters change to reflect those inputs. That’s designed to make it easier to share and reference specific variations of costs. Tur ir dažas citas matemātikas, piemēram, noskaidrojot globālo tabulu patiesās izmaksas un izpratni par atvasinātajām izmaksām, piemēram, tīkla pārsūtīšanu vai DynamoDB Accelerator (DAX). 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. Explore “what if” scenarios for your own workloads Izmaksu analīze reālajā pasaulē Galīgais mērķis visu šo tinkering un pielāgošana ir palīdzēt jums izpētīt dažādus "kas-ja" scenārijus no DynamoDB izmaksu perspektīvas. My colleague Gui and I just got together for a deep dive into how factors like traffic surges, multi-datacenter expansion, and the introduction of caching (e.g., DAX) impact DynamoDB costs. We explored how a few (anonymized) teams we work with ended up blindsided by their DynamoDB bills and the various options they considered for getting costs back under control. Skatīties DynamoDB izmaksas čats tagad About 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.
