Какую DB для мессенджера выбрать?

Hello!

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

В общем сервер сайд код уже почти весь готов. Использовал Dart (странный выбор, я знаю), WebRTC, Redis, RabbitMQ и Postgres. Групповые чаты работают, видео звонки работают, все скейлится ок, кроме БД. Насколько я знаю, Postgres не скейлится на несколько нод без танцев с бубном. Я не БД инженер, знаю по этой теме не много и не думаю, что смогу разобраться, как правильно скейлить Постгрес. Слишком глуп :) Использовал PG просто потому что только его и знаю немного, и, если честно, я думал, что он скейлится из коробки, поэтому даже не гуглил ничего.

Сейчас ищу другие варианты. Сначала обратил внимание на Cassandra. Легко скейлится и используется во многих похожих проектах. Можно использовать group id в качестве partition key, тогда все сообщения из группы будут храниться на одной ноде. Но в Кассандре нет джойнов. Когда юзер появляется онлайн, нужно вытащить непрочитанные сообщения из множества разных групп, в которых он состоит, а, значит, так как нет джойнов, придется делать кучу разных запросов, что, конечно, так себе идея.

Затем гугл привел меня к CockroachDB. Скейлится легко, синтаксис Постгреса, все вроде идеально. Не самая быстрая БД, но мне не требуются супер быстрые инсерты, так как если юзер онлайн, то сообщение ему отправляется до того, как оно пишется в БД.

Что можете посоветовать? Что выбрать? Может, какой-то другой вариант? БД столько разных, что голова кругом.

И, пожалуйста, не нужно советов вида, что мне ничего этого не требуется, легко обойдусь одним инстансом Постгреса, преждевременная оптимизация это глупо, сначала запусти в прод, а уже потом, если вдруг Постгрес перестанет справляться, будешь думать о скейле и тд и тп. Я знаю, что мне ничего этого не требуется. Это, можно сказать, просто практика, тренировка реализации более менее сложной архитектуры.
  • Вопрос задан
  • 1719 просмотров
Пригласить эксперта
Ответы на вопрос 7
@xfg
Популярные NoSQL решения не используют джойны поскольку это в любом случае ведет к сетевым походам на различные шарды. Даже если это скрыто от пользователя. Соответственно в распределенной системе вы не получите джойнов как в Postgre. Более того, если пытаться шардировать Postgre, у вас и там возникнет проблема джойнов между шардами и от подобных джойнов придется отказаться.

Проблема в том, что вы подходите к хранению данных в NoSQL также как в RDBS. Это неверно и для распределенных систем вполне себе допустимо хранение избыточных данных. Вы вполне например можете записывать новое сообщение на множество шардов, на шард где хранятся сообщения группы и на шарды с юзерами. Делать это можно по событию, которое генерируется при создании сообщения, далее оно попадает в rabbitmq, а оттуда подписчикам, которые запишут сообщение на нужные шарды.

Таким образом, вы всегда сможете прочитать вместе с пользователем его новые сообщения с одного шарда. Делают по разному, основная мысль в том, чтобы максимально упростить сбор данных, для того или иного экрана приложения.

Например в социальных сетях так советуют собирать ленту новостей. Система принимает пост от пользователя, а затем сервис в фоновом режиме раскладывает этот пост по всем пользователям (шардам), которые этот пост могут увидеть. Соответственно отображение ленты новостей становится тривиальной задачей. Также нужно быть готовым к тому, что в распределенных системах принята согласованность по событию вместо согласованности по транзакции. Проще говоря, не все пользователи увидят новый пост в своей ленте мгновенно, а спустя некоторое время и для больших проектов вроде facebook или amazon это ок. Из-за этого иногда на facebook можно обновлять ленту с переодичностью в секунду и в какой-то момент получить новый пост у которого дата добавления была 1 минуту назад.

По базам данных можно выбрать любую популярную с поддержкой шардинга из коробки, которая больше нравится или с которой лучше знакомы. Знакомы с кассандрой, отлично используйте её, знаете монго, берите её. Не знаете ничего, почитайте плюсы и минусы обоих систем и решите для себя, что больше вам подходит.
Ответ написан
@GWindoz
Никто ничего не сказал о CockroachDB. Она ведь соответствует требованиям автора вопроса. И действительно работает с join'ами и транзакциями
Ответ написан
@lubezniy
Master-slave полезно на случай отказа одного сервера, но по нагрузке и оно имеет свои пределы; и что потом будете делать? Более-менее сложная архитектура подразумевает встраивание сервера БД в архитектуру приложения так, чтобы оно горизонтально масштабировалось - например, с помощью шардинга. Поэтому рекомендую выбрать систему, с которой умеете работать и которая умеет реплицироваться. Но реализовывать её так, чтобы можно было масштабироваться путём добавления серверов именно к Вашему сервису, а не к серверу БД.
Ответ написан
@raiboon
Абсолютный бред.
Т.е. да, для чатов я бы вероятно использовал что-то другое, вроде Кассандры, или даже динамодб.
Но ваши мысли не имеют под собой никаких оснований. Postgresql самый универсальный выбор, он отлично шардируется/масштабируемая/реплиуируется и другие страшные слова.
Ответ написан
@auoa16
Самое главное что нужно сделать это перестать говорить СКЕЙЛИТСЯ. Вы употребили его больше раз, чем все жители нашей страны за всю историю. Это было первое.

Второе - про масштабирование прочтите вот этот мой ответ и вот это обсуждение
Ответ написан
antonio1107
@antonio1107
Заместитель руководителя web-отдела
Привет.
Это вопрос уровня архитектура, а не программиста или разработчика.
И честно говоря, не совсем понимаю, что ты именно хочешь?

Научиться практикам DevOps? Это один подход. И глубокое изучение масштабирования определенной огромной базы.

Если показать, насколько ты крут, как разраб, то это не то, что требуется от разработчика.

Решить конкретную задачу - выдержать 1м пользователь онлайн, хоть в чатах, хоть в чем другом, то тут довольно обыденно.
На highload и devconf(отличный мастер-класс от Бородина там) всё приходят и рассказывают про единый подход: это спотовая архитектура. Пример-badoo. У них на mysql и 450M пользователей.

У manychat это называется галактиками. У этих близится к 200M пользователей в чатах ежедневно. И у них postgresql
Ответ написан
@kapustor
У PG есть два крутых open source форка, поддерживающих горизонтальное масштабирование до сотен узлов и петабайт данных: Citus DB для OLTP нагрузки (QPS~=TPS, похоже ваш случай) и Greenplum для OLAP (мало QPS, много TPS, аналитика, джойны, оконные функции и тд). Оба полностью совместимы с PG по синтаксису.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы