Как правильно делать счетчики на сайте?

Question

[Dos]

Всем привет! Довольно часто нужно выводить различные счетчики на сайтах: количество новых уведомлений, количество заявок в друзья, количество друзей, количество предстоящих событий, количество новых комментариев и так далее. Таких счетчиков может быть достаточно много. Но может и быть минимальным, как я описал.

Данные счетчики чаще всего выводятся в UI: меню, профиле, статистике и так далее. Я их буду использовать в так же. Но передавать данные буду через API. Практически всегда такие счетчики я получал с помощью дополнительного запроса. Либо отдельного, либо с использованием join. Реже я создавал дополнительные поля у пользователя и по событиям синхронизировал эти счетчики. И выводить такие счетчики уже можно одним запросом. Но дополнительная сложность возникала об актуальности данных. Важно синхронизировать все данные верно и учитывать все нюансы.

Хотелось бы уточнить как правильно работают профессионалы с таким? Какие хорошие практике на эту тему есть? Какой подход лучше выбирать при работе с такими данными? Может быть хранить эти счетчики в NоSQL?

В целом вопросов много. Было бы хорошо услышать толковый ответ на эту тему. Возможно есть ссылки на подобные темы, видел и так далее. Всех заранее благодарю! С наступающим!)

Comments

[bozuriciyu]

Исключительно очереди.

Answer 1

[xmoonlight]

Есть 3 типа счётчиков:
1. Public
2. ALL Registered Users
3. Current User
Приоритет важности актуализации значения счётчика, соответственно, обратный.

1. Для Public - обычно, суммарный сбор данных по крону (+читает счётчики системного пользователя).
2. Для ALL Registered Users - обновляет системный пользователь по своим событиям (+читает счётчики пользователей).
3. Для Current User - обновляет этот пользователь свои счётчики по своим событиям (+читает только свои счётчики).

Таким образом идёт восходящий подсчёт различных значений счётчиков с разным приоритетом и размеренной нагрузкой.

Обновление своего счётчика по событиям: любое действие, требующее подсчёт - это запрос в БД для самого действия и в этом же запросе - смена значения нужного параметра в таблице счётчиков конкретного типа счётчика (из трёх, выше указанных).

PS: И, Вас, тоже, с наступающим!

Comments

[Dos]

Доброго утра! С наступившим Новым годом!)

Отличный ответ! Могли бы Вы ещё дополнить ответ, как и в каком виде хранить данные? На вопрос подписалось 10 человек. Имеет актуальность.

Все советуют Redis. Я так понимаю в таком виде и стоит хранить? Или использовать в MYSQL?

Если взять базу данных MYSQL, то как хранить три ваших типа? Какая архитектура таблиц? Например, для вашего типа ALL Registered Users можно создать дополнительные поля в таблице users: counter_friends, counter_comments, counter_reviews, etc... А можно создать дополнительную таблицу user_counters и добавить их там.

Возьмем второй примитивный пример - посты в блоге. У которых есть счётчики: количество комментариев, к. отзывов, к. подписчиков и так далее. Как быть в этом случае?

В вашем типе Public какую структуру иметь счетчиков? Это отдельная база счетчиков? Или это отдельная таблица?)

Если не сложно - можете дополнить свой ответ или ответить в комментариях? Очень волнующая тема. Ваш ответ внёс некие понимания и в целом он хороший!

Благодарю!

[xmoonlight]

pro-dev, Спасибо, Вам, за поздравления и, особенно, за такую оценку моего ответа.

Счётчики для конкретных записей - делаются рядом (в той же таблице, доп.колонкой).

Таблица общих счётчиков - всегда делается отдельно (отдельным реестром полей одной таблицы).

Собирается - всё через update-запросы в виде транзакций из других таблиц.

Хранить - можно в обычном mysql.
Нужен ли Redis - зависит от динамики. Если происходят частые изменения счётчиков (более 100 update-ов в секунду) - redis, разумеется, нужен.

Если не особо хочется редис, то Все можно переложить и в статичное кеширование или часть - в кеш сессии пользователя.

[Dos]

xmoonlight, спасибо за дополнение ответа. Есть небольшие утончения по ответу. Если не сложно - прокомментируйте...

Счётчики для конкретных записей - делаются рядом (в той же таблице, доп.колонкой).

Если полей счетчиков много? Имеет смысл вынести в отдельную таблицу? Или в большинстве случаев достаточно этого? Сколько по вашему опыту можно хранить счетчиков рядом, а при каком количестве отдельная таблица? Если говорим о MYSQL или другой реляционной БД.

Собирается - всё через update-запросы в виде транзакций из других таблиц.

У меня события реализованы не в базе, а в коде. С помощью EventDispatcher, где есть Event и Listener. Мне кажется так правильней, чем события БД. При смене БД или переносе данных в таком случае могут возникнуть сложности. И с тестами проблема. Что думаете?

В остальном понятно. А как хранить в редис? user:125:counter:friends? С Redis пока что в примитивном виде использовал. Сложные вещи не структурировал.

[Dos]

xmoonlight, если не сложно можно услышать вообще мнение по этому вопросу? Как передавать разрешения для API?

[xmoonlight]

pro-dev,

Если полей счетчиков много?

Я не понимаю слова "много" в данном вопросе.
Счётчик считает или конкретную выборку, или количество запросов/операций (через update). Если это выборки - это отдельная таблица значений счётчиков, если количество (просмотров конкретной публикации, например), то этот счётчик ставится в таблицу контролируемого объекта доп.полем (в таблицу публикаций, например).

Сколько по вашему опыту можно хранить счетчиков рядом, а при каком количестве отдельная таблица?

