Вопрос для профи.
Суть простая, я делаю проект, будучи менеджером проекта, спросить особо не у кого, хочу сменить бд, нужна производительность, от кол-ва возможности записи зависит кол-во пользователей. Сейчас наша бд крутится на релиционной бд (мускул, innodb). Хочу перейти на современное решение, типа редиски, с перспективами к масштабированию, с возможностью репликации со слейва на мастер и обратно ( сейчас будет 3 сервера, 1 только бд мастер чтение запись, второй только чтение(очень малое потребление), третий запись и отправка со слейва на мастер своей части.
Требуемая скорость записи на мастер от 2500 записей в секунду, чтение раз в минуту 100 тыс., запись многопоточная, асинхронная. Надо учитывать что будет еще и репликация с чтением.
Выборка на чтение в стиле: запрос id, затем чтение нужного поля.
Запись асинхронная, поиск id, запись числа от 1 до 10000
Чтение порядковое от 1 до 100тыс.
Как вы считаете какое лучшее решение для описанного выше? Идеальный ли вариант редис?
Вы - PM (Project Manager), ваша задача - управлять человеческими ресурсами, НЕ лезьте в разработку.
Задача программиста, согласно вами описанными правилами - реализовывать функционал, однако инструменты для этого он должен выбирать самостоятельно, согласно ТЗ.
То, что вы указали несколько цифр - это архитектурные требования и они ВНЕ вашей компетенции.
Вы указали требования на запись/чтение, а что на счет целостности, себестоимости, сложности внедрения и поддержки?
Redis - это key-value хранилище (чаще всего используется как кэш, и pub/sub роутер), MySQL - это реляционна БД. Это как сравнивать мотоцикл и фуру, они предназначены для разных целей.
Так то мускул и редис стоят совсем разных функциональных рядах, если вам кейвалью нужно то логично что это редис, если sql то мускул или постгрес.
Из вашего описания не очень понятно что вы храните, если у вас просто айди + поле то редис и выборка только по айди то редис самое то.
Структура бд проста. Выбираем id читаем, в течение минуты выясняем результат, асинхронно, результат пишем. Таких выборок 100 тыс в минуту, на 1 сервер. Сложные выборки на чтение и "медленную" запись, под медленной понимается сложная выборка пользователем, как правило не чаще раз в сути, тут идеален мускул, по многим причинам.
Кстати как вы думаете, по идее если редис поставить на сервер где запись, а потом реплицировать на второй сервер где редкое чтение, их возможно подружить на уровне данных? Теоретически, на уровне данных на раз два.
У редиса есть репликация, в редис будет сложно засунуть 245 миллиардов записей если они довольно большие, так как редис хранит все в памяти.
В редисе нет выборок кроме как запросов по айди, то есть там по сути хочу взять запись номер N.
В редисе есть и мастер мастер и мастер слейв репликация
Пума Тайланд: сорри за тупой вопрос если есть мастер слей следовательно есть слейв мастер? Думаю да. 245 млрд если сделать их в несколько байт (а у нас возможно сделать до 10-15 байт значения).
Что касается размеров теоретически, с учетом озвученного обьема данных, по моим подсчетам это 40 gb данных примерно, и честно говоря на опыте это чуть больше в размере ddr чем я озвучил., так случилось на моей работе. И честно говоря я не хочу повторения событий, в которых производительность прямо пропорционально размеру ddr, притом , если кто сам покупал серверную ddr, тот знает нереальную цену такого рода "масштабированию"))).
не знаю как вы придумали слейв мастер, либо я дурак либо вы дурак.
40 гигов это вообще ни о чем, это самая обычная база крайне среднего проекта
цена памяти вообще копеечная
какой нибудь дешевый сервер на 64 гига памяти стоит 100 евро в месяц.
я то думал у вас хайлоанд начальный хотя бы десятки серверов нужны.
Десяток не нужен, но нужно 4-5, для распределения нагрузки и защиты, сам сайт крутится на одном сервере ( назовем его слейв1), он и является пабликом, его же в основном и дидосят и используют юзеры для чтения, на него мы реплицируем данные для чтения.
На другом(назовем его мастер2) почти тупо запись в больших объемах, и примерно 10% чтения для записи, с него реплицируем данные, которые использует слейв1).
Третий и четвертый сервак (назовем их слейвами 3 и 4) для определенных задач скриптов, в результате работы этих скриптов, часть данных отправляется на мастер2.
редис это NoSQL хранилище.
Все записи хранятся в виде ключ - значение т.е. тут не выборок по параметру в принципе, в обычном понимании. Разве что только перебором искать.
Все что вы описали имеется в mysql. Никто не мешает вам масштабировать его.
Цифры все с потолка или уже имеются данные такие?
Чем не устраивает mysql и почему это не современное решение?
Nosql и все красивые слова мы знаем. Единственное я не владею ключ-значение, но не суть, как я понимаю +- это то что нам может подойти, с учетом того что сложных выборок нет.
Имеются значения в год я посчитал мы записываем 245> миллиардов записей. Разделить не сложно. Основано именно на опыте, а не на теориях.
Попробую скорр скинуть структуру и запрос.
Судя по описанию Redis Вам точно не подходит.
Даже с MySql на Postgres переход будет "болезненным". Если проект большой нужно подготовить себя к тому что это займет много времени.
Я согласен, что мускул это в первую очередь проект с опытом, и был у меня опыт с 40gb данными highload, но там я грешил всегда на оптимизацию запросов и перепроектирование. Но всегда считал, что от перехода зеркального на оракл, ничего не изменится.
Простой
