65

我正在将我的 Java、Tomcat、Mysql 服务器迁移到 AWS EC2。

我已经附加了用于存储 MySql 数据的 EBS 卷。在我的网络应用程序中，人们可能会上传图片。所以我应该坚持他们。我的想法有2个选择：

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

以下是我的笔记，请不要怀疑，因为我的专长不是服务器，而是软件开发。

  • EBS plus：S3 存储更贵。（0.15 美元/Gb > 0.1 美元/Gb）

  • S3 plus：从 EBS 提供静态数据可能会对我的 Web 服务器的性能产生负面影响。这是真的？服务图像是否会显着影响服务器性能？对于 S3，我的服务器将不负责提供静态数据。

  • S3 plus：从 EBS 提供静态数据可能会导致 I/O 成本，可能会很小。

  • EBS plus：人们说 EBS 更快。

  • S3 plus：人们说 S3 对于持久性来说更安全。

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

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

谢谢

4

5 回答 5

53

价格比较不太对劲：S3 费用为每 GB 使用 0.14 美元，而 EBS 费用为每 GB 0.10 美元（您的 EBS 卷的大小），无论您是否使用它。因此，S3 可能比 EBS 便宜，也可能不便宜。

于 2011-02-01T18:58:23.967 回答
49

我目前正在为一个项目使用 S3，它运行得非常好。

EBS 意味着您需要管理一个卷 + 将其附加到的机器。您需要在空间填满时添加空间并执行备份（并不是说您不应该备份您的 S3 数据，只是它不那么重要）。

这也使得扩展变得更加困难：当您想要添加额外的机器时，您要么需要将图像拉到单独的机器上，要么在所有机器上克隆图像。这也意味着您正在添加一个瓶颈：您必须管理自己的上传过程，该过程将上传到所有机器或让单个机器管理它。

我推荐 S3：设置好了就忘了。任何数量的机器都可以并行执行上传，您实际上不需要通知其他机器有关上传。

此外，您可以使用 Amazon Cloudfront 作为图像前面的廉价 CDN，而不是直接从 S3 下载。

于 2010-02-18T14:03:22.313 回答
12

我在 AWS 上为 Stock 摄影网站构建了解决方案，该网站存储了数百万张跨越 TB 数据的图像，我想分享一些 AWS 中的最佳实践以满足您的要求：

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

P2) 在 S3 减少冗余选项 (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 仍然可以连接到它并访问/写入图像。

于 2013-05-29T07:14:22.793 回答
8

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

如果您计划存储 TB 级的图像，并且存储需求日复一日地增加，那么S3可能是您的最佳选择，因为它专为此类情况而构建。您可以获得无限的存储空间，而不必担心将数据分片到多个EBS卷上。

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

于 2010-02-18T12:30:53.540 回答
5

你希望这些图像无限期地持续下去吗？

Amazon EBS 常见问题解答非常清楚；年故障率并非“基本为零”；他们报价 0.1% 到 0.5%。它比你办公桌下的磁盘要好，但它需要某种备份。

于 2011-03-08T22:31:51.570 回答