Comments 12
Представьте важное объявление на крупном сервере, уведомляющее всех (everyone) пользователей на нём: пользователи запустят приложение и прочитают сообщение, отправляя огромный объём трафика базе данных
У меня на архитектурных собеседованиях в месседж-сервисах протягивать сообщения через базку считается дурным тоном :)
А как вы данные храните, не в БД?
Ну, всмысле, вам же надо сохранить сразу кучу всего в случае тега всех пользователей - и факт сообщения, и признак непрочтенности, и признаки прочтения каждым из пользователей по факту.
Всё это даст нагрузку на БД просто по факту на большом числе пользователей, вне зависимости от того, как реализовывать.
UPD: я не писал ни разу мессенджеры, не очень представляю есть ли способ сделать это легко и просто.
Ну начнем с того что БД - совершенно точно плохой транспорт сообщений между пирами в онлайне. Для того, чтоб подгрузить историю тем, кто только подключается, очевидно, нужен какойто персистентный стораж (хотя если есть цель совсем по-босяцки делать, можно и собирать с других пиров например, вообще ничего не хранить самим, как олдскульный скайп), но совсем необязательно использовать что-то прям развесистое как кассандра - нам же нужен просто список сообщений в канале, начиная с какого-то момента. В этом месте уже напрашивается, например, кафка (только метаданные, типа офсетов, лучше бы держать в другом месте, чтобы не грузить ее мелочью). Или что-то подобное, где можно использовать особенность вашего ворклоада, а именно много записи, а чтение в основном большими кусками и с конца.
Мессенджеры я тоже не писал, но достаточно очевидно, что база тут рано или поздно станет ботлнеком, причем хорошо так прикопанным, легко не вытащить если что, так что лучше взять чтото, что можно без лишних проблем масштабировать неограниченно. А иначе придется приседать вот как в статье описано :)
Хороший вопрос, почему не кафка.
Если посмотреть на прошлую новость от дискорда (про 2017 год в шапке) - https://discord.com/blog/how-discord-stores-billions-of-messages
то видно, что как минимум два пункта упоминают рандомный доступ, а не просто "прочитать последнее". И вот тут я по кафке не уверен - есть ли простые способы делать рандомный доступ, поиск, это всё? Ну т.е. в БД обычно есть поиск и на него можно рассчитывать, может не всегда оперативно. Как искать в кафке - не имею понятия.
В целом, не вижу навскидку упоминаний кафки как инструмента, может для них какие-то особенности кафки недопустимы? GC там, производительность может не смогли обеспечить на тестовых проверках.
ПС: можно, наверное, делать оперативную работу в кафке, а хранение и случайный поиск через БД. Но тогда при большом числе обращений к БД выбор этой самой БД всё равно будет важен и статья будет вполне понятной "почему именно так".
Если без воды, то можно выделить два улучшения:
Cassandra --> ScyllaDB.
Сервисы, кеширующие запросы к СУБД.
Интересно, а схема БД осталась прежней? Упоминаний про изменения не увидел.
Ещё интересно, как они хранят запросы к БД - внутрипроцессно (в какой коллекции?), или в отдельном in-memory хранилище.
Интересно, в какую сумму им обошлась лицензия сциллы. Думаю, немалую, хотя, понятное дело, оно того стоило.
Как Discord хранит триллионы сообщений