二进制数据存储方案(保存用户上传的文件)

Question

在我们的应用程序中，我们目前正在将二进制数据保存到数据库中(我知道，这很糟糕；但这是遗留的东西，这不是我的决定)。我们试图将这些数据迁移到一个外部设备上，而我正试图想出一个方案来保存这些文件。

我们有多个租户，我想给每个租户一个目录。我的方案是使用租户的前三个字母构建路径。因此，如果您有一个名为apple的租户，那么它的文件将位于/a/p/p/apple。在这些目录中，我将保存文件。对于这些文件，我想要生成一个随机的6个字符的字母数字名称(暂时只是小写字符，因为内部原因)。因此，如果我们生成一个名为6a8jxo的文件名，它将存储为<tenant>/6/a/6/6a8jxo。使用这种策略，每个租户最多可以拥有大约9,160亿个唯一文件(不是我们试图保存的文件数量)，每个目录最多可以保存46,656个文件。如果我使用一个5个字符的名称，我们最多将有605亿个唯一文件，每个目录有1296个文件。

这种方法有什么缺点吗？我意识到某些目录可能只包含一个或两个文件，但在我看来，这不是一个大问题。

我的同事不想这样做；他希望在数据库中使用一个自动递增字段，然后将目录结构基于十六进制值(我假设为32位)，而不是使用租户。使用他的策略，十六进制值将被使用如下:文件将存储在位于<tenant>/aa/bbb的目录中，其中aa是十六进制值的前两个字符(最重要的咬口)，bbb是接下来的三个字符。他的理由是，他只想创建新的目录时，一个人填补，而不是有许多，部分填充目录。

这种方法在代码方面带来了许多困难，而且我不认为完全填充目录可以证明需要为此付出额外的努力。

还有其他我没有考虑过的策略或方法吗？

Answer 1

散列目录(不要与生成文件名的散列相混淆)从而将其分解为多个目录的想法是一个好主意。如果它的多租户，您可能有一个客户的数据库id。用唯一的id (自动增量或其他)跟踪数据库中文件的存在是个好主意。因此，您可以简化您的方法，并执行如下操作：

/(client id)/(thousands)/(file-id).txt

为租户创建一个目录，然后根据文件的唯一数据库id生成文件路径，将其分组为数千或数万。因此，对于租户编号8的自动递增行id为53445的文件可能如下所示

/8/53/53445.txt

如果需要支持更分布式的设置，则在跟踪文件时可以使用uuid而不是自动增量字段。我不会使用客户端的名称作为路径的一部分，因为名称会改变，您可能会遇到一个客户端，其名称中的字符不能作为文件名的一部分使用--只需跳过所有的复杂性，使用数据库id即可。

按租户分解文件在技术上可能没有必要(我通常不会)，但如果您需要将这些文件提供给客户端，则可能会帮助您。这样做是否明智，取决于应用程序的性质。