Хэш SHA-1 для хранения файлов
-
21-09-2019 - |
Вопрос
После прочтения это, это звучит как отличная идея хранить файлы, используя SHA-1 для каталога.
Однако я понятия не имею, что это значит, все, что я знаю, это то, что SHA-1 и MD5 являются алгоритмами хеширования.Если я вычислю хэш SHA-1, используя этот рубиновый скрипт, и я изменяю содержимое файла (что изменяет хэш), как мне узнать, где тогда хранится файл?
Тогда мой вопрос заключается в том, каковы основы реализации SHA-1 / файловой системы хранения?
Если содержимое всех файлов постоянно меняется, есть ли лучшее решение для их хранения, или вам просто нужно постоянно обновлять хэш?
Я просто думаю о том, как создать общую систему хранения файлов, такую как GoogleDocs, Flickr, Youtube, DropBox и т.д., Что-то, что вы могли бы повторно использовать в различных средах (например, для хранения Опубликованный журнальные статьи или Зубрила домашние задания и тесты, или просто изображения, как на Flickr).Я бы, наверное, сохранил их на Amazon EC2.Просто какая-то система, чтобы я мог сказать: "с этого момента я буду хранить файлы именно так в 99% случаев", чтобы я мог перестать думать о создании надежного / согласованного способа хранения файлов и заняться некоторыми реальными проблемами.
Решение
Прежде всего, если содержимое файлов меняется, подход filename из SHA-digest не очень подходит, потому что имя и расположение файла в файловой системе должны меняться при изменении содержимого файла.
По сути, вы сначала вычисляете дайджест SHA-1 или MD5 (= хэш-значение) из содержимого файла.
Например, когда у вас есть дайджест, 00e4f56c0de1c61fdb926e79e8a0a65bd12930c9
, вы генерируете местоположение файла и имя файла из дайджеста.Например, вы разделяете первые несколько символов из дайджеста на структуру каталогов, а остальные символы - на имя файла.Например:
00e4f56c0de1c61fdb926e79e8a0a65bd12930c9 => some/path/00/e4/f5/6c0de1c61fdb926e79e8a0a65bd12930c9.txt
Таким образом, вам нужно только сохранить дайджест файла SHA-1 в базе данных.После этого вы всегда сможете узнать нужное местоположение и имя файла.
Каталоги обычно также имеют максимальное количество файлов, которые они могут содержать, например, максимум 32000 подкаталогов и файлов на каталог.Структура каталогов, основанная на таком типе хеширования, делает маловероятным, что вы храните слишком много файлов в одном каталоге.Также, используя подобное хэширование, убедитесь, что в каждом каталоге примерно одинаковое количество файлов, вы не попадете в ситуацию, когда все ваши файлы находятся в одном каталоге.
Другие советы
Идея заключается в том, нет изменить содержимое файла, а точнее его имя (и путь), используя хэш-значение.
Изменение содержимого с помощью хэша было бы катастрофическим, поскольку хэш обычно необратим.
Я не уверен в мотивации использования хэш вместо имени файла (или даже вместо длинного случайного числа), но вот несколько преимуществ хэш-оценки:
- имена файлов на диске одинаковы
- верхняя или нижняя части хэш-значения могут использоваться для присвоения имен каталогам и, следовательно, для относительно равномерного распределения файлов
- имя становится кодом, что затрудняет кому-либо задачу а) угадать имя файла б) классифицировать изображения (может ли кто-нибудь украсть содержимое жесткого диска)
- иметь возможность извлекать имя файла и местоположение из самого содержимого файла (при условии, что хэш получен из такого содержимого.(не совсем уверен, какой вариант использования будет включать это...немного расстроен ...)
Общий интерес использования хэша заключается в том, что в отличие от имени файла, хэш не имеет смысла, и поэтому требуется, чтобы база данных связывала изображения и данные "библиографического" типа (имя загрузчика, дата загрузки, теги, ...)
Размышляя об этом, перечитывая ответ SO, на который ссылается ссылка, я на самом деле не вижу большого преимущества хэша по сравнению, скажем, со случайным числом...
Более того...некоторые хэши выдают числовое значение, обычно выражаемое в шестнадцатеричном формате (как показано в приведенном вопросе SO), и это может рассматриваться как расточительное, поскольку имена файлов становятся длиннее, чем они должны быть, и, следовательно, повышается нагрузка на файловую систему (большие каталоги ...)
Идея заключается в том, что вам нужно придумать название для фотографии, и вы, вероятно, захотите разбросать файлы по нескольким каталогам.Один из простых способов придумать уникальное имя - это использовать хэш.
Таким образом, начало хэша было удалено для многоуровневой структуры каталогов, а остальная часть хэша была использована для имени файла jpg.
Это дает дополнительное преимущество в обнаружении дублирующихся загрузок.
Одно из преимуществ, которое я вижу при хранении файлов с использованием их хэша, заключается в том, что данные файла нужно сохранить только один раз, а затем на них можно ссылаться несколько раз в вашей базе данных.Это сэкономит вам место, если у вас разные пользователи, загружающие один и тот же файл.
Однако недостатком этого является то, что когда пользователь удаляет из вашего приложения файл, который, по его мнению, там находится, вы не можете просто физически удалить файл с диска, потому что другие пользователи, загрузившие точно такой же файл, могут все еще использовать его.