Добрый день.
Подскажите пожалуйста вариант как организовать архитектуру приложения.
Система будет написана на php, база данных mysql.
Вкратце что представляет из себя система:
В системе будут множество пользователей, каждый пользователь может создавать сообщения в которые может загружать до 10 файлов. Этих сообщений может быть сколько угодно много, соответственно и файлов может быть очень много(как маленьких, так и больших). К сообщениям, а также к файлам пользователи могут добавлять тэги, тэги создаёт сам пользователей. Пользователи могут создать сколько угодно много тэгов и добавить к каждому файлу/сообщению сколько угодно много тэгов.
Пользователь может делать поиск по тэгам.
Собственно прошу совета:
1. как правильно организовать файловое хранилище? Допустим у каждого пользователя есть своя папка, где хранятся его загруженные файлы, но этих файлов могут быть сотни тысяч и тогда, как я понимаю могут быть проблемы у самой файловой системы.
2. как правильно организовать базу данных с тэгами и поискам по тегам? Как максимально оптимизировать, чтобы была наименьшая нагрузка на базу данных?
Если может где-то в описании допустил неточности - прошу заранее меня простить.
Если я вас правильно понял.
Допустим у меня в базе каждый пользователь создал 10 000 сообщений, пускай для каждого сообщения он подцепил по 5 тегов. При этом 3 тэга уникальные новые. Для 1000 пользователей мы имеем:
база сообщений 10 000 000 строк
база отношения сообщений к тэгам 50 000 000
база тэгов 30 000 000 строк
Не будет ли такая схема слишком затратной в плане ресурсов для базы данных?
Потом вывод результатов:
Мы выводим 50 сообщений, для каждого из них нужно вывести ещё и названия тэгов, так? Тэгов может быть от 0 и до 100. То есть после того как мы сделали запрос на поиск по тэгам мы длякаждого результирующего сообщения должны будем ещё и выбрать его тэги, верно? Итого запрос на поиск всех соответствующих сообщений + 50 запросов на получение тэгов для этих сообщений.
diver23: да, именно так, и это нормально. Потом можно уже оптимизировать, вводить денормализацию тегов что бы ускорить выборку (помимо связей хранить массив тегов в сериализованном виде), тогда у нас и поиск по тегам будет работать хорошо и с джойнами не надо париться (или вы хотели для кадой записи отдельно запросы делать?). Проблемы со скоростью поиска в такой базе решаются индексами и выделением достаточного количества оперативки под них. Если у вас предвидятся такие нагрузки, то значит так надо.
10 000 сообщений на пользователя это много, это очень много. 10 000 пользователей по 1000 сообщений хоть немного более вероятный сценарий. В целом обычно это будет ДО 1000 сообщений с пользователя, в среднем думаю будет где-то сотня сообщений на пользователя.
Спасибо за ответ.
>вводить денормализацию тегов что бы ускорить выборку (помимо связей хранить массив тегов в сериализованном виде), тогда у нас и поиск по тегам будет работать хорошо и с джойнами не надо париться
Об этом как-то не подумал, спасибо.
"файлов могут быть сотни тысяч и тогда, как я понимаю могут быть проблемы у самой файловой системы"
А по файловой системе подскажете?
diver23: проблем быть не должно, вы можете упереться только в лимит файлов для каталога для вашей файловой системы, разве что... ну и если что всегда можно использовать распределенные хранилища и файловые системы, или разбрасывать на несколько серверов. Тут как говорится вариантов слишком много.
Единственное поскольку вы используете PHP рекомендую вам сразу оперировать файлами через какую абстракцию типа Flysystem и тогда менять хранилища будет не больно.
diver23
> вводить денормализацию тегов что бы ускорить выборку
отметьте на будущее: стандартный цикл разработки структуры БД (там, где есть схема) - нормализация "до упора", денормализация по необходимости для ускорения конкретных (!) запросов. Обычно для 80% запросов нормализованная структура вообще проблемы не составляет, и только 20% и менее самых тяжелых или самых частых (например, отрабатывающих на главной странице) требуют введения избыточных данных.
Средний
