AWS ElastiCache / SimpleQueue与DynamoDB

我们使用DynamoDB和ElastiCache Redis的原因有很多。

DynamoDB：

• 有一个查询语言，能够做更复杂的事情（大于，之间等）
• 可以通过外部面向互联网的API访问（不同区域可以在没有任何改变或自己的基础设施）
• 基于表或者甚至行的权限是可能的
• 根据数据大小缩放至无限大
• 您按要求付款 – >低要求号码表示较小的帐单，高要求号码表示较高的帐单
• 读写成本不同
• AWS在多个设施中保存数据
• DynamoDB具有高度可用的开箱即用function
• 自动缩放在服务本身中可用

ElastiCache Redis：

• 简单的查询语言 – 没有复杂的function
• 从其他地区无法访问（开箱即用）。
• 您总是限制在内存的数量（或集群中所有主要实例的总和）
• 在多个实例中进行分片只能在你的应用程序中进行–Redis在这里不做任何事情（Redis集群在这里有帮助，但是分片逻辑仍然在你的应用程序中使用的驱动程序/ sdk中） – scale-in和scale-如果没有宕机的话，现在是不可能的
• 无论负载或请求的数量如何，您都按每个实例支付。
• 如果你想要冗余的数据，你需要设置复制（不可能在不同的地区之间）
• 您需要使用副本以实现高可用性
• 没有可用的自动缩放（参见上面没有缩放的部分）

所以我们的设置大部分时间是：在Redis中由Redo提供的大容量请求的简单caching，作为永久和长期持久的存储。 有了这个，我们限制了成本，因为我们通过Redis的按实例付费模型获得隐式折扣，同时也获得了DynamoDB冗余的好处，甚至可以将DynamoDB查询语言用于更复杂的工作（如果我们需要的话）。

希望有所帮助！

更新：随着Amazon DynamoDB加速器（ https://aws.amazon.com/de/dynamodb/dax/ ）的发布，我们正在切换使用DAX（最终），我们正在使用DAX DynamoDB和Redis的组合。 由于DAX完全由AWSpipe理，使我们有机会在应用程序中始终使用DynamoDB语言，而且还可以像Redis一样获得直写caching的好处。

我们使用Elasticache而不是DynamoDB的主要原因是速度 – 对于小物体，您可以获得小于1ms的往返延迟。 这个盒子非常接近你的EC2机器，内存比磁盘，甚至SSD要快得多。

考虑到不同的定价模式，也可能有成本优势，尽pipe我没有在那里详细描述。

Redis / memcached是内存中的存储，通常应该比caching/队列types数据的DynamoDB更快。 他们还有一些方便的附加项目，如Dynamo可能没有的过期键，Redis中的Pub / Sub等。