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

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

[Philipp]

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