我有一个web应用程序，它使用mysql数据库记录来呈现页面。
每条记录都有以下内容：
id（主键）
各种类型的附加字段（integer、varchar、long等）
text（或mediumtext）类型的字段，用于存储页面上显示的静态html块
静态html从不用于连接，也不意味着可以搜索。仅当通过主键检索整个记录时，才会检索它。
到目前为止，事情进展顺利。但是，随着表大小的增加，我认为在mysql外部存储静态html文本可能更有效。
mysql数据库在aws rds中运行。所以，我在考虑使用另一个aws服务来存储文本数据。所以我现在的选择是：
将所有内容都保存在mysql中，而不必担心表的大小（它目前接近1gb，而且增长很快）。
对html文本数据使用s3对象，并通过主键或类似于存储在表中的uuid的内容引用它们
对html文本数据使用dynamodb，并使用存储在数据库中的键（或通过相同的主键）引用值
我关心的是选项1的表大小。选项2和选项3的问题是同步问题，并且在呈现页面时必须在服务器端进行额外调用以获取数据。我的理解是dynamodb在数据检索方面要比s3快，但是它对每条记录都有一个大小限制，处理容量单位之类的数据可能会变得昂贵和混乱。
任何指导都会有帮助。谢谢。
1条答案
按热度按时间368yc8dk1#
我认为您已经准确地确定了dynamodb和s3之间的权衡。
我认为最简单的解决方案是使用s3。在s3和mysql之间保持同步并不像您想象的那样困难或容易出错。我工作的一个应用程序专业地使用了这种策略（针对不同的用例），而且我们从未遇到过与主数据库中的s3数据不同步相关的任何操作负担。
是的，s3的延迟比dynamodb高。您可以预期dynamodb小于10ms，而s3小于几十到几百毫秒（假设对象小于等于400kb，dynamodb项目大小限制）。但是，s3不要求您提供容量，实际上，对文件大小没有限制(从技术上讲，单个文件的容量不能超过5tb，但对于本用例，您不太可能达到5tb。）
除非你知道你需要一位数的毫秒延迟，否则你应该使用s3。它就是为这件事而设计的。
s3在创建对象时保证了很强的一致性，但只有在更新时才保证最终的一致性。如果这是一个你关心的问题，确保你只是创建一个新的对象，每次你通常会更新它。由于您将密钥存储在数据库中，因此不必绑定到特定的文件名，而且每次修改html时都可以很容易地生成一个新密钥。
如果您使用s3构建它，并且延迟太高，那么您可以在s3前面放置一个缓存，或者您可以尝试使用lambda@edge 使用cloudfront为来自s3的静态资源提供服务。