Comments 9
у нас нет отдельного человека, отвечающего за базы данных, а программисты и системные администраторы не могут каждый день тратить кучу времени на поддержание стабильности MySQL и реагировать на каждое падение
кластер с master-master репликацией
Хочу пожелать удачи в соблюдении взаимоисключающих параграфов.
Сервис мониторинга — такая задача же элементарно партицируется горизонтально, данные по крайней мере разных аккаунтов не связаны между собой должны быть. Зачем вам мастер-мастер реплика?
Хочу пожелать удачи в соблюдении взаимоисключающих параграфов.
Мы работаем над разработкой и улучшением самого сервиса и, в основном, front-end'a. С масштабируемостью MySQL у нас не очень большой опыт, но мы работаем над этим.
Сервис мониторинга — такая задача же элементарно партицируется горизонтально, данные по крайней мере разных аккаунтов не связаны между собой должны быть. Зачем вам мастер-мастер реплика?
Останется ли в этом случае проблема слишком большого количества подключений к базе? Или при партиционировании тоже настраивается LB?
При горизонтальном масштабировании (aka шардирование, погуглите, я опишу только самые азы) вы берёте вашу одну базу и делите на части (например, на две машины) по какому-то признаку. Поскольку аккаунты должны быть независимые друг от друга по самой идее предметной области — хороший выбор делить по аккаунтам.
На приложении выясняете, на каком сервере хранятся данные нужного пользователя, открываете соединение только к этой БД и работаете только с ней. Получили два полностью независимых писателя, т.е. удвоили производительность БД. Можете одного даже случайно уронить, эффект заметит только та часть клиентов, которая обслуживается этим сервером. Так же просто добавляется любое потребное число серверов по мере роста проекта.
Как хранить соответствие пользователя и сервера БД — самое гибкое решение — делаете нулевой сервер БД, который будет хранить таблицу соответствия user_id -> server. Таблицу можно легко кэшировать тем же memcache и проблем нет (но становится точкой отказа). На нём же вполне уместна всякая авторизация и регистрация юзеров.
На приложении выясняете, на каком сервере хранятся данные нужного пользователя, открываете соединение только к этой БД и работаете только с ней. Получили два полностью независимых писателя, т.е. удвоили производительность БД. Можете одного даже случайно уронить, эффект заметит только та часть клиентов, которая обслуживается этим сервером. Так же просто добавляется любое потребное число серверов по мере роста проекта.
Как хранить соответствие пользователя и сервера БД — самое гибкое решение — делаете нулевой сервер БД, который будет хранить таблицу соответствия user_id -> server. Таблицу можно легко кэшировать тем же memcache и проблем нет (но становится точкой отказа). На нём же вполне уместна всякая авторизация и регистрация юзеров.
Спасибо, всегда хотелось увидеть Galera у кого-нибудь еще в продакшене.
При такой структуре инженерного ресурса люди часто смотрят в сторону NoSQL, в том числе MongoDB, оно хоть и не ACID, но имеет свои преимущества. В том числе практически беспроблемный шардинг, высокая (из-за модели доступа к памяти) а также массу дополнительных приятных плюшек (типа поиска), и прочего. Я не знаю какая у Вас структура данных, но судя по наличию большому количеству метрик мониторинга очень рекомендую также посмотреть на Elastic Search.
При такой структуре инженерного ресурса люди часто смотрят в сторону NoSQL, в том числе MongoDB, оно хоть и не ACID, но имеет свои преимущества. В том числе практически беспроблемный шардинг, высокая (из-за модели доступа к памяти) а также массу дополнительных приятных плюшек (типа поиска), и прочего. Я не знаю какая у Вас структура данных, но судя по наличию большому количеству метрик мониторинга очень рекомендую также посмотреть на Elastic Search.
Имею противоположный опыт астрономического роста объема данных (из-за JSON) по сравнению с реляционной БД, катастрофически медленного map reduce и диких тормозов при вставке данных в коллекцию с несколькими миллионами элементов (на SSD должен заметить).
MongoDB, конечно, не панацея. И просто «пихать» в нее все подряд тоже не выход. На одном проекте растянули все на 17 шардов по несколько ТБ… Вот там были тормоза, ведь данные просто клались как попало. Решили вопрос сменой структуры данных и переносом части вещей в kafka/elasticsearch.
В MongoDB начиная с версии 3.0 добавлена поддержка WiredTiger Storage Engine который поддерживает компрессию данных и обещает от 7х до 10х скорость вставки.
Но как говорят сами разработчики пока, «тестируйте тестируйте тестируйте».
Но как говорят сами разработчики пока, «тестируйте тестируйте тестируйте».
Извиняюсь за глупый вопрос, но вы не рассматривали вариант перехода на Cassandra?
aquanet Скажите пожалуйста статья была написана 2 года назад.
Как вам эксплуатация бесплатной версии ClusterControl?
Есть ли проблемы? Вы так же используете ее?
Есть ли замены/бесплатные аналоги?
Как вам эксплуатация бесплатной версии ClusterControl?
Есть ли проблемы? Вы так же используете ее?
Есть ли замены/бесплатные аналоги?
Sign up to leave a comment.
Быстрая установка SQL кластера Galera MariaDB c HaProxy и ClusterControl от Severalnines