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

Question

[verycooldev]

Есть простой API сервер для SPA приложения. Стек: Нода, Экспресс, Монго.

Задача: простой счетчик количества запросов по определенному роуту (поскольку сам фронт отделен от API) неуникальных пользователей и сохранение этих данных. Т.е. каждое обращение считать, даже если юзер обновляет страницу (так же как и на Тостере).

И тут возникают вопросы как же это правильно реализовать?

1. Если при каждом обращении за данными изменять поле count в Монге для запрашиваемой статьи - это выглядит как-то слишком нагруженно на сервер
2. Что будет если одновременно запросит страницу (т.е. вернее роут, с которого страница потянет данные) 100, 500, 1000 человек? 1000 операций записи в БД одновременно? Как с этим на практике у Монги? Я полагаю данные либо будут терятся либо все умрет. Или они встанут в очередь и появится дикая задержка?
3. Может как-то хранить в памяти счетчик и потом периодически его сохранять в БД к нужной статье?

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

Answer 1

[Алексей Шашенков]

Если ожидается большая нагрузка, то можно сделать шардирование бд или применить бд которые готовы в большим объемам записи (clickhouse).
Можно еще к примеру применить буферы, после наполнение, более 1000 записей, сразу всю пачку записать в бд. Но писать по 1-й строке в основную бд это очень дорого в точки зрения ресурсозатрат

Comments

[verycooldev]

Суть в том, что на мой взгляд неэффективно одновременно запрашивать запись в Монге и производить ее изменение (поле count, например). Вертояно это просто неправильно. Идея с буфером неплохая, но тогда надо производить дополнительно какждый раз проверку на его количесвто. Но это точно лучше чем каждый раз добавлять +1. Спасибо за идею.

[Алексей Шашенков]

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

Answer 2

[napa3um]

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

Минутка философии

Вообще, у хранилищ данных в информационной системе можно выделять две условные (не всегда чёткие) роли. OLTP - это хранилище, в которое приложение может быстро писать, там нужно делать минимум обработки, главное быстро сохранить данные и "отпустить" клиента (самый прямой пример такого хранилища - лог). И OLAP - это уже хранилище предвычисленных агрегатных данных, чтобы быстро отобразить их клиенту (а не вычислять во время запроса). И когда назревает необходимость масштабирования, эти роли начинают провляться всё явнее и явнее - приходится разделять этап приёма запроса и, собственно, его обработки, обработку откладывают на потом (складывают в очередь) настолько, насколько позволителен лаг между записью и актуализацией читаемых данных.

Comments

[verycooldev]

Хорошая идея насчет нескольких счетчиков. Об этом я не думал, полезно (впрочем, для моих целей думаю можно обойтись).

Answer 3

[frees2]

Если больше 10 событий, юзер нажал, просмотрел 10 раз, к примеру, то отправляем на сервер, зато роботы всякие в пролёте.

var i = 0;(function(history){ var pushState = history.pushState;
history.pushState = function(state) { if (typeof history.onpushstate == "function")
{history.onpushstate({state: state});} 
return pushState.apply(history, arguments); }})(window.history);
window.onpopstate = history.onpushstate = function(e){ i++; test=JSON.stringify(e.state);  


if (localStorage.getItem('history666') === null) { document.getElementById("moo").innerHTML ='Нет в памяти!' ;   }

Или через localStorage, JSON данные куда нибудь в хранилище идёт.

Comments

[verycooldev]

Вопрос о другом вообще, какие 10 событий?

[frees2]

В частности количество запросов (не обязательно), если их условно 10 в памяти браузера юзера, то считываем переменную ( если мы перед этим идентифицировали этого юзера, он зарегистрировался или оставил куки, только сейчас их отключают все кому не лень)) и отправляем на хранение.

[verycooldev]

frees2, ощущение что вы сами с собой разговариваете, простите

[frees2]

verycooldev, просто невозможно реализовать вашу идею
"Что будет если одновременно запросит страницу (т.е. вернее роут, с которого страница потянет данные) 100, 500, 1000 человек? 1000 операций записи в БД одновременно?"
без хранения информации в браузере юзера и выдачи её порциями в базу данных.
Удивлюсь, если кто придумает по иному!