1

阅读本文后，使用 SHA-1 作为目录存储文件听起来是个好主意。

我不知道这意味着什么，但我只知道 SHA-1 和 MD5 是散列算法。如果我使用这个 ruby​​ 脚本计算 SHA-1 哈希，并且我更改了文件的内容（这会更改哈希），那么我怎么知道文件的存储位置？

那么我的问题是，实现 SHA-1/文件存储系统的基础是什么？

如果所有文件一直在更改内容，是否有更好的存储它们的解决方案，或者您只需要不断更新哈希？

我只是在考虑如何创建一个通用的文件存储系统，如 GoogleDocs、Flickr、Youtube、DropBox 等，您可以在不同的环境中重复使用这些系统（例如存储PubMed 期刊文章或Cramster作业和测试，或者只是Flickr 上的图像）。我可能会将它们存储在 Amazon EC2 上。只是一些系统，所以我可以说“从现在开始，我将在 99% 的时间里进行文件存储”，这样我就可以停止考虑构建一种可靠/一致的方式来存储文件并解决一些实际问题。

4

4 回答 4

4

首先，如果文件的内容发生变化，SHA-digest 方法的文件名不是很合适，因为文件的内容发生变化时，文件的名称和在文件系统中的位置必须改变。

基本上，您首先从文件的内容中计算出 SHA-1 或 MD5 摘要（= 哈希值）。

例如，当您有摘要时，您会从摘要00e4f56c0de1c61fdb926e79e8a0a65bd12930c9生成文件位置和文件名。例如，您将摘要中的前几个字符拆分为目录结构，将其余字符拆分为文件名。例如：

 00e4f56c0de1c61fdb926e79e8a0a65bd12930c9 => some/path/00/e4/f5/6c0de1c61fdb926e79e8a0a65bd12930c9.txt

这样您只需将文件的 SHA-1 摘要存储到数据库中。然后，您始终可以找到正确的位置和文件名。

目录通常还具有它们可以包含的最大文件数，例如每个目录最多 32000 个子目录和文件。基于这种散列的目录结构使您不太可能将太多文件存储到同一个目录中。同样使用这样的散列确保每个目录都有大约相同数量的文件，你不会遇到所有文件都在同一个目录中的情况。

于 2009-11-22T17:26:05.737 回答
2

这个想法不是通过使用哈希值来更改文件内容，而是更改其名称（和路径）。

使用散列更改内容将是灾难性的，因为散列通常是不可逆的。

我不确定使用哈希而不是文件名（甚至不是长随机数）的动机，但这里有一些哈希方法的优点：

  • 磁盘上的文件名是统一的
  • 哈希值的上半部分或下半部分可用于命名目录，从而相对均匀地分布文件
  • 名称变成了代码，让人难以 a) 猜出文件名 b) 对图片进行分类（有人会窃取硬盘内容吗）
  • 能够从文件内容本身检索文件名和位置（假设哈希来自此类内容。（不太确定哪个用例会涉及到这个......有点人为......）

使用散列的普遍意义在于，与文件名不同，散列是无意义的，因此需要数据库将图像和“书目”类型数据（上传者名称、上传日期、标签……）关联起来

在考虑它时，重新阅读引用的 SO 响应，与随机数相比，我并没有真正看到哈希的太多优势......

此外......一些哈希产生一个数值，通常以十六进制表示（如在引用的 SO 问题中所见），这可能被视为浪费，因为文件名比它们需要的长，因此对文件系统（更大的目录...）

于 2009-11-22T17:20:01.690 回答
1

这个想法是您需要为照片命名，并且您可能希望将文件分散在多个目录中。想出唯一名称的一种简单方法是使用哈希。

因此，散列的开头被剥离用于多级目录结构，其余散列用于 jpg 的文件名。

这具有检测重复上传的额外好处。

于 2009-11-22T17:25:47.997 回答
1

我看到使用哈希存储文件的一个优点是文件数据只需要存储一次，然后可以在数据库中多次引用。如果您有不同的用户上传完全相同的文件，这将节省您的空间。

但是，这样做的缺点是当用户从您的应用程序中删除他们认为存在的文件时，您不能只是从磁盘上物理删除该文件，因为上传相同文件的其他用户可能仍在使用它。

于 2011-02-10T20:48:03.160 回答