Хранение файлов пользователей на файловой системе
От: halo Украина  
Дата: 25.12.19 17:26
Оценка:
Работаю над старым проектом, в котором пользовательские файлы хранятся прямо на файловой системе. Схема размещения файлов подчиняется следующему шаблону:

/files/$TYPE/$TENANT_ID/$FILENAME

где:

* $TYPE -- предназначение файлов, жёстко определяемое системой;
* $TENANT_ID -- код пользователя, обычная целочисленная строка без паддингов нолями, также определеяется системой;
* $FILENAME -- любое имя файла от пользователя.

Пользовательская иерархия файлов не допускается by design. Недостатки подхода, по крайней мере, такие:

* имена файлов уже на существующей специализированной платформе для развёртывания приложения не поддерживают не-ASCII символы (в смысле от 0 до 31 и от 128 и выше кроме точки и косой черты);
* файл с таким же названием запросто может перетереть другой файл с таким же именем (или не дать создать другой файл с таким же именем, хотя содержимое будет отличаться, не суть);
* все файлы для одного пользователя по определённому типу лежат в одной директории, что может теоретически превысить лимить записей в директории, но что вряд ли когда-нибудь случится.

Поскольку главной проблемой для заказчика пока является невозможность использовать не-ASCII символы в именах файлов, а не другие ограничения + я пока не рассматриваю другие подходы хранения файлов, можно переделать структуру директорий следующим образом:

/blobs/$HASHED_FILE
/files/$TYPE/$TENANT_ID/$HASHED_FILENAME

где:

* $HASHED_FILE -- имя файла, составляемое из хеша содержимого этого же файла в виде строки в base16;
* $HASHED_FILENAME -- символическая ссылка в виде хеша имени оригинального файла в base16, узывающая на блоб из директории /blobs.

Все три (на самом деле, нет: кроме второй) вышеуказанные проблемы в обозримом будущем покрываются таким подходом. Так, пока невозможный в этой системе /files/backgrounds/162/пустой-файл.bin мог бы быть представлен на файловой системе следующим образом (пускай хеш-функцией будет SHA-1):

/blobs/da/39a3ee5e6b4b0d3255bfef95601890afd80709 -- пустой файл
/files/backgrounds/162/05/562e534a175beadd7c5c5504af329b02e2ffbb -- символическая ссылка на /blobs/da/39a3ee...709

Скрипты прямой миграции (но не обратной ввиду невозможности восстановить оригинальное имя файла из хеша) файлов со старой схемы реализуются просто.

Интересует: какие недостатки, кроме невозможности обратной миграции, есть у такого подхода + какие из уже существующих решений могут справиться с этой задачей?

Спасибо за советы.

------

EDIT1

Короче говоря, я многое упустил при постановке вопроса (есть реляционная БД, веб), поэтому эти недоговорки очень повлияли на ответы, все из которых полагают, что конечный пользователь видит файловую систему. Не видит, ему всё-равно, поэтому есть возможность переделать механизм работы хранилища как угодно. Ёщё путаницу привнесло то, что имена файлов, загружаемых пользователём, есть именами файлов прямо на файловой системе в хранилище --- вообще без валидации, трансформации и т.д. так как это изначально. Там сейчас просто хаос, от которого я хочу избавиться.

Мне очень жаль, что потратил ваше время на ответы на неполный вопрос.
Отредактировано 26.12.2019 13:13 halo . Предыдущая версия . Еще …
Отредактировано 26.12.2019 10:51 halo . Предыдущая версия .
Отредактировано 26.12.2019 10:46 halo . Предыдущая версия .
linux java
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.