用于存储文件的SHA-1哈希

时间:2009-11-22 17:12:35

标签: ruby file-storage sha1

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

我不知道这意味着什么,但我所知道的是SHA-1和MD5是哈希算法。如果我使用this ruby script计算SHA-1哈希值,并且我更改了文件的内容(更改了哈希值),那么如何知道文件的存储位置呢?

我的问题是,实施SHA-1 /文件存储系统的基础是什么?

如果所有文件都在不断更改内容,是否有更好的存储方式,或者您只需要不断更新哈希?

我正在考虑如何创建一个通用文件存储系统,如GoogleDocs,Flickr,Youtube,DropBox等,您可以在不同的环境中重复使用(例如存储PubMed期刊文章或{ {3}}家庭作业和测试,或者仅仅是Flickr上的图像。我可能会将它们存储在Amazon EC2上。只是一些系统所以我可以说“这就是我从现在起99%的时间来存储文件”,所以我可以不再考虑构建一个可靠/一致的方式来存储文件并解决一些实际问题。 / p>

4 个答案:

答案 0 :(得分:2)

想法是来改变文件内容,而是通过使用哈希值来改变它的名称(和路径)。

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

我不确定使用 hash 而不是文件名(或者甚至是长的随机数)的动机,但这里有一些哈希appraoch的优点:< / p>

  • 磁盘上的文件名是统一的
  • 哈希值的上部或下部可用于命名目录,因此相对均匀地分发文件
  • 这个名字变成了一个代码,让某人很难    a)猜一个文件名    b)对图片进行分类(有人会窃取硬盘内容)
  • 能够从文件内容本身检索文件名和位置(假设哈希来自这样的内容。(不太确定哪个用例会涉及到这个......有点受到限制......)

使用哈希的一般兴趣是,与文件名不同,哈希是没有意义的,因此需要数据库关联图像和“书目”类型数据(上传者的名称,上传日期,标签,。 ..)

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

此外......一些哈希值会产生一个数值,通常以十六进制表示(如引用的SO问题中所示),这可能会使文件名长于它们所需的时间而被视为浪费,因而放置对文件系统的压力更大(更大的目录...)

答案 1 :(得分:2)

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


基本上,您首先根据文件内容计算SHA-1或MD5摘要(=哈希值)。

如果您有摘要(例如00e4f56c0de1c61fdb926e79e8a0a65bd12930c9),则会从摘要中生成文件位置和文件名。例如,您将摘要中的前几个字符拆分为目录结构,将其余字符拆分为文件名。例如:

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

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

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

答案 2 :(得分:1)

这个想法是你需要为照片找到一个名字,你可能想要在多个目录中分散文件。提出唯一名称的一种简单方法是使用哈希。

因此,哈希的开头被剥离出来用于多级目录结构,其余的哈希用于jpg的文件名。

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

答案 3 :(得分:1)

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

然而,这样做的缺点是当用户从您的应用程序中删除他们认为存在文件的内容时,您不能仅仅从磁盘上物理删除该文件,因为上传相同文件的其他用户可能仍在使用它。 / p>