Нормальный ли метод хранения файлов на сервере?

Question

[Михаил Шатилов]

Задача: юзер без регистрации может заливать и скачивать свои файлы. В дальнейшем он может зарегистрироваться и получить дополнительный функционал.

Идея хранения файлов.
Есть класс-хранилище, способный писать, читать и хранить массив файлов по ключу (md5). Структура:

/user_files/ef/eff7d5dba32b4da32d9a67a519434d3f.zip
/user_files/d5/d58e3582afa99040e27b92b13c8f2280.zip

Есть класс-контроллер, управляющий классом-хранилище (с контролем доступа). Генерация ключа происходит, например, по такой схеме: md5(user_id+file_name+...). В базе хранится user_id, оригинальное имя файла и ключ.
Скачивание (отдается через php):

/user-files/download/d58e3582afa99040e27b92b13c8f2280/ -> Мой документ.zip

1. Все файлы на 1 сервере.
2. Высоких нагрузок не ожидается.

Есть ли минусы в данной схеме?

Answer 1

[zooks]

MD5 не уникальна - чисто теоретически они могут повторяться.

Comments

[Михаил Шатилов]

знаю, но это не особо важно, т.к. будет меньше ляма файлов

Answer 2

[Виталий Перетятько]

И еще "Скачивание (отдается через php)" можно заменить на скачивание через X-Accel-Redirect если стоит nginx

Answer 3

[Александр Вульф]

Нормальная система.

Answer 4

[Philipp]

Схема неплохая, но лучше использовать sha1_file() для обнаружения одних и тех же файлов. Т.е. сначала генерировать контрольную сумму, потом искать в базе по ней дубликат, если он есть, проверять совпадение файлов (это может занять время, должен быть продуман фоновый процесс обработки). Если файлы одинаковые, то нет смысла хранить копии. В таком случае схема в базе немного усложняется, но значительно экономится место на диске из-за дедупликации.
Метаданные для каждого пользователя необходимо хранить индивидуально и ссылку выдавать уникальную для каждого пользователя.

Comments

[FanatPHP]

Схема хорошая, но случаев, когда много дублей, не так уж и много. Плюс, вместо невнятного "схема усложняется", следовало описать реализацию классической системы ссылок и сборки мусора - удаления файлов, на которые нет больше ссылок. А sha не обязательно. Я бы наоборот хотел поймать коллизию md5 - это было бы круто. Но уж очень маловероятно.

[Philipp]

FanatPHP: наверно классическая схема сборки мусора на то и классическая, что ее должен знать любой программист?

[FanatPHP]

Ой :) Только не на тостере и только не в с тегом "похапе" :)

Answer 5

[Александр Аксентьев]

Вполне нормальная система
Сам делаю почти так же. Только файлы "безликие". Название и мета в базе.
Отдается через php, сами папки естественно закрыты.

• /uploads/03.05.2014/2a7db79344e0bfe58975de0b505310c6
• /uploads/03.05.2014/37d7af3859d055fc8685334b03b052dd

Comments

[FanatPHP]

Ага, а потом импортируем 100500 файлов за раз. И все в одну папку.

[Rsa97]

Если уж создавать каталоги по дате, то называть лучше в стиле год-месяц-день (2014-05-03), искать вручную будет гораздо проще.

[Михаил Шатилов]

По вашему совету решил хранить файлы без расширения, т.к. будет легче дергать по ключу

Answer 6

[Андрей Буров]

Вполне nginx.org/ru/docs/http/ngx_http_proxy_module.html#...

Answer 7

[FanatPHP]

Минусы стандартные.

• На миллион файлов одного уровня вложенности хватит, но на десяти уже начнутся проблемы, когда в каждом каталоге будет по несколько десятков файлов. Я помню про "не больше ляма", но "640К памяти хватит всем...", ога.
• Заведомо неуникальные имена файлов пользователей. Не забыть прибавлять к хэшируемой строке микротайм.
• Следить, чтобы у хэшируемой строки не было общего префикса (скажем, полного пути к файлу на диске) - тогда первые символы хэша будут распределяться неравномерно, и неравномерно заполнять каталоги.