AWS ElastiCache / SimpleQueue vs DynamoDB

Tôi đang tự hỏi về lý do sử dụng ElastiCache / SimpleQueue so với việc chỉ có các bảng "Cache" và "Queue" bên trong DynamoDB tương ứng.

Có vẻ như độ trễ mạng đối với các dịch vụ Cache / Queue sẽ tăng rất nhiều hiệu suất và việc EC2 xử lý Dynamo vì dịch vụ cache / hàng đợi của nó sẽ cung cấp độ trễ và thông lượng tương tự (vì Dynamo cho phép độ trễ thấp cố định trong bất kỳ tải).

Có phải chủ yếu là về giá của máy phát điện so với các dịch vụ khác đang tải?

Có ai có bất kỳ số độ trễ thô nào khi so sánh Dynamo với ElastiCache / SQS không?

Có những cân nhắc quan trọng nào khác mà tôi đang thiếu mà biện minh cho sự phức tạp bổ sung?

Cảm ơn.

Chúng tôi đang sử dụng DynamoDB và ElastiCache Redis vì những lý do khác nhau.

Máy phát điện:

• Có một ngôn ngữ truy vấn có thể thực hiện những điều phức tạp hơn (lớn hơn, giữa, v.v.)
• Có thể truy cập thông qua API đối diện internet bên ngoài (các khu vực khác nhau có thể truy cập mà không có bất kỳ thay đổi hoặc cơ sở hạ tầng riêng nào)
• Quyền dựa trên bảng hoặc thậm chí hàng có thể
• Cân về kích thước dữ liệu đến vô cùng
• Bạn trả cho mỗi yêu cầu -> số yêu cầu thấp có nghĩa là hóa đơn nhỏ hơn, số yêu cầu cao có nghĩa là hóa đơn cao hơn
• Đọc và viết là khác nhau về chi phí
• Dữ liệu được AWS lưu trong nhiều cơ sở
• DynamoDB có sẵn rất cao
• Tự động hóa có sẵn trong chính dịch vụ

ElastiCache Redis:

• Ngôn ngữ truy vấn đơn giản - không có tính năng phức tạp
• Là (ngoài hộp) không thể truy cập từ các khu vực khác.
• Bạn luôn bị giới hạn số lượng bộ nhớ (hoặc tổng của tất cả các phiên bản chính trong một cụm)
• Việc bảo vệ nhiều trường hợp chỉ có thể có trong ứng dụng của bạn - Redis không làm gì ở đây (Redis cluster giúp ở đây nhưng logic shending vẫn nằm trong trình điều khiển / sdk bạn đang sử dụng trong ứng dụng của mình) - chia tỷ lệ và chia tỷ lệ- Hiện tại là không thể nếu không có thời gian chết
• Bạn trả tiền cho mỗi trường hợp cho dù tải hay số lượng yêu cầu như thế nào.
• Nếu bạn muốn dự phòng dữ liệu, bạn cần thiết lập sao chép (không thể giữa các vùng khác nhau)
• Bạn cần sử dụng bản sao để sẵn sàng cao
• Không có tự động hóa có sẵn (xem phần về không có tỷ lệ ở tất cả ở trên)

Vì vậy, thiết lập của chúng tôi hầu hết thời gian là: Bộ nhớ cache đơn giản với khối lượng yêu cầu lớn trong Redis được hỗ trợ bởi DynamoDB là bộ lưu trữ lâu dài và lâu dài. Với điều này, chúng tôi giới hạn chi phí khi chúng tôi được giảm giá ngầm cho các lần đọc của chúng tôi theo mô hình trả tiền theo trường hợp của Redis nhưng cũng nhận được lợi ích từ sự dư thừa của DynamoDB và thậm chí có thể sử dụng ngôn ngữ truy vấn của DynamoDB cho những thứ phức tạp hơn ( nếu chúng ta cần nó).

Mong rằng sẽ giúp!

Cập nhật: Với thông báo về Trình tăng tốc Amazon DynamoDB ( https://aws.amazon.com/de/dynamodb/dax/ ), chúng tôi sẽ chuyển sang sử dụng DAX như chính xác (cuối cùng) chúng tôi đang làm gì với sự kết hợp giữa DynamoDB và Redis. Vì DAX được quản lý hoàn toàn bởi AWS và cho chúng tôi cơ hội luôn sử dụng ngôn ngữ DynamoDB trong ứng dụng của mình nhưng cũng nhận được lợi ích từ bộ đệm ghi thông qua như Redis.

Lý do chính chúng tôi sử dụng Elasticache thay vì DynamoDB là tốc độ - bạn có độ trễ chuyến đi vòng 1ms cho các đối tượng nhỏ. Hộp thực sự gần với máy EC2 của bạn và bộ nhớ nhanh hơn nhiều so với đĩa, thậm chí cả SSD.

Cũng có thể có một lợi thế về chi phí với các mô hình định giá khác nhau, mặc dù tôi chưa đi sâu vào chi tiết đó.

Redis / memcached là các kho lưu trữ trong bộ nhớ và thường phải nhanh hơn DynamoDB cho dữ liệu kiểu bộ đệm / hàng đợi. Họ cũng có các vật phẩm bổ sung tiện dụng như khóa hết hạn, Pub / Sub trong Redis, v.v. mà Dynamo có thể không có.