AWS ElastiCache / SimpleQueue与DynamoDB

我想知道使用ElastiCache / SimpleQueue的理由，而不是分别在DynamoDB内部具有“ Cache”和“ Queue”表。

似乎到Cache / Queue服务的网络延迟将大大提高性能，并且使EC2将Dynamo视为其缓存/队列服务将提供相同的延迟和吞吐量（因为Dynamo在任何情况下都允许固定的低延迟）加载）。

它主要是关于发电机负载下其他服务的价格吗？

有人将Dynamo与ElastiCache / SQS进行比较时，有任何大致的延迟数字吗？

我还缺少其他更重要的考虑因素来证明额外的复杂性吗？

谢谢。

出于不同的原因，我们使用DynamoDB和ElastiCache Redis。

DynamoDB：

• 具有查询语言，它能够执行更复杂的操作（大于，大于或等于之间）
• 可通过外部面向Internet的API进行访问（无需更改或拥有自己的基础结构即可访问不同区域）
• 基于表甚至行的权限都是可能的
• 根据数据大小扩展到无穷大
• 您按请求付费->请求号低表示账单较小，请求号高表示账单较高
• 读写成本不同
• AWS将数据冗余存储在多个设施中
• DynamoDB开箱即用
• 自动缩放可在服务本身中使用

ElastiCache Redis：

• 简单的查询语言-没有复杂的功能
• 从其他区域（开箱即用）无法访问。
• 您总是受限于内存量（或群集中所有主实例的总和）
• 仅可在您的应用程序内对多个实例进行分片-Redis在这里不做任何事情（Redis群集在这里没有帮助，但分片逻辑仍在您在应用程序中使用的驱动程序/ SDK内部）-放大和缩放-目前没有停机是不可能的
• 无论负载或请求数量如何，您都按实例付费。
• 如果要冗余数据，则需要设置复制（在不同区域之间不可能）
• 您需要使用副本以实现高可用性
• 没有可用的自动缩放功能（请参阅上面有关完全不缩放的部分）

因此，我们大多数时候的设置是：由DynamoDB支持的Redis中的简单缓存和大量持久的持久存储。有了这个，我们就限制了成本，因为通过Redis的按实例付费模型为读取提供了隐式折扣，而且还受益于DynamoDB的冗余，甚至还可以将DynamoDB查询语言用于更复杂的东西（如果我们需要它）。

希望有帮助！

更新：随着Amazon DynamoDB Accelerator（https://aws.amazon.com/de/dynamodb/dax/）的发布，我们将切换使用DAX，这实际上是（最终）我们正在使用DAX DynamoDB和Redis的组合。由于DAX受AWS完全管理，因此使我们有机会始终在我们的应用程序中使用DynamoDB语言，而且还可以从Redis等直写式缓存中受益。

我们使用Elasticache而不是DynamoDB的主要原因是速度-小对象的往返延迟不到1毫秒。盒子确实靠近您的EC2计算机，并且内存比磁盘甚至SSD快得多。

考虑到不同的定价模式，虽然我还没有在其中详细介绍过，但也可能具有成本优势。

Redis / memcached是内存中存储，对于缓存/队列类型的数据，Redis / memcached通常应比DynamoDB快。它们还具有Dynamo可能没有的方便的其他项，例如到期密钥，Redis中的Pub / Sub等。