Планируется создать файло обмнеик.
Php +mysql +Apache+ nginx
Хотел узнать мне опытных людей как лучше организовать структуру папок пользователей в базе данных или в файловой системе.
Однозначно документы будут храниться на диске в базе данных только ссылки на них.
Поскольку файлов будет очень много и постоянно будут скачиваться и закачивается, объемы файлов до 10ГБ. Даль больше.
Каждый пользователь может создавать свои папки, сколько угодной вложенности.
Есть идея хранить структуру папок в базе данных. Это позволяет:
1. легко выполнять операции переноса файлов с одной папки в другую
2. организовать доступ к папке тем пользователя, которым нужно.
3. Удобно при использование нескольких файловых хранилищ т.е. файлы в одной папке могут храниться на разных серверах.
4. Ну и нет нагрузки на файловый сервер.
А вот из минусов, какие могут быть при такой реализации?
Не будет ли проблем с базой когда кол-во пользователей разрастется до 100 000 и более?

А прямого доступа к файлам не будет.
Серверу будет посылаться запрос пита [files/gjeqrwqopiki13rp23ioiripo12]
Php согласно этому hash коду находит данные в базе данных и через nginx отдает файл.

Мне вот что интересно.
Что будет работать быстрее такой вот подход хранение дерева папок пользователя в базе данных или же все таки файловой системе. Когда кол-во пользователей вырастет больше 100 000 и у каждого пользователя будет свое дерево. Я так понял в данном случаи, что для быстрой работы с базой обычная древовидная структура базы не подойдет (типа ID, PARENTID, …. Идт).?

vkleValerikЧто будет работать быстрее такой вот подход хранение дерева папок пользователя в базе данных или же все таки файловой системе. Когда кол-во пользователей вырастет больше 100 000 и у каждого пользователя будет свое дерево.А в том ли вопрос то?
Насчет файловой системы: делайте такую организацию, чтоб в одной папке было не более тысячи элементов (файлов или папок). При бОльших количествах много времени уходит на чтение каталога. Это в любом случае, независимо от того как будете строить дерево (по базе или по ФС). Но это так, к сведению.
Далее, при замахе на оверстотыщ юзеров скорее всего одного то сервера и не будет достаточно. Потому будете хранить в БД не только путь до файла в ФС, но и имя сервера, который этот файл отдавать будет. И еще придумаете как этот сервер будет разбираться, можно ли юзеру отдавать этот файл или нет. Скорее всего.

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

Edd.DragonКогда нагрузка по-настоящему станет горячей, ни то, ни другое в чистом виде не будет максимально эффективным.

Ну какие это объемы будут? Там уже о кластеризации, кешировании и прочей лобуде думать надо. Даже о том, как роутинг вообще от php отобрать и отдать специализированному более скорострельному решению. А не о том, что не по приколу ли в БД засунуть?


Это какому решению мона отдать? мона пример?

Edd.DragonНу а так, если делить мир на белое и черное, то большие файлы пхать и читать в БД сомнительная польза, а вот миллионы пузатой мелочи меньше размера пары минимальных блоков записи/чтения - это уже пошесть, от которой голова чешется. Интуитивно возникает желание как-то это все культурно сгрузить и скатекой прикрыть, чтобы не маячило =))

Сомневаюсь что в БД хранить хорошая затея, будет большая нагрузка на базу.

РенатValerikТак это и не планируется хранить все на одном сервере.
По мере разрастания, и файловый сервер создавать новый и базу новую заводить.
Про то что в папочке хранить не более тысячи элементов это понятно, пока идея хранить файлы в папках по времени закачки каждый час новая папка.
Про то как отдавать пользователю файл или нет, может я чего-то не до понимаю? Пока идея такая серверу передается hash ID файла по нему в базе смотрим кому принадлежит этот файл и кто его запрашивает если у этого пользователя есть доступ к этому файлу то отдаем его.
1. по поводу если через файловую систему делать: А чем вам не устраивает вариант: array_merge(scandir(), scandir()....) ?
2. по поводу 100,000... ну не такие большие это цифры, вполне нормально должна справляються
Еще никто не отменял
а) шардинг
б) репликация
что позволит вам хоть 1000,000,000 файлов хранить.

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

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

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

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

Не понял, в данном случае лучше будет дерево папок хранить в БД?
Я правильно вас понял?

HettБолее того, одинаковых файлов будет много и хранить все дубликаты не имеет смысла. В случае с хранением структуры в ФС можно было бы конечно создавать вторую жесткую ссылку на файл, но в случае с распределенной системой у вас этого не получится.

Хорошо. Где хранить структуру папок (в базе понятно).
Тогда другой вопрос, как хранить все эти деревья в базе что бы запросы с таблицей дерева папок быстро работал.
Я имею ввиду, вот у меня 100 000 пользователей, каждый их которых на создавал свое дерево папок, как будет работать MySQL при такой нагрузке?
И как лучше организовать структуру такой таблице, что бы пользователь мог быстро получить всю структуру своих папок? Понятно, что простым ID, PARENTID тут не обойтись что тогда?