Решаю, какую БД использовать для мессенджера. Понимаю, что моим мессенджером будут пользоваться полтора человека, но я пишу его для практики, изучения неизвестных мне технологий и для того чтобы положить в портфолио, так что я делаю вид, будто у меня будет миллион одновременных юзеров. Стараюсь спроектировать сервер сайд так, чтобы он легко скейлился простым добавлением новых серверов.
В общем сервер сайд код уже почти весь готов. Использовал Dart (странный выбор, я знаю), WebRTC, Redis, RabbitMQ и Postgres. Групповые чаты работают, видео звонки работают, все скейлится ок, кроме БД. Насколько я знаю, Postgres не скейлится на несколько нод без танцев с бубном. Я не БД инженер, знаю по этой теме не много и не думаю, что смогу разобраться, как правильно скейлить Постгрес. Слишком глуп :) Использовал PG просто потому что только его и знаю немного, и, если честно, я думал, что он скейлится из коробки, поэтому даже не гуглил ничего.
Сейчас ищу другие варианты. Сначала обратил внимание на Cassandra. Легко скейлится и используется во многих похожих проектах. Можно использовать group id в качестве partition key, тогда все сообщения из группы будут храниться на одной ноде. Но в Кассандре нет джойнов. Когда юзер появляется онлайн, нужно вытащить непрочитанные сообщения из множества разных групп, в которых он состоит, а, значит, так как нет джойнов, придется делать кучу разных запросов, что, конечно, так себе идея.
Затем гугл привел меня к CockroachDB. Скейлится легко, синтаксис Постгреса, все вроде идеально. Не самая быстрая БД, но мне не требуются супер быстрые инсерты, так как если юзер онлайн, то сообщение ему отправляется до того, как оно пишется в БД.
Что можете посоветовать? Что выбрать? Может, какой-то другой вариант? БД столько разных, что голова кругом.
И, пожалуйста, не нужно советов вида, что мне ничего этого не требуется, легко обойдусь одним инстансом Постгреса, преждевременная оптимизация это глупо, сначала запусти в прод, а уже потом, если вдруг Постгрес перестанет справляться, будешь думать о скейле и тд и тп. Я знаю, что мне ничего этого не требуется. Это, можно сказать, просто практика, тренировка реализации более менее сложной архитектуры.
Популярные NoSQL решения не используют джойны поскольку это в любом случае ведет к сетевым походам на различные шарды. Даже если это скрыто от пользователя. Соответственно в распределенной системе вы не получите джойнов как в Postgre. Более того, если пытаться шардировать Postgre, у вас и там возникнет проблема джойнов между шардами и от подобных джойнов придется отказаться.
Проблема в том, что вы подходите к хранению данных в NoSQL также как в RDBS. Это неверно и для распределенных систем вполне себе допустимо хранение избыточных данных. Вы вполне например можете записывать новое сообщение на множество шардов, на шард где хранятся сообщения группы и на шарды с юзерами. Делать это можно по событию, которое генерируется при создании сообщения, далее оно попадает в rabbitmq, а оттуда подписчикам, которые запишут сообщение на нужные шарды.
Таким образом, вы всегда сможете прочитать вместе с пользователем его новые сообщения с одного шарда. Делают по разному, основная мысль в том, чтобы максимально упростить сбор данных, для того или иного экрана приложения.
Например в социальных сетях так советуют собирать ленту новостей. Система принимает пост от пользователя, а затем сервис в фоновом режиме раскладывает этот пост по всем пользователям (шардам), которые этот пост могут увидеть. Соответственно отображение ленты новостей становится тривиальной задачей. Также нужно быть готовым к тому, что в распределенных системах принята согласованность по событию вместо согласованности по транзакции. Проще говоря, не все пользователи увидят новый пост в своей ленте мгновенно, а спустя некоторое время и для больших проектов вроде facebook или amazon это ок. Из-за этого иногда на facebook можно обновлять ленту с переодичностью в секунду и в какой-то момент получить новый пост у которого дата добавления была 1 минуту назад.
По базам данных можно выбрать любую популярную с поддержкой шардинга из коробки, которая больше нравится или с которой лучше знакомы. Знакомы с кассандрой, отлично используйте её, знаете монго, берите её. Не знаете ничего, почитайте плюсы и минусы обоих систем и решите для себя, что больше вам подходит.
Master-slave полезно на случай отказа одного сервера, но по нагрузке и оно имеет свои пределы; и что потом будете делать? Более-менее сложная архитектура подразумевает встраивание сервера БД в архитектуру приложения так, чтобы оно горизонтально масштабировалось - например, с помощью шардинга. Поэтому рекомендую выбрать систему, с которой умеете работать и которая умеет реплицироваться. Но реализовывать её так, чтобы можно было масштабироваться путём добавления серверов именно к Вашему сервису, а не к серверу БД.
Абсолютный бред.
Т.е. да, для чатов я бы вероятно использовал что-то другое, вроде Кассандры, или даже динамодб.
Но ваши мысли не имеют под собой никаких оснований. Postgresql самый универсальный выбор, он отлично шардируется/масштабируемая/реплиуируется и другие страшные слова.
Мне кажется, что коллега по неправильным критериям выбирает бд. Транзакционности для чата ? Srsly? А ничего, что там не про сохранность данных, во-первых, чай - не финансовая система. Во-вторых, транзакционности в распределенной системе - это тупо дорого и медленно. В третьих, как ниже коллеги написали - джойны в распределенной это плохо. Гонять трафик по сети туда-сюда. Поэтому в первую очередь надо задуматься о модели данных. О критериях и требованиях работы с ними. Ну, и дальше уже выбирать базу.
Могу добавить, что для быстродействия очень сладко выглядят in-memory бд, которые при достаточном количестве реплик могут и сохранность данных обеспечить.
Ну, и обязательно добавить шину сообщений типа Kafka
Зачем нужна распределенность? Просто шардируем по чатам. Один чат хранится на определенной ноде. И все будет локально. Все будет работать отлично. Транзакции начинают мешать на очень больших нагрузках.
Самое главное что нужно сделать это перестать говорить СКЕЙЛИТСЯ. Вы употребили его больше раз, чем все жители нашей страны за всю историю. Это было первое.
konstunn, пользователь Adamos дал хороший ответ на ваш вопрос - использование англицизма должно быть оправдано либо его безумной популярностью и распространенностью, либо отсутствием в русском языке слова в достаточной степени передающего идентичный смысл. В данном случае не выполняется ни первое, ни второе условие. Поэтому, как вы верно заметили, это выглядит вульгарно и режет глаза.
Есть такая вещь как коммуникативная целесообразность. Это банально и тупо, но в слове скейлинг меньше букв, его быстрее и удобнее набирать. Но это вульгарно, да.
Привет.
Это вопрос уровня архитектура, а не программиста или разработчика.
И честно говоря, не совсем понимаю, что ты именно хочешь?
Научиться практикам DevOps? Это один подход. И глубокое изучение масштабирования определенной огромной базы.
Если показать, насколько ты крут, как разраб, то это не то, что требуется от разработчика.
Решить конкретную задачу - выдержать 1м пользователь онлайн, хоть в чатах, хоть в чем другом, то тут довольно обыденно.
На highload и devconf(отличный мастер-класс от Бородина там) всё приходят и рассказывают про единый подход: это спотовая архитектура. Пример-badoo. У них на mysql и 450M пользователей.
У manychat это называется галактиками. У этих близится к 200M пользователей в чатах ежедневно. И у них postgresql
Антон Косьяненко, это нихера не общиприняттые сокращения, если не брать во внимание отдельную голову.
если уж хочется общепринятости и сокращения, то это записывается как 1kk чего-то там.
и не нужно прилетать сюда девопс, который совсем про другое.
У PG есть два крутых open source форка, поддерживающих горизонтальное масштабирование до сотен узлов и петабайт данных: Citus DB для OLTP нагрузки (QPS~=TPS, похоже ваш случай) и Greenplum для OLAP (мало QPS, много TPS, аналитика, джойны, оконные функции и тд). Оба полностью совместимы с PG по синтаксису.
Средний
Простой
Простой
