我有一个使用MySQL数据库记录来呈现页面的Web应用程序。
每条记录具有以下内容：
静态HTML永远不会在联接中使用，也不是可搜索的。仅当通过主键检索整个记录时才检索它。
到目前为止，一切进展顺利。但是，随着表大小的增加，我认为将静态HTML文本存储在MySQL外部可能更有效。
MySQL数据库在AWS RDS中运行。因此，我正在考虑使用另一个AWS服务来存储文本数据。所以我目前的选择是：
我对选项1的关注是表的大小。选项2和3的问题在于同步问题，并且在渲染页面时必须在服务器端进行额外的调用才能获取数据。我的理解是DynamoDB的数据检索速度将比S3快，但是它对每个记录都有大小限制，并且处理容量单位等时可能会变得昂贵而混乱。
任何指导都会有所帮助。谢谢。
答案 0 :(得分：1)
我认为您已经准确地确定了DynamoDB和S3之间的权衡。
我认为最简单的解决方案是使用S3。在S3和MySQL之间保持同步并不像您想象的那样困难或容易出错。我专业工作的应用程序之一使用了该策略（针对不同的用例），而且我们从未遇到与S3数据与主数据库不同步相关的操作负担。
是的，来自S3的延迟高于DynamoDB。您可以预期DynamoDB的时间少于10毫秒，而S3则需要几十毫秒（假设对象<= 400 kB，DynamoDB项的大小限制）只有几十毫秒。但是，S3不需要您提供容量，实际上，文件大小没有限制。 （从技术上讲，单个文件不能超过5TB，但在这种情况下您不太可能达到该文件。）
除非您知道需要一位数毫秒的延迟，否则应使用S3。它就是为此设计的。
S3保证在创建对象时具有很强的一致性，但在更新对象时只能保证最终的一致性。如果您对此感到担心，请确保每次正常更新时都只创建一个新对象。由于您将密钥存储在数据库中，因此您无需绑定到特定的文件名，并且每次修改html时都可以轻松生成一个新密钥。
如果使用S3构建它，并且延迟最终变得过高，则可以在S3前面放置一个缓存，或者可以尝试使用带有CloudFront的Lambda @ Edge迁移到无服务器模型，以从S3提供静态资源。