Про распределение - я указал выше. А про количество рядом - столько, сколько необходимо для задач контроля конкретного объекта или его поля.

Про оптимизацию немного:
Здесь важно не забывать про быстрое обновление кэша и быстрое обновление.
Можно "схлопывать" очередь обновления, считая сумму показателей для обновления одного и того же поля внутри очереди (в коде) - пакетная оптимизация (вместо нескольких запросов к бд будет только один).

Кэш счётчика - лучше обновлять из кода и только при изменении/модификации данных и именно в момент изменения/модификации - одним проходом.

Про события:
Если Вы сами себе полностью гарантируете контроль "состояния гонки" через код, это ваше право: непересекающиеся данные - обработать в несколько потоков, а зависимые - строго в порядке транзакции.

Поскольку у Вас свой EventDispatcher - пока вообще не лезьте в редис. Он может вообще даже не понадобиться Вам, если всё сделаете правильно.

[Dos]

xmoonlight, понял) Спасибо!))

[xmoonlight]

pro-dev, вижу, что остались вопросы, но мучает совесть))
Готов ответить ещё на пару-тройку))

[Dos]

xmoonlight, нет. Сейчас правда все понятно. Надо опробовать на практике, а если в процессе появятся вопросы - я напишу их сюда. Пока что все понятно.

Счетчиков вначале не так много. Нагрузки не большие. Скорее всего обойдусь пока без Redis. Попробую дополнительными полями.

Какие счетчики возможно обновлять прямо в коде - буду изменять значения прямо в коде. А какие нет - с использованием событий и EventDispatcher. Это ещё и позволит в будущем быстро переписать код счетчиков на другую базу, например Redis.

А может и сразу редис буду использовать. Так как в symfony уже его использую. Надо подумать только об этом.

[xmoonlight]

pro-dev, ок. Если что - welcome!

Answer 2

[Григорий Васильков]

Редис. Счетчики могут быть переключены одновременно сотней людей, транзакции это будет конец. Чтобы принять запрос его хорошо бы сделать тем меньше чем возможно, хттп запрос это не самое малое что можно передать. Открыв сокет и плюнув датой, хешом юзера и айди счетчика, да все это в бинари, данных будет существенно меньше

Comments

[Dos]

Благодарю за ответ. Можете ещё подсказать пример какая структура данных должна быть в базе?) Пока не очень понятно. Можно почитать в другом ответе о чем речь...

[Григорий Васильков]

В случае если мы хотим видеть конкретное лицо - кто куда когда нажал - это будет таблица "действия" и там значит "кто", "что", "когда" сделал. Плюсы - нет проблем с одновременной записью, пиши хоть тысячу людей одновременно. Минусы - огромная растет таблица, и когда надо вывести сумму - ее надо пересчитывать, а это не очень быстро происходит на базах из пары миллионов. Т.е. пересчет придется делать периодически и данные несколько неактуальные.

Если мы говорим о счетчике - то это поле в любой из таблиц, что считаем. Повторю еще раз - если ты сделаешь счетчики в базе данных, а запросов будет не 2 в секунду, а десять тысяч - то у тебя встанет вопрос - как их всех одновременно приплюсовать, т.к. на время записи ячейка заблокируется (а точнее - вся строка - ты не сможешь обновлять пост пока пишется счетчик, ибо счетчик и есть обновление, т.е. счетчик еще и не может быть в таблице например "посты") а должна быть таблица "постСчетчики" где "ид поста" и поле "сумма".

Простейшее казалось бы решение - завернуть в транзакцию и пусть все ждут пока счетчик переключиться. Это приведет к гигантского размера очереди т.к. все будут ждать, пока предыдущие операции делаются.

Поэтому предлагается для счетчика использовать Redis, в котором это будет "чуть чуть" быстрее, что увеличит допустимую нагрузку на каждый из счетчиков. И каждые n-секунд уже повышать счетчик в базе данных, чтобы если счетчик перестанут переключать и редис его подчистит - данные остались надолго.

При показе смотрим есть ли в редисе, нет - берем из базы.

[Dos]

Григорий Васильков,

Поэтому предлагается для счетчика использовать Redis, в котором это будет "чуть чуть" быстрее, что увеличит допустимую нагрузку на каждый из счетчиков. И каждые n-секунд уже повышать счетчик в базе данных, чтобы если счетчик перестанут переключать и редис его подчистит - данные остались надолго.

То есть вы предлагаете некий гибрид: хранить в базе и redis? Почему тогда нельзя сразу оставить только redis? Не понял немного по такому подходу)

И ещё вопрос. Если счётчики пока не большие. Например 1 шт. имеет ли смысл заводить сразу редис или пока хранить в БД?

[Григорий Васильков]

в базе долговременное в редис коротковременное. поднимать счетчик в редис потому что быстро. пересчитывать и периодически сливать в базу, чтобы если редис или компьютер офнулся - счетчик остался. можно как-то там и редис настроить на периодическую запись и восстановление из файла наверное. ну уже детали. нужно коротковременное быстрое хранилище, и долговременное, куда редко пишем, но откуда читаем если быстрое сломалось

[Dos]

Григорий Васильков, понял)

Answer 3

[Philipp]

Обычно для счетчиков стараются применять базы данных в памяти.
В основном это Redis, но можно и MySQL использовать, просто указать хранилище в памяти и отключить транзакции.
В большинстве своем счетчики обновляются на основе различных событий, например отправка комментария. Обновление делается в фоновом режиме.
Как только данные актуализируются, интерфейс уведомляется о новом состоянии счетчиков. На больших сайтах это реализуется через SSE или веб-сокеты.