我应该坚持在EBS或S3上的图像?

我将我的Java,Tomcat,Mysql服务器迁移到AWS EC2。

我已经附加了EBS卷来存储MySql数据。 在我的web应用程序中,人们可能会上传图片 所以我应该坚持下去。 我脑海中有两种select:

  1. 将上传的图像保存到EBS卷。
  2. 使用S3服务。

以下是我的笔记,请对此表示怀疑,因为我的专业知识不在服务器上,而在于软件开发。

  • EBS plus:S3存储更贵。 (0.15 $ / Gb> 0.1 $ / Gb)

  • S3 plus:从EBS服务静态可能会影响我的Web服务器的性能。 这是真的? 服务图像是否会显着影响服务器性能? 对于S3我的服务器将不负责服务静态。

  • S3 plus:从EBS服务静态可能会导致I / O成本,可能会很小。

  • EBS加上:人们说EBS更快。

  • S3 plus:人们说S3对于持久性更加安全。

  • EBS plus:无需学习API,直接将图像保存到EBS卷。

即我不能决定,如果你指导,会很高兴。

谢谢

我目前正在使用S3作为一个项目,它工作得非常好。

EBS意味着你需要pipe理一个卷+机器来附加它。 你需要增加空间来填充和执行备份(不要说你不应该备份你的S3数据,只是它不重要)。

这也使得难以扩展:当你想添加额外的机器,你需要将图像拖到一台单独的机器或克隆所有的图像。 这也意味着你正在增加一个瓶颈:你必须pipe理自己的上传过程,这个过程可以上传到所有的机器上,或者让一台机器来pipe理它。

我推荐S3:已经设定好了,忘记了。 任何数量的机器都可以并行执行上传,而您并不需要通知其他机器上传。

另外,您可以将Amazon Cloudfront用作图像前的便宜CDN,而不是直接从S3下载。

价格比较是不正确的:不pipe是否使用,S3费用是每GB使用0.14美元,而EBS费用是每GB提供0.10美元(EBS数量)。 因此,S3可能比EBS便宜也可能不便宜。

我已经在AWS上为AWS的架构devise了一些存储数百万张跨越TB数据的图片的网站,我想根据您的要求分享一些AWS最佳实践:

P1)在S3标准选项中存储原始图像文件

P2)在S3 Reduced Redundancy选项(RRS)中存储可重现的图像,如拇指等,以节省成本

P3)有关包含S3 URL的图像的元数据可以存储在Amazon RDS或Amazon DynamoDB中,具体取决于查询的复杂性。 查询Amazon RDS中的条目。 如果查询复杂,则将元数据存储在Amazon CloudSearch或Apache Solr中也是常见的做法。

P4)使用Amazon CloudFront将您的大拇指传递给延迟较低的用户。

P5)通过Amazon EC2上的SQS或RabbitMQ排队镜像转换

P6)如果您打算使用EBS,那么它们不能与EC2一起扩展。 因此,理想情况下,您可以将GlusterFS用作所有映像的公用存储池。 Auto Scaled模式下的多个Amazon EC2仍然可以连接到它并访问/写入图像。

你已经概述了两者的优点和缺点。

如果您计划存储千兆字节的图像,随着存储需求的日益增加, S3可能是您最好的select,因为它是专为这种情况而build的。 您可以获得无限的存储空间,而无需担心在许多EBS卷上分割数据 。

S3的经常性成本是比EBS贵50%。 您还必须学习API并在您的应用程序中实施它,但这是一次性支出,我认为您应该能够很快吸收。

你期望的图像无限期地持续?

亚马逊EBS常见问题解答非常清楚。 年度失败率不是“基本为零”; 他们引用0.1%到0.5%。 它比桌面下的磁盘要好,但需要一些备份。