Нужен совет. Совсем скоро планирую добавить на сайт модуль по сбору информации о активности пользователя и подсчёта этой активности. Коротко о самом модуле: данный модуль собирает все сведения о активности пользователя в ежедневный буфер (в текущей версии всё данные записываются в БД), а через сутки выполняется подсчёт этой самой активности и выдача награды пользователю. И стал передо мной такой вопрос: а как же правильно собирать информацию? Ведь это слишком много запросов в БД. Как вариант записывать всё в json каждый день, и все шифровать в base64. Но будет ли это лучше? Или есть ещё какая-либо альтернатива?
Ведь это слишком много запросов в БД.
если у вас небольшое кол-во пользователей (не сайт-миллионик), то обычная БД это переварит ( ну 100 - 1000 запросов в секунду во всяком случае переварить сможет)
Как вариант записывать всё в json каждый день
где именно? хранить на стороне пользователя json?
и все шифровать в base64.
при передаче json на сервер вам по идее и так это придётся делать
Но будет ли это лучше? Или есть ещё какая-либо альтернатива?
смотря что вы понимаете под активностью пользователя, насколько эта активность активна и как много пользователь работает с сайтом:
если под активностью пользователя понимать, на какую страницу заходит пользователь и какой элемент пользователь нажимает - то это относительно редкие вещи, поэтому можно сразу посылать их на сервер и записывать в БД, причем таблицу можно организовать совсем просто:
идентификатор пользователя | тип действия | объект действия | время действия | дополнительная информация
в продолжении п.1) если действий относительно много, то их можно накапливать на клиенте пользователя и отсылать раз в минуту или при накоплении 100 действий, сами действия хранить в массиве со структурой описанной выше - по сути это будет json-данные, которые вы потом превращаете в строку (base64) и пересылаете на сервер
если же под действиями понимается любой чих - сколько раз пользователь нажал клавишу или кнопку мыши, сколько километров пробегал курсором мышки, какой текст вводил, с какой интенсивностью и т.д., то это опять таки надо будет накапливать на клиенте и пересылать порциями, причем желательно поджимать информацию тогда - к примеру те же числа (если их много) передавать не в 10ричной системе исчисления, а в 256ричной, типа не 20
, а ' '
Айфон мало держит заряд, разбираемся с проблемой вместе с AppLab
Возникла следующая проблема — при опросе ip адресов, которые берутся с БД, на некоторых ip адресах зависает метод подключенияСуть следующая...
Имеются города city, автомойки wash и посты на них bfrs