mysql - 在 AWS 中存储与数据库记录相关的大量 HTML 内容的位置

Question

我有一个使用 MySQL 数据库记录来呈现页面的 Web 应用程序。

每条记录都有以下内容：

• ID（主键）
• 各种类型的附加字段（integer、varchar、long 等）
• 文本（或 mediumtext）类型的字段，用于存储页面上显示的静态 HTML 块

静态 HTML 从不用于连接，也不意味着可搜索。仅当通过主键检索整个记录时才检索它。

到目前为止，事情进展顺利。但是，随着表大小的增加，我认为将静态 HTML 文本存储在 MySQL 外部可能更有效。

MySQL 数据库在 AWS RDS 中运行。所以，我正在考虑使用另一个 AWS 服务来存储文本数据。所以我目前的选择是：

• 将所有内容保存在 MySQL 中，而不必担心表大小（它目前接近 1 GB 并且增长迅速）。
• 将 S3 对象用于 HTML 文本数据，并通过主键或存储在表中的 UUID 之类的东西来引用它们
• 将 DynamoDB 用于 HTML 文本数据并使用存储在数据库中的键（或通过相同的主键）引用值

我对选项 1 的关注是表格大小。选项二和三的问题是同步问题，并且在渲染页面时必须在服务器端进行额外的调用以获取数据。我的理解是，DynamoDB 在数据检索方面会比 S3 更快，但它对每条记录有大小限制，并且在处理容量单位等方面可能会变得昂贵且混乱。

任何指导都会有所帮助。谢谢。

标签： mysqlamazon-web-servicesamazon-s3amazon-dynamodb

Answer 1

我认为您已经准确地确定了 DynamoDB 和 S3 之间的权衡。

我认为最简单的解决方案是使用 S3。在 S3 和 MySQL 之间保持同步并不像您想象的那么困难或容易出错。我从事的其中一个应用程序专业地使用了该策略（用于不同的用例），并且我们从未遇到过与 S3 数据与我们的主数据库不同步相关的任何操作负担。

是的，S3 的延迟高于 DynamoDB。您可以预计 DynamoDB 小于 10 毫秒，而 S3 则为几十到几百毫秒（假设对象 <= 400 kB，即 DynamoDB 项目大小限制）。但是，S3 不需要您提供容量，实际上，文件大小没有限制。（从技术上讲，单个文件不能超过 5TB，但对于这个用例，你不太可能达到这个值。）

除非你知道你需要个位数的毫秒延迟，否则你应该使用 S3。它就是为这件事而设计的。

S3 在创建对象时保证强一致性，但仅在更新对象时保证最终一致性。如果这对您来说是一个问题，请确保每次通常更新它时只创建一个新对象。由于您将密钥存储在数据库中，因此您不会被绑定到特定的文件名，并且每次修改 html 时都可以轻松生成新密钥。

如果您使用 S3 构建它，但最终延迟太高，您可以在 S3 前面放置一个缓存，或者您可以尝试使用 Lambda@Edge 和 CloudFront 迁移到无服务器模型，以提供来自 S3 的静态资源。