首先,从前面的回答和对话中,我想说,不要担心数十亿行,直到你有问题要解决。如果您只是在设计一些全新的服务,则可能无需担心如何立即管理数十亿张图像。尝试处理可服务数十亿文件的高可用性、低延迟服务是一项设计挑战,世界上一些最优秀的工程师可能需要数年时间来设计和实施。
也许将注意力降低几个数量级,以考虑您将如何处理数百万或数千万条记录,或者您将在未来一两年内需要管理的任何现实级别的对象。在这种情况下,确实没有理由,例如,具有良好设计索引的 MySQL 安装无法处理对具有良好响应时间的数百万行的表的查询,特别是如果您了解访问模式并且能够缓存经常请求的文件元数据。
至于关系数据库是否是存储文件元数据的最佳方式,实际上取决于您要存储的数据的层次结构以及您的访问模式(即您将如何查找数据) )。您提供了一个关于如何组织文件的非常基本的示例,并建议可能存在某种组织结构,其中每个图像都以多种分辨率存储。
您的应用程序是否需要了解图像的所有分辨率选项并根据某些标准决定提供最佳分辨率选项,还是您始终知道要检索的确切图像?
在第一种情况下,您可能需要 NoSQL 类型的元数据存储,以便您可以查找图像组并使用应用程序逻辑从组中选择最佳图像文件。在后一种情况下,使用关系数据库或什至像 SimpleDB 或类似的高可用键值存储来获取文件元数据可能会更好。
此外,关于实际提供图像,您可能需要考虑实际使用 Cloudfront 来提供 S3 文件,因为这也会给您带来一些延迟优势。
关于您关于 S3 中“文件夹”的问题,重要的是要了解 S3 中没有真正的文件夹。人们通常使用类似文件夹的命名方案来命名他们的文件,以可能建议对存储桶中的文件进行一些分层分组,但实际上没有物理目录结构,也没有执行通常与目录结构相关联的事情的能力(例如列出一个目录中的所有文件)目录)。所有文件仅存在于存储桶级别。
这是一个files
表(如果使用 SQL 或变体):
file_id folder_id file_path
1 1 http://s3.aws.amazon.com/my-bucket/folder1/img1a.jpg
2 1 http://s3.aws.amazon.com/my-bucket/folder1/img1b.jpg
3 2 http://s3.aws.amazon.com/my-bucket/folder2/img2a.jpg
4 2 http://s3.aws.amazon.com/my-bucket/folder2/img2b.jpg
在这里,file_id 将是具有自动增量字段的主键,而 folder_id 将是具有索引的 int 列,以提供一种简单的方法来查找某个文件夹中的所有文件。