Сообщение Хранение файлов пользователей на файловой системе от 25.12.2019 17:26
Изменено 26.12.2019 13:13 halo
Хранение файлов пользователей на файловой системе
Работаю над старым проектом, в котором пользовательские файлы хранятся прямо на файловой системе. Схема размещения файлов подчиняется следующему шаблону:
/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
Скрипты прямой миграции (но не обратной ввиду невозможности восстановить оригинальное имя файла из хеша) файлов со старой схемы реализуются просто.
Интересует: какие недостатки, кроме невозможности обратной миграции, есть у такого подхода + какие из уже существующих решений могут справиться с этой задачей?
Спасибо за советы.
/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.
/blobs/da/39a3ee5e6b4b0d3255bfef95601890afd80709 -- пустой файл
/files/backgrounds/162/05/562e534a175beadd7c5c5504af329b02e2ffbb -- символическая ссылка на /blobs/da/39a3ee...709
Скрипты прямой миграции (но не обратной ввиду невозможности восстановить оригинальное имя файла из хеша) файлов со старой схемы реализуются просто.
Интересует: какие недостатки, кроме невозможности обратной миграции, есть у такого подхода + какие из уже существующих решений могут справиться с этой задачей?
Спасибо за советы.
Хранение файлов пользователей на файловой системе
Работаю над старым проектом, в котором пользовательские файлы хранятся прямо на файловой системе. Схема размещения файлов подчиняется следующему шаблону:
/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
Короче говоря, я многое упустил при постановке вопроса (есть реляционная БД, веб), поэтому эти недоговорки очень повлияли на ответы, все из которых полагают, что конечный пользователь видит файловую систему. Не видит, ему всё-равно, поэтому есть возможность переделать механизм работы хранилища как угодно. Ёщё путаницу привнесло то, что имена файлов, загружаемых пользователём, есть именами файлов прямо на файловой системе в хранилище --- вообще без валидации, трансформации и т.д. так как это изначально. Там сейчас просто хаос, от которого я хочу избавиться.
Мне очень жаль, что потратил ваше время на ответы на неполный вопрос.
/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.
/blobs/da/39a3ee5e6b4b0d3255bfef95601890afd80709 -- пустой файл
/files/backgrounds/162/05/562e534a175beadd7c5c5504af329b02e2ffbb -- символическая ссылка на /blobs/da/39a3ee...709
Скрипты прямой миграции (но не обратной ввиду невозможности восстановить оригинальное имя файла из хеша) файлов со старой схемы реализуются просто.
Интересует: какие недостатки, кроме невозможности обратной миграции, есть у такого подхода + какие из уже существующих решений могут справиться с этой задачей?
Спасибо за советы.
------
EDIT1
Короче говоря, я многое упустил при постановке вопроса (есть реляционная БД, веб), поэтому эти недоговорки очень повлияли на ответы, все из которых полагают, что конечный пользователь видит файловую систему. Не видит, ему всё-равно, поэтому есть возможность переделать механизм работы хранилища как угодно. Ёщё путаницу привнесло то, что имена файлов, загружаемых пользователём, есть именами файлов прямо на файловой системе в хранилище --- вообще без валидации, трансформации и т.д. так как это изначально. Там сейчас просто хаос, от которого я хочу избавиться.
Мне очень жаль, что потратил ваше время на ответы на неполный вопрос.