Я изучаю альтернативный сценарий использования плагина Discourse Chat и у меня есть несколько вопросов о его предельных возможностях, в частности касательно хранения данных и интенсивного использования API.
Для контекста: мы ищем систему комментариев с ветвлением (threaded). Функция «ответы в ветках» (threaded replies) внутри плагина Chat обеспечивает пользовательский опыт, гораздо более близкий к нашим потребностям, чем стандартная структура тем/сообщений. По этой причине мы рассматриваем возможность использования каналов чата в качестве постоянных веток комментариев.
Из-за такого сценария использования нам потребуется хранить историю чата неограниченно долго. Это приводит к нашей главной проблеме: производительности при очень больших масштабах.
Наш прогнозируемый объем использования высок:
Общее количество сообщений: от 1 до 10 миллионов.
Каналы: примерно от 150 до 200.
Наши основные вопросы:
Возможно ли полностью отключить хранение чата или увеличить его лимит для поддержки указанного количества сообщений? Например, установив период хранения в 0 или очень большое число.
Как это повлияет на производительность API? Мы планируем активно использовать API плагина Chat для интеграции с нашей внешней системой. Наш основной паттерн доступа — получение сообщений в хронологическом порядке (от новых к старым) как для основных каналов, так и для веток. Создаст ли такая частая опросная активность (polling) API на каналах с огромной историей значительную нагрузку на сервер?
Каково будет общее влияние на производительность сервера и базы данных при постоянном хранении миллионов сообщений чата? В частности, как это повлияет на:
Использование процессора (CPU) и оперативной памяти (RAM) сервера?
Общую отзывчивость сайта?
Существуют ли известные «точки отказа» или мягкие лимиты, при которых производительность системы начинает значительно снижаться при такой нагрузке?
Мы понимаем, что это нетипичное использование плагина чата и что отключение хранения данных не является лучшей практикой. Наша цель — определить архитектурные пределы системы — как в интерфейсе, так и через API — прежде чем мы примем решение о таком подходе.
Любые советы от команды или участников сообщества, которые уже запускали чат в больших масштабах, были бы чрезвычайно ценны.
Привет @Nima1, я могу начать отвечать на некоторые из этих вопросов:
Да, это возможно. Вы можете установить значение chat channel retention days в «0», чтобы сохранять сообщения навсегда — но учитывая масштаб вашей деятельности, вы правы, задаваясь вопросом о влиянии на производительность. Также отмечу, что у нас пока нет поддержки поиска по сообщениям чата (это мы обсуждаем, но пока не планируем). Это означает, что даже если вы будете сохранять сообщения навсегда, учитывая высокую нагрузку на проект, участникам может оказаться трудно находить конкретные сообщения.
Я не уверен в ответах на эти вопросы, давайте я уточню у некоторых инженеров, которые больше всего работали с чатом, чтобы узнать их мнение.
Также мне было бы интересно узнать больше о вашем сценарии использования — готовы ли вы поделиться дополнительными деталями о том, к чему вы стремитесь?
Спасибо за ответ и за то, что уточнили информацию в инженерной команде. Я с радостью расскажу подробнее о нашем случае использования.
Мы создаем сообщество для энтузиастов криптовалют. Для каждого крупного криптоактива мы хотим создать отдельный постоянный канал для обсуждения в реальном времени.
Мы обнаружили, что стандартная модель тем/сообщений не совсем подходит для этого, потому что:
Темп и формат: Обсуждения проходят быстро и состоят из коротких сообщений, обновлений и реакций, что идеально соответствует формату чата.
Поток информации: Нашим пользователям нужно видеть самые новые сообщения первыми и прокручивать вверх для просмотра недавней истории, что является стандартным поведением в чате. В то же время темы предназначены для чтения в хронологическом порядке — от самых старых к самым новым.
Вложенные ответы в плагине чата и отображение в обратном хронологическом порядке идеально соответствуют пользовательскому опыту, который мы хотим создать.
Наша главная проблема — масштаб. Поскольку у нас будет отдельный канал для каждого актива, мы ожидаем необходимость в сотнях каналов, каждый из которых может содержать очень длинную историю. Именно поэтому нас так интересуют ограничения производительности.
Мы намерены использовать Discourse благодаря его мощным функциям модерации, управления пользователями и геймификации, которые критически важны для создания здорового сообщества.
С нетерпением жду мнения инженеров. Еще раз спасибо!
После обсуждения с нашей командой, боюсь, мы не можем с уверенностью сказать, как на производительность повлияет такой объём сообщений — у нас пока немного пользователей, работающих с чатом в таком масштабе, и на это сильно повлияет то, где вы разместите свой сайт.