Планируется создать файло обмнеик.
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 тут не обойтись что тогда?

Edd.DragonЗачем в базе хранить какие-то деревья?

Разве работа между сервером и юзером подразумевает это?

У юзера есть список файлов (возможно тегированный/категоризированный). Каждый файл имеет имя, дату, кол-во скачиваний и т.д. Для сервера каждый файл еще имеет путь, где он лежит.

Зачем этот список файлов юзера рассматривать как дерево?

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

неТоликValerik,

Обратите внимание на Webdav, как раз для ваших целей. Из плюсов этого протокола - можно обойтись без php и mysql.
А там можно организовывать общий доступ и открытый доступ к файлам и папкам?
Основанная идея, что бы пользователь мог делиться своими файлами с кем угодно.

Если бы можно было заводить пользователей в системе средствами php
И назначать права доступа на определенные папки и файлы по это конечно значительно облегчило задачу.
А так по любому придется хранить данные в базе данных, о том кому и какие данные доступны.

Hettvkleпропущено...
А почему нельзя то? У php есть интерфейс для вызова системных функций, а-ля командная строка.

Вы предлагаете поднять контролер домена?

Вот я про тоже, что это накладно будет при 100 000 пользователей.

Так как лучше то будет?

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

vkleValerikпропущено...


Вот я про тоже, что это накладно будет при 100 000 пользователей.Контроллер домена или какой-то другой способ реализации - не слишком важно на данный момент. Авторизация и аутентификация пользователей в любом случае будет. При большом количестве пользователей придется выделить наверно и не один сервер под это дело. Ага, и про резервирование этого центрального узла нервной системы не забываем. Хранение прав доступа тоже должно где то реализовываться. Будет ли это база на мускуле, оракле, или на файловой системе - в любом случае, будет какой то запрос вроде "юзер такой-то пытается получить доступ на [чтение|запись] к такому-то файлу. разрешить? (да|нет)". В файловых системах этот момент уже проработан, реализован и отлажен, в том числе, и на предмет ресурсожручести и надежности. Если есть готовая реализация, так почему бы ей не воспользоваться? Думаю, есть смысл рассмотреть этот вариант.

И сколько это будет стоить ?

vkleValerikИ сколько это будет стоить ?Что именно?

контролер домена