Сообщение Хранение файлов пользователей на файловой системе от 25.12.2019 17:26
Изменено 26.12.2019 10:51 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
Скрипты прямой миграции (но не обратной ввиду невозможности восстановить оригинальное имя файла из хеша) файлов со старой схемы реализуются просто.
Интересует: какие недостатки, кроме невозможности обратной миграции, есть у такого подхода + какие из уже существующих решений могут справиться с этой задачей?
Спасибо за советы.
/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
Скрипты прямой миграции (но не обратной ввиду невозможности восстановить оригинальное имя файла из хеша) файлов со старой схемы реализуются просто.
Интересует: какие недостатки, кроме невозможности обратной миграции, есть у такого подхода + какие из уже существующих решений могут справиться с этой задачей?
Спасибо за советы.