我正在研究烧瓶后端应用程序。有一些配置文件图像从android前端进入烧瓶API端点。我想存储这些图像。
技术堆栈：Android应用，Flask API /后端，Postgres，AWS服务。
什么是最好的主意？
我想到了以下想法。如果这些想法有任何意义，请告诉我！
将图像直接存储在Postgres数据库中。 （我认为这很糟糕，因为它会给数据库带来负担）。
将图像存储在Amazon S3存储桶和S3文件路径中，作为Postgres表中的值之一。
我认为2的改进是 - 安排像2，并有一个CDN，如Amazon Cloudfront for CDN，并更快地分发给其他服务请求图像。
听起来怎么样？还有其他想法吗？
谢谢！ :)
答案 0 :(得分：0)
选项2是一种常用的方法，但是根据它的使用方式，Postgres中用于二进制大对象的lo类型也可以。首先，这是关于编写图像所需的吞吐量，以及用于检索图像的其他应用程序使用哪种请求接口（例如，通过Python Web框架序列化和反序列化blob图像不是一个好主意，但是对于某些用例，做一些类似gRPC服务器的东西可能就这样了。）
对于选项2，考虑如何为图像创建某种类型的图像ID是个好主意，这对于文件路径或名称的更改，格式更改，存储桶更改等都是可靠的。这可能是一种痛苦，但是在设置所有关于图像说明符的所有这些令人讨厌的方面得到适当规范化的事情是值得的。
考虑您是否需要一系列尺寸或后期处理输出，例如存储缩略图＆＃39;原始尺寸＆＃39;还是值得考虑的。和＆＃39;小＆＃39;版本的图像。如果事先没有以理智的方式布置，那么回填这些东西可能会非常痛苦。
这很大程度上取决于您的实际用例。数据集将如何增长？当人们请求图像数据时需要什么样的延迟？你有可能存储除图像之外的其他类型的资产吗？对于摄取和稍后提供图像，存在什么样的吞吐量需求。