Why real-world DynamoDB usage scenarios often lead to unexpected expenses In , Tôi đã đề cập đến cách tải công việc không thể đoán trước dẫn đến chi phí không thể đoán trước trong DynamoDB. Bài viết mới nhất về DynamoDB Bây giờ chúng ta hãy đi sâu hơn. một khi bạn đã hiểu những điều cơ bản, như nutty , hoặc chi phí quá mức xung quanh kích thước mục, sao chép và bộ nhớ cache ... bạn sẽ nhận ra rằng chi phí DynamoDB không chỉ là về khối lượng đọc / viết - nó là nhiều sắc thái hơn trong thế giới thực. 7.5x inflation of on-demand compared to reserved Lời bài hát: Round Em Up! Một triệu chữ viết mỗi giây ở 100 byte không nằm trong cùng một thiên hà như một triệu chữ viết ở 5KB. Tại sao? Bởi vì DynamoDB đo chi phí trong các mảnh 1KB cho chữ viết (và 4KB cho đọc). Viết một mục 1.2KB? Bạn được tính phí cho 2KB. Đọc một mục 4.5KB với tính nhất quán mạnh mẽ? Bạn được tính phí cho 8KB. Bạn không chỉ trả tiền cho những gì bạn sử dụng, bạn đang trả tiền cho việc làm tròn. Nhớ nhân vật này trong Superman III lấy 1⁄2 xu từ mỗi thanh toán? Đó là cùng một thỏa thuận (và vâng, $ 85,789.90 là rất nhiều tiền vào năm 1983) ... Wasted capacity is unavoidable at scale, but it becomes very real, very fast when you cross that boundary on every single operation. And don’t forget that hard cap of 400KB per item. That’s not a pricing issue directly, but it’s something that has motivated DynamoDB customers to look at alternatives. của chúng tôi cho phép bạn mô hình tất cả những điều này. Những gì nó không tính là một số mìn đất trong thế giới thực - chẳng hạn như thực tế là một bản ghi xung đột được giải quyết (chẳng hạn như cập nhật đồng thời ở nhiều khu vực) vẫn tốn tiền cho bạn mỗi lần cố gắng, ngay cả khi chỉ có bản ghi cuối cùng giành chiến thắng. Hoặc khi bạn xây dựng logic hết hạn TTL của riêng bạn, có thể kéo một loạt các mục trong quét, kiểm tra dấu thời gian trong mã ứng dụng, hoặc phát hành xóa. , mà bây giờ bạn có thể xem theo yêu cầu. DynamoDB cost calculator DynamoDB chi phí webinar Global tables are a global pain So you want low latency for users worldwide? Global tables are the easiest way to do that. Some might even say that it’s “batteries-included.” But those batteries come with a huge price tag. Mỗi bài viết được sao chép qua các khu vực bổ sung. Viết một mục 3.5KB và sao chép nó cho 4 khu vực? Bây giờ bạn đang trả tiền cho 4 x 4KB (tùy nhiên, được làm tròn). Đừng quên thực hiện chuyển giao mạng giữa các khu vực. Đó là một cú đánh khác ở mức giá cao. Và xin lỗi, bạn không thể đặt các bài viết sao chép đó. You’re paying for that speed, several times over, and the bill scales linearly with your regional growth. Nó trở nên tồi tệ hơn khi nhiều khu vực viết cho cùng một mục cùng một lúc. DynamoDB giải quyết xung đột (viết cuối cùng chiến thắng) nhưng bạn vẫn phải trả tiền cho mỗi lần cố gắng. Máy tính chi phí của chúng tôi cho phép bạn mô hình tất cả điều này. chúng tôi sử dụng giá bảo thủ cho Hoa Kỳ-Tây Đông, nhưng khu vực càng kỳ lạ, càng có khả năng chi phí sẽ cao hơn. Vì vậy, hãy suy nghĩ về chi phí sao chép bảng toàn cầu bao gồm pin, và xin vui lòng nhớ, đó là ! trên bàn DAX caching với một catch Bây giờ bạn có muốn độ trễ đọc thậm chí còn chặt chẽ hơn, đặc biệt là đối với P99 nhạy cảm với độ trễ của bạn? DynamoDB Accelerator (DAX) giúp đỡ, nhưng nó bổ sung thêm trên đầu, cả hoạt động và tài chính. Các cụm cần phải được kích thước đúng, tỷ lệ hit được điều chỉnh, và các trường hợp lỗi được xử lý trong ứng dụng của bạn. Bỏ qua bộ nhớ cache, trả tiền cho việc đọc. Không cập nhật bộ nhớ cache, rủi ro bị mất dữ liệu. Even after you have tuned it, it’s not free. DAX instances are billed by the hour, at a flat rate, and once again, without reserved instance options like you might be accustomed to. Máy tính chi phí DynamoDB của chúng tôi cho phép bạn mô phỏng tỷ lệ hit bộ nhớ cache, kích thước tập dữ liệu, loại trường hợp và nút. Nó sẽ không dự đoán hiệu quả bộ nhớ cache, nhưng nó sẽ giúp bạn bắt những gotchas bộ nhớ cache. Động cơ khuyến nghị hàng triệu đô la Một dịch vụ phát trực tuyến lớn đã xây dựng một công cụ giới thiệu toàn cầu với DynamoDB. công việc lô hàng hàng ngày tạo ra các khuyến nghị mới và viết chúng vào một bảng duy nhất 1PB, sao chép trên 6 khu vực. Họ đã tối ưu hóa cho độ trễ và viết địa phương. Chi phí? Mỗi viết vào bảng cơ sở cộng với 5 viết lặp. Mỗi tương tác người dùng đã kích hoạt một viết (xem lịch sử, phản hồi, sở thích). Và nhờ chu kỳ làm mới hàng ngày đó, họ đã viết lại bảng - cho dù có gì thay đổi. They used provision capacity, scaling up for anticipated traffic spikes, but still struggled with latency. Cache hit rates were too low to make Redis or DAX cost-effective. The result? Base workload alone cost tens of millions per year, and the total doubled after accommodating peaks in traffic spikes and batch load processes. Đối với nhiều nhóm, đó là nhiều hơn doanh thu của chính sản phẩm! Sau khi họ chuyển sang mô hình định giá của chúng tôi dựa trên khả năng dự trữ (không tính phí mỗi hoạt động), ScyllaDB đã có thể nén đáng kể dữ liệu được lưu trữ của họ, đồng thời cải thiện nén mạng giữa AZ và khu vực. Họ có tự do làm điều này trên bất kỳ đám mây nào (hoặc thậm chí tại chỗ). Họ đã cắt giảm chi phí của họ, cải thiện hiệu suất và loại bỏ sự cần thiết phải nén quá mức cho đỉnh. công việc hàng loạt hàng ngày chạy nhanh hơn và doanh nghiệp của họ tiếp tục mở rộng mà không có hóa đơn cơ sở dữ liệu của họ làm như vậy. Another case of caching to survive Một công ty adtech sử dụng DynamoDB đã chạy vào sự phức tạp của bộ nhớ đệm theo cách khó khăn. họ đã triển khai 48 nút DAX trên 4 khu vực để đạt được mục tiêu độ trễ P99. mỗi nút được điều chỉnh theo khối lượng công việc của khu vực đó (sau nhiều thử nghiệm và lỗi). Their writes (246 bytes/item) were wasting 75% of the write unit billed. Their analytics workload tanked live traffic during spikes. And perhaps worst of all, auto-scaling triggers just weren’t fast enough, resulting in request throttling and application failures. The total DynamoDB and DAX cost was hundreds of thousands per year. ScyllaDB offered a much simpler solution. Built-in row caching used instance memory at no extra cost with no external caching layer to maintain. They also ran their analytics and OLTP workloads side by side using Không ảnh hưởng đến hiệu suất. Workload ưu tiên Thậm chí tốt hơn, thời gian hết hạn phiên dựa trên TTL của họ được xử lý tự động mà không có logic đọc / xóa thêm. chi phí và sự phức tạp đã giảm, và họ bây giờ là một khách hàng hạnh phúc. Xem video chi phí DynamoDB If you missed the webinar, be sure to check out the – Đặc biệt là nơi Guilherme bao gồm tất cả các khối lượng công việc thực tế này chi tiết. DynamoDB costs video Chi phí DynamoDB là phi tuyến tính và được định hình bởi các mô hình sử dụng, không chỉ là thông lượng. Global tables, item size, conflict resolution, cache warmup and more can turn “reasonable” usage into a 7-figure nightmare. DAX và tự động quy mô không phải là phép thuật; chúng cần điều chỉnh và vẫn tốn tiền đáng kể để có được đúng. Máy tính chi phí DynamoDB của chúng tôi giúp mô hình hóa các chi phí ẩn này và so sánh các thiết lập khác nhau, ngay cả khi bạn không sử dụng ScyllaDB. And finally, if you’re a team with unpredictable costs and performance using DynamoDB, make the switch to ScyllaDB and enjoy the benefits of predictable pricing, built-in efficiency and more control over your database architecture. If you want to discuss the nuances of your specific use case and get your technical questions answered, . chat with us here 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.
