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

Задача

Одним из этапов развития «Персии» стала разработка системы сбора, хранения и отображения статистических данных о работе рекрутеров в рамках отдельной компании. Для руководителя компании важно знать эффективность работы команды, а для этого необходима оценка работы всей компании и каждого сотрудника на базе цифровых показателей. Для «Персии» такими показателями являются: количество закрытых вакансий, скорость их закрытия, количество добавленных резюме, средние значения этих показателей (за период, на одного пользователя) и т. п.

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

Поиск решения

Вариант А: ведение полной истории

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

Проведем оценку скорости роста таблицы статистики по одному пользователю. Предположим, что пользователь добавляет по одному резюме каждую минуту (что маловероятно, но наглядно для анализа). Другие действия пользователей, интересующие нас, требуют еще больше времени на выполнение. Итак, в год: 60×24×365 = 525600 действий. А значит столько же записей в таблицу статистики. А теперь умножаем на число пользователей в компании. Потом умножаем на число компаний… Многовато :) Какой выход? Разделить статистические данные по отдельным таблицам для каждой компании. Разделили. Для некоторых компаний этого будет уже достаточно: возможно у них 2-3 рекрутера и работа выполняется достаточно медленно. Но для крупных компаний таблица статистики все же будет слишком большой.

Вариант Б: хранение обобщенных данных

Посмотрим внимательней на собираемые данные и то, как мы их в итоге показываем пользователям. В данном случае, пользователя интересуют не столько записи о конкретных действиях, сколько их количество за определенный интервал времени. Значит, если выбрать минимальный интервал, то можно хранить количество (сумму) действий как одну запись. А это во много раз уменьшает таблицу статистики компании. Какой же выбрать минимальный интервал? Логично предположить, что в течение рабочего дня статистические данные могут меняться очень быстро и не имеет смысла за ними следить в режиме «реального времени». Скорее всего, руководителю интересно получить данные за неделю или месяц, и по ним принимать решения. Поэтому был выбран минимальный интервал в 1 сутки, что позволит нам получить информацию с вполне достаточной детализацией до одного дня.

При таком подходе получим таблицу, которая состоит из нескольких записей для каждого отдельного дня: одна строка для всей компании и по одной строке для каждого рекрутера этой компании. Например, если в компании 2 рекрутера, то в таблице будет: 2×3 х 365 = 2190 записей за год. В расчете на одного пользователя это в 480 раз меньше, чем в предыдущем варианте!

Решение

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

Такой подход к сбору и хранению статистики позволяет простыми методами значительно уменьшить объем хранимой информации и увеличить скорость получения и вывода статистики пользователям.

Видимый пользователям системы результат:

Общая статистика по компании

Статистика работы рекрутера

Выводы

Конечно, у такого подхода есть как преимущества, так и недостатки.

Недостатки:

• теряются исходные данные по каждому отдельному действию пользователя;
• невозможно повторно выполнить пересчет статистики;
• пользователи не видят статистику за текущие сутки.

Преимущества:

• возможность сохранять статистическую информацию независимо от изменения основной базы (даже если исходная информация уже удалена);
• значительное уменьшение объема хранимой информации без потери ее ценности как статистических данных;
• уменьшение нагрузки на сервер баз данных;
• увеличение скорости вывода статистики пользователям.