php - 设计一个 MySQL 表来存储上传文件的数据

Question

我正在对我们的数据库进行一些重新设计，我正在构建新表来保存有关用户上传文件的数据。这里最重要的问题是用户可能会上传大量不同类型的文件。例如，他们可能会上传一个 mp3 文件作为歌曲、个人资料图片、个人资料封面照片等。不过，我遇到了一些设计和实际问题，我正在努力找出最好的方法来做到这一点。目前主要设计看起来像这样:

 ID | name | type | amazon_S3_info

ID: 为每个新上传自动增加一个 ID。
名称:上传的名称，例如文件名
类型:上传的类型，例如头像、封面照片、音频文件等。
amazon_S3_info: 我将所有文件存储在 S3 中，此字段保存数据，因此我可以生成 URL。我无法在此处存储 URL，因为我使用的是签名 URL，并且它们始终需要使用存储在该字段中的数据重新生成。

创建这样的表后，我就可以创建匹配表，例如，在其中创建用户 ID 和他们上传的个人资料图片的上传 ID 之间的关系等，这非常简单。

我最初的想法是将整个事情分解成多个表，这意味着我会为个人资料图片制作 1 个表格，为封面照片制作 1 个表格，等等。这在 php 端会变得有点令人头疼的原因是我有一个标准函数，它使用一个 ID 来检索这些文件的文件 URL。如果我有多个表，那么每种类型的上传都会有 1 个相同的 ID，从而使我当前的 URL 检索变得无用。这已经在整个站点中使用，并且重做会很麻烦，但是如果需要的话。

需要说明的是，这里将表格分成几张表的想法是速度。我的逻辑是，将可能有 2,000,000 行的单个表分解为 500,000 行的 4 个表会更有效。从这 500,000 行表中的每一个中提取数据会更快，或者这是一个错误的前提？

所以我想问你们很多问题是哪种数据库设计更好，尤其是当我们谈论扩展到相当大的时候？

Answer 1

对于数据库(以及一般的计算机)，您通常会担心 10 的因数，而不仅仅是 2 倍或 3 倍。

因此，将表按类型拆分为多个表，比如总共 5 个表而不是 1 个，一旦数据变得非常大，最终将无法解决性能问题。就像你说的，这是一种编程痛苦。 (基本上你会在没有算法的情况下手动分片......如果要分片也可以使用哈希分片算法来查找数据库/表)。

您的设计是标准的多对多设计。正确索引表格，这是您能做的最好的事情。

如果性能成为问题，您需要横向扩展。关系数据存储在这方面做得不好，但 NoSQL 数据存储可以。您也可以在 NoSQL 中拥有这些类型的引用。如果仍然可以更改设计，请查看 AWS DynamoDB(NoSQL 服务)。

编辑:回复评论...

@arian1123 根据我的经验，有一点(表大小)突然 mysql 开始表现不佳。您拥有的硬件(尤其是内存)越多，在这种情况发生之前表可以增长得越大。 ( killer 是连接。如果你不在大表上连接大表，那么一个大表本身可能会在足够的硬件下变得非常大，我已经处理了 10 亿+行表，其中只进行了读取而没有连接，这不是问题。)

在您自己的笔记本电脑上，您可能会看到 100k 表表现良好，而 1M 表表现不佳。如果数据不会再增长，而这就是您在生产中拥有的硬件的力量，那么拆分将是一个好主意。但是，如果您总是要增加表的大小，比如您提到的 50M，那么将其拆分只会在您可以无限拆分时才有帮助(比如每 200 万行再次拆分表)。如果你不想继续将一张 table 分成 4 到 20 到 100...所以我认为最好保留一张 table ，如果它不执行则查看其他数据存储类型。