Как обрабатывать большие объемы данных для модуля веб-статистики

Question

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

Механизм, который я использую, заключается в сохранении записи базы данных в таблице статистики каждый раз, когда пользователь входит в определенную зону в моей БД (я избегаю дублирования записей с помощью файлов cookie).

Например, у меня есть следующие зоны:

1. Веб-сайт — общая зона, используемая для подсчета уникальных пользователей, поскольку в последнее время я перестал доверять Google Analytics.
2. Категория – самоописательная.
3. Мини-сайт - самоописательный.
4. Изображение продукта — всякий раз, когда пользователь видит продукт и форму отправки запроса.

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

Я подумал, может быть, написать сервис, который будет каким-то образом анализировать данные, но не вижу способа сделать это без потери гибкости.

Мои вопросы:

1. Как крупномасштабные приложения для анализа данных, такие как Google Analytics, загружают данные так быстро?
2. Как мне лучше всего это сделать?
3. Может быть, у меня неправильная конструкция БД и мне следует хранить данные только в одной таблице?

Спасибо всем, кто помогает,

Эйтан.

Answer 1

Основной подход, который вы ищете, называется агрегирование.

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

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

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

Answer 2

Кажется, вы могли бы добиться успеха, используя две базы данных.Один предназначен для транзакционных данных и обрабатывает все операторы INSERT.Другой предназначен для отчетности и обрабатывает все ваши запросы.

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

Answer 3

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

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

Это означает, что если вы укажете диапазон дат при отправке запроса, данные, находящиеся за пределами этого диапазона, даже не будут учитываться;это может привести к очень значительной экономии времени, даже лучше, чем индекс (индекс должен учитывать каждую строку, поэтому он будет расти вместе с вашими данными);раздел — один в день).

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