Tránh ga dynamoDB

Question

Tôi mới sử dụng điện toán đám mây, nhưng có một câu hỏi nếu một cơ chế như những gì tôi sắp mô tả tồn tại hoặc có thể tạo ra?

Dynamodb có thông lượng được cung cấp (ví dụ: 100 ghi/giây). Tất nhiên, trong thực tế ứng dụng thực tế đời sống thông qua là rất năng động và sẽ hầu như không bao giờ được cung cấp số tiền của bạn là 100 viết/giây. Tôi đã nghĩ những gì sẽ là tuyệt vời sẽ là một số loại hàng đợi cho dynamodb. Ví dụ, dynamodb của tôi trong giờ cao điểm có thể nhận được 500 yêu cầu ghi mỗi giây (gấp 5 lần những gì tôi đã phân bổ) và sẽ trả về lỗi. Có một số hàng đợi tôi có thể đặt giữa máy khách và cơ sở dữ liệu, vì vậy các yêu cầu của máy khách đi đến hàng đợi, máy khách nhận được yêu cầu của họ đã được xử lý, sau đó hàng đợi sẽ đưa ra yêu cầu tới dynamodb với tốc độ 100/viết mỗi giây một cách chính xác, vì vậy mà không có lỗi trả lại và tôi không cần phải nâng cao thông qua đặt mà sẽ nâng cao chi phí của tôi?

Answer 1

Đưa AWS SQS lên trước DynamoDB sẽ giải quyết vấn đề này cho bạn và không phải là mẫu thiết kế không phổ biến. SQS đã rất phù hợp để mở rộng quy mô lớn và cần nhập một lượng lớn thông điệp với các mẫu luồng không thể đoán trước.

Bạn có thể đặt tất cả thư vào SQS trước hoặc sử dụng SQS làm bộ đệm tràn khi bạn vượt quá mức mặc định thiết kế trên cơ sở dữ liệu DynamoDB của mình.

Một hoặc nhiều trường hợp công nhân không thể đọc thư từ hàng đợi SQS và đưa chúng vào DynamoDB theo đúng tốc độ bạn quyết định.

Nếu thứ tự của các thông điệp đến vô cùng quan trọng, Kinesis là một tùy chọn khác để bạn nhập các tin nhắn đến và sau đó chèn chúng vào DynamoDB, theo cùng thứ tự chúng đến, với tốc độ bạn xác định.

IMO, SQS sẽ dễ làm việc hơn, nhưng Kineses sẽ cung cấp cho bạn sự linh hoạt hơn nếu nhu cầu của bạn phức tạp hơn.

Answer 2

Điều này không thể hoàn thành bằng DynamoDB. DynamoDB được thiết kế cho khối lượng công việc đồng nhất, có thể mở rộng, có thể dự đoán được. Nếu bạn muốn đặt hàng đợi trước DynamoDB, bạn đã tự làm điều đó.

DynamoDB có một chút khoan dung đối với burst capacity, nhưng đó không phải là để sử dụng bền vững. Bạn nên đọc các thông lệ phần tốt nhất Consider Workload Uniformity When Adjusting Provisioned Throughput, nhưng đây là một số ít, những gì tôi nghĩ là quan trọng, đoạn văn với một vài điều được nhấn mạnh bởi tôi:

Đối với các ứng dụng được thiết kế để sử dụng với khối lượng công việc thống nhất, phân vùng DynamoDB của hoạt động phân bổ không đáng chú ý. Một sự không thống nhất tạm thời trong khối lượng công việc thường có thể được hấp thụ bởi phụ cấp bùng nổ, như được mô tả trong Use Burst Capacity Sparingly. Tuy nhiên, nếu ứng dụng của bạn phải phù hợp với khối lượng công việc không đồng đều, bạn nên thiết kế bảng của mình với hành vi phân vùng của DynamoDB (xem Understand Partition Behavior) và lưu ý khi tăng và giảm thông lượng được cung cấp trên bảng đó.

Nếu bạn giảm lượng thông lượng được cung cấp cho bảng của mình, DynamoDB sẽ không làm giảm số lượng phân vùng. Giả sử bạn đã tạo một bảng có lượng thông tin được cung cấp lớn hơn nhiều so với ứng dụng của bạn thực sự cần thiết, và sau đó giảm thông lượng được cung cấp sau đó. Trong trường hợp này, thông lượng được cấp phép cho mỗi phân vùng sẽ nhỏ hơn mức có thể nếu ban đầu bạn đã tạo bảng với ít thông lượng hơn.

Có các công cụ trợ giúp tự động mở rộng DynamoDB, chẳng hạn như sebdah/dynamic-dynamodb có thể đáng xem xét.