Выбор базы данных для быстрой записи меняющихся данных?
Задача сделать что то похожее на майскор, сайт на котором показаны все коэффициенты по спортивным событиям. Соответственно получать их буду по api. Нет сервисов выдающих сразу одним запросом все. То есть сначала получить список событий, а потом получить коэффициенты по каждому событию по api. То есть будет очередь запросов. Я думал взять под это дело редис, так как в сохранности данных нужды нет, но есть нужда в быстрой записи, так как каждые 2-3 секунды нужно писать изменённые коэффициенты по 50-300 событиям в лайве. И держать информацию актуальной. Коэффициенты не всегда изменяются, значит нужно будет проверять, изменился ли коэффициент, и если нет - то не записывать. А если да - то определить вырос он или понизился, чтобы можно было отрисовать это на фронтенде. Я не уверен что MySQL подойдёт для этого. Так же думал про кликхаус, но пока мало с ним знаком, не знаю подойдёт ли.
Вообщем получается что нужно:
- Запрос по api всех событий (node js, асинхронно)
- дальше очередь запросов по каждому событию раз в 3 секунды (их может быть и 200 и 300, по прематчу раз в минуту запросы, может быть до 3000 событий)
- запись в бд события с коэффициентами, с проверкой изменилось ли что то или нет. И ответ с изменёнными данными.
То есть раз в 3 секунды обработка и запись 300 событий. И раз в минуту добавляется запись 3000 событий.
Сможет ли MySQL и я зря беспокоюсь, или редис все же лучше подходит под это дело. Может кто имел опыт разработки чего то подобного, или может знает как работают такие сервисы, или кто то писал что то подобное, подскажите куда копать пожалуйста :)
Это не должно быть проблемой для Mysql, это очень быстрая СУБД. С учётом, что это временные значения, которые не нужно хранить постоянно, то и классическая СУБД не нужна. Поэтому берите Redis. А Clickhouse это аналитическая СУБД, это здесь вообще не причём.
сохранность и тут возможна, какой-нибудь redis пишет фоном данные на диск с поддержкой транзакций
а самодельный лог может под конкретную задачу поднять производительность до невообразимых высот, даже на hdd (линейный лог там быстрый)
Сохранность временная, на 2 секунды или минуту. Так как все равно уйдёт запрос к апи и информация снова появится. Насчёт хранения в памяти даже не подумал, спасибо.
Román Mirilaczvili, я уже почитал насчёт хранения в памяти программы, то есть в переменных/картах что это быстрее даже редиса. Хоть убедился что редис сюда больше подходит и я в правильном направлении думаю)
Вячеслав Правильный,
Тут есть такие мысли:
1. речь не только о том как хранить данные, а также о том как получать их. Особенно если они нужны серверу лишь для того, чтобы дать клиенту нарисовать график.
2. В коде будет куда проще разобраться, увидев один несложный запрос к СУБД, а не код на несколько страниц, с учетом блокировок мьютексами и прочими прелестями.
Вячеслав Правильный, разумеется хранить в собственной памяти приложения будет быстрее, чем обращаться к внешней СУБД. Другое дело, далеко не факт, что это будет узким местом. А узким местом может оказаться получение данных из внешних источником, даже при асинхронных неблокирующих запросах. А еще данные как-то надо отдавать дальше, причем пока не ясно как. И все это будет делать одно приложение. Вполне вероятно оно справится, если его правильно написать, но при необходимости масштабироваться, придется менять архитектуру.
Для хранения/обновления/получения актуальных значений используйте redis, для сохранения истории mysql.
Nodejs по апи забирает исходные данные и обновляет их в redis, из редиса данные берутся во фронтенд и отдельным микросервисом складываются в mysql
Dimonchik, Я не думаю что там будет больше гигабайта данных в текстовом виде. Или редис использует x50 памяти от содержащихся данных? Мне не надо постоянное хранение истории, только текущие данные, с обновлением раз в пару секунд основных, и раз в минуту остальных (которых больше). Или запись жрет много памяти? По кликхаусу мало данных чтобы понять нужен он мне или нет. Либо нужно очень сильно вникать, поверхностно не разберешь можно ли применить под мою схему.
ну ты начни - дело в том что - да, может в твоей задачи проблемы и не возникнет такой , хватит редиса и железа под него, кликхаус тоже не идеал и надо уметь
но - быстрый запись много данных - это про клик 100%, редис? 100% если влазит в память )
и что, вы взяли коэффициент к в 0 часов, ав 0 часов 1'' коэффициент k поменялся k`, и кто-то тем старым коэффициентом k воспользовался.
Вы серьезно ок забыть, какой он был?
Наверное даже во время запроса по списку, часть коэффициентов изменится, по мере считывания, при том, что все, как задумано,но по-честному Вам бы наверное хотелось список "к" в 0 часов список в 0 часов + 1 версия + 2 ... n версия.
Учитывая 300 значений/3 секунды по 32 бита на каждый получаем 1,2МБ в час. В принципе копейки для MySQL
Редиску можно встроить для текущего слепка, если хочется немедленный ответ из буфера.
Простой
Простой
