Есть некие данные, которые обновляются в режиме реального времени. На основании их идет калькуляция значений, которые вносятся в БД из расчета что каждому пользователю соответствует свой набор результирующих значений.
Здравый смысл подсказывает, что делать UPDATE'ы для всех пользователей и пересчитывать значения в реальном времени нерационально, т.к данные отображаются только залогиненным (а это совсем малая часть от общего числа пользователей).
Как в таких случаях поступают "по науке", чтобы в первую очередь актуальные данные были у тех, кто онлайн, а для всех остальных данные пересчитывались с более низким приоритетом?
P.S: БД планируется использовать MySQL, но с удовольствием послушаю про другие, если они помогут решить проблему.
Вам нужна очередь (queue). Из скрипта данные кладутся (push) в очередь, а затем кроном из нее достаются (pull) и обрабатываются. Там работает практически весь популярный функционал большинства highload-проектов (например, мессенджер).
А как в данном случае быть с кэшированием? Если данных очень много, а показываются они в первую очередь только определённому кругу пользователей. Нужно ли будет обновлять после каждого изменения pull'а?
конечно, данные после пула должны обрабатываться так же, как если бы код был выполнен не в очереди, а в скрипте. А чтобы не возникало проблем с outdated данными у онлайн пользователей, нужно горизонтально расширять систему, запускать одновременно несколько инстансов кронов, изменять кол-во данных, находящихся в одной пачке из пула очереди.
Какой-нибудь счетчик просмотров с insert или update может в сумме давать ощутимую нагрузку при не самой большой посещаемости. В моем случае сервер задышал намного легче после того, как я перевел все счетчики на очередь. Это ведь по сути кеширование для insert/update запросов.
