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 Желимо нешто боље.У потпуној транспарентности, желимо нешто боље да помогнемо тимовима да размотре . 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 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 Да будем искрен, радити са примерима на was a bit of a nightmare, and when you “show calculations,” you get these walls of text: https://calculator.aws/ I was tempted to take a shorter approach, like: Mesečni WCU Troškovi = WCUs × Price_per_WCU_per_hour × 730 sati/mesec 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. So that gets the job done for On Demand, Provisioned (and Reserved) capacity models. Ако сте користили AWS калкулатор, знате да не можете да наведете ствари као што је врхунац (или ширина врха) у На захтев. нисам сигуран о њиховом размишљању. Одлучио сам да би било лакше за кориснике да наведете и базу и врхунац за читање и писање (одговарајуће) у На захтев, као и провизионисани капацитет. 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. There’s some other math in there, like figuring out the true cost of Global Tables and understanding derived costs of things like network transfer or DynamoDB Accelerator (DAX). However, explaining all that is a bit too dense for this format. We’ll talk more about that in an upcoming webinar (see the next section). 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. Истражите „шта ако“ сценарије за своје радне оптерећења Анализа трошкова у реалном свету сценарија Крајњи циљ свих ових подешавања и подешавања је да вам помогне да истражите различите сценарије "шта ако" из перспективе трошкова ДинамоДБ-а. Да бисте започели, делимо трошкове утицаја неких од занимљивијих сценарија корисника ДинамоДБ-а које смо наишли на СциллаДБ-у. Мој колега Гуи и ја смо се управо окупили за дубоко роњење у то како фактори као што су раст саобраћаја, експанзија мулти-датцентара и увођење кеширања (нпр. DAX) утичу на трошкове ДинамоДБ-а.Истражили смо како су неколико (анонимизованих) тимова са којима радимо завршили заслепљени својим ДинамоДБ рачунима и разним опцијама које су разматрали како би повратили трошкове. Watch the DynamoDB costs chat now Тим Коопманс Тим је имао руке у свим облицима инжењеринга у протеклих неколико деценија са склоношћу за поузданост и сигурност. 2013. године основао је Флоод ИО; дистрибуирану платформу за тестирање перформанси. Након што је стечен, уживао је у скалирању производа, бизниса и тима пре него што се преселио на друге напоре везане за перформансе.
