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

Question

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

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

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

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

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

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

Мои вопросы:

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

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

Эйтан.

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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