We built a new DynamoDB cost analyzer that helps developers understand what their workloads will really cost Koszty DynamoDB mogą cię zaskoczyć. zespoły regularnie borykają się z „szokiem rachunku”: to osłabiające uczucie, gdy patrzysz na szokująco wysoki rachunek i zdajesz sobie sprawę, że nie zwróciłeś wystarczającej uwagi na swoje użytkowanie, zwłaszcza przy ustalaniu cen na żądanie. Chociaż , często pomija niuanse rzeczywistych obciążeń roboczych (np. wybuchowy ruch lub nierówne wzorce dostępu, lub korzystanie z globalnych tabel lub pamięci podręcznej). AWS oferuje kalkulator cenowy DynamoDB Chcieliśmy czegoś lepszego.W pełnej przejrzystości chcieliśmy czegoś lepszego, aby pomóc zespołom rozważyć Tak więc zbudowaliśmy nowy kalkulator kosztów DynamoDB, który pomaga deweloperom zrozumieć, ile ich obciążenia pracy naprawdę będą kosztować. Chociaż zaprojektowaliśmy go dla zespołów porównujących DynamoDB z ScyllaDB, uważamy, że jest to przydatne dla każdego, kto chce bardziej precyzyjnie oszacować koszty DynamoDB, z dowolnego powodu. ScyllaDB jako alternatywa dla DynamoDB kalkulator.scylladb.com Jak go zbudowaliśmy Chcieliśmy zbudować coś, co działałoby po stronie klienta, bez potrzeby żadnych komponentów serwera. Jest to prosta aplikacja JavaScript na jednej stronie, którą obecnie hostojemy na stronach GitHub. https://github.com/scylladb/calculator Aby być szczerym, pracując z przykładami na Był to trochę koszmar, a kiedy „wyświetlasz obliczenia”, otrzymasz te ściany tekstu: https://calculator.aws/ Byłem skłonny podjąć krótsze podejście, takie jak: Miesięczny koszt WCU = WCUs × Price_per_WCU_per_hour × 730 godzin/miesiąc Ale za każdym razem, gdy to upraszczałem, trudniej było uzyskać równość między tym, co obliczyłem, a końcową ceną w obliczeniach AWS. Czasami różnica wynikała z zaokrąglania, w innych przypadkach wynikało to z mieszaniny zastrzeżonej + zdolności prowizji itp. Aby ułatwić (dla mnie) naprawę, wiernie podążałem za ich obliczeniami linią za linią i próbowałem powtórzyć to w mojej własnej dość brzydkiej funkcji: https://github.com/scylladb/calculator/blob/main/src/calculator.js Mogę to jeszcze przekształcić w mniejsze funkcje. Ale na razie chciałem uzyskać równość między ich a naszymi. Zobaczysz, że istnieją również testy końcowe dla tych obliczeń - używam tych, aby przetestować wiele różnych konfiguracji. W ten sposób wykonuje się prace nad modelami pojemności On Demand, Provisioned (i Reserved). Jeśli korzystałeś z kalkulatora AWS, wiesz, że nie możesz określić takich rzeczy jak szczyt (lub szerokość szczytu) w aplikacji On Demand. Nie jestem pewien co do ich uzasadnienia. Lepiej radzę sobie z wizualnymi, więc widok szczytów i szczytów ułatwia mi zrozumienie – i mam nadzieję, że i dla ciebie. Zauważysz również, że zmieniając dane wejściowe, parametry zapytania URL zmieniają się, aby odzwierciedlać te dane wejściowe. Istnieje kilka innych matematyk, takich jak ustalenie prawdziwych kosztów Global Tables i zrozumienie kosztów pochodnych takich rzeczy jak transfer sieciowy lub DynamoDB Accelerator (DAX). Dobrą wiadomością jest to, że możesz oszacować te koszty oprócz swojego obciążenia pracą, ponieważ mogą one być dużymi mnożnikami kosztów podczas planowania korzystania z DynamoDB. Poznaj scenariusze „co jeśli” dla własnych obciążeń roboczych Analiza kosztów w scenariuszach rzeczywistych Ostatecznym celem całego tego tinkering i tuning jest, aby pomóc Ci zbadać różne scenariusze „co jeśli” z perspektywy kosztów DynamoDB. Aby rozpocząć, dzielimy się wpływem kosztów niektórych bardziej interesujących scenariuszy użytkowników DynamoDB, które spotkaliśmy w ScyllaDB. Mój kolega Gui i ja właśnie spotkaliśmy się, aby głęboko zanurzyć się w to, jak czynniki takie jak wzrost ruchu, ekspansja wielu centrów danych i wprowadzenie pamięci podręcznej (np. DAX) wpływają na koszty DynamoDB. Obejrzyj DynamoDB koszty czat teraz Tytuł: Tim Koopmans W ciągu ostatnich kilku dekad Tim zajmował się wszelkimi formami inżynierii, dążąc do niezawodności i bezpieczeństwa.W 2013 roku założył Flood IO; rozproszoną platformę do testowania wydajności.Po jej przejęciu cieszył się skalowaniem produktu, biznesu i zespołu przed przejściem do innych działań związanych z wydajnością.
