Наиболее оптимальный способ хранения большого количества файлов

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

Если на начальном этапе - вполне хватит хранения всех фото или аудио файлов в одной папке "files", а идентификатор пути к файлам можно поместить в БД... Или же стоит продумать оптимизацию хранения в файловой системе заранее? (например, группировать добавленные файлы по месяцам в папках jan/feb/mar/apr/may etc...)

Благодарю за ответ!

большое количество - это сколько? (примерно) Может для вас 1000 - это много

Стоит разделять средствами FS в любом случае. Потому как вдруг - сейчас кажется что ничего, и так хватит, а через полгодика потребуется много. (Наперед не узнать, и я советую проектировать и затем реализовывать так, чтобы масштабирование было как часть проекта).

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

Stierus, я думаю за месяца 3-4 достигнет 1000.

EuGen,
FS - Архитектура «файл-сервер»?

Как вы думаете, разделение файлов по следующей структуре (папки):

(data) -> (год) -> (месяц) -> (images/audio/video/files)

или же

(data) -> (images) -> (год) -> (месяц)
(data) -> (audio) -> (год) -> (месяц)
(data) -> (video) -> (год) -> (месяц)
(data) -> (files) -> (год) -> (месяц)

К дате я бы привязываться не стал ... к первым символам в названии файла тогда уж , к виду контента, которому относится (/images/forum/... /images/avatars/ и тд) Ты же не описываешь всей ситуации - как тут советовать

Да, по дате точно не стоит. А то сейчас и дня хватает, а потом может и папки часов потребуются.
По чему-то независимому от количества, как Stierus предлагал, к примеру.
FS - File System, архитектура веб-приложений всегда "клиент сервер".

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

А почему бы не создавать папки вида день-месяц-год? Например 01052009. Или месяц-год.

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

Ты прав мэн, как нарисую схему базы - я выложу её сюда.

(Отредактировано автором: 17 Апреля, 2009 - 14:57:27)

Немного задержался, но всё таки нарисовал
На схеме - каждый овал, прямоугольник - это отдельная таблица базы данных. Цвета я разделил, для визуальной группировки взаимосвязанных таблиц.
Стрелки выставил, что бы тоже определить связь таблиц.

Три таблицы категорий (зелёного цвета), которые имеют общую связь с аппаратурой (equipment) - служат для будущего разделения аппаратуры на категории, а так же удобной навигации по ним.

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

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

(Отредактировано автором: 26 Апреля, 2009 - 07:33:46)