mysql - AWS 中的何处存储与数据库记录关联的大块 HTML 内容

Question

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

每条记录都有以下内容:

• ID(主键)
• 各种类型的附加字段(整数、varchar、long 等)
• 文本(或中文本)类型的字段，用于存储页面上显示的静态 HTML block

静态 HTML 永远不会在连接中使用，也不意味着可搜索。仅当通过主键检索整个记录时才检索它。

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

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

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

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

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

Answer 1

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

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

是的，S3 的延迟高于 DynamoDB。您预计 DynamoDB 的时间小于 10 毫秒，而 S3 的时间为数十到数百毫秒(假设对象 <= 400 kB，即 DynamoDB 项目大小限制)。但是，S3 不需要您配置容量，实际上，文件大小没有限制。 (从技术上讲，单个文件不能超过 5TB，但对于此用例，您不太可能达到这个大小。)

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

S3在创建对象时保证强一致性，但在更新时仅保证最终一致性。如果您担心这一点，请确保每次正常更新对象时都创建一个新对象。由于您将 key 存储在数据库中，因此您不受特定文件名的限制，并且每次修改 html 时都很容易生成新 key 。

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