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

Question

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

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

На данный момент у меня есть некоторые проблемы с дизайном:

Трафик в этих кампаниях очень высокий, поэтому потенциально у меня есть миллионы строк, вставляемых в день. В этой системе может быть несколько пользователей, поэтому я не могу хранить все эти данные в одной таблице, потому что это может привести к путанице. Может быть, я могу разделить данные на несколько таблиц, по одной таблице на пользователя, но я не уверен в этом решении.
Процесс сохранения данных должен быть выполнен как можно быстрее (несколько миллисекунд), поэтому я считаю, что NodeJS намного лучше, чем PHP, для этого. Особенно в отношении скорости и ресурсов сервера. Я не хочу, чтобы сервер зависал из-за недостатка оперативной памяти.
Мне нужно сгруппировать эти данные для статистических целей. Например, у меня есть по одной строке для каждого пользователя, который посещает мою целевую страницу, но мне нужно сгруппировать эти данные, чтобы показать количество показов на этой конкретной целевой странице. Таким образом, все эти запросы должны выполняться как можно быстрее с таким большим количеством строк.
Мне нужно геокодировать IP-адреса, поэтому мне нужна точная информация, такая как страна, провайдер, тип соединения и т. Д., Но это может замедлить процесс сохранения данных, если я вызову службу API. И это должно быть сделано в режиме реального времени и не может быть сделано позже.

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

В основном я нахожу лучшие решения для:

Эффективно управлять очень большой базой данных
Сохранение данных от пользователей в кратчайшие сроки (мс)
Если возможно, сделайте геокод ip в кратчайшие сроки, не блокируя выполнение
Оптимизировать схему и запросы для генерации статистики

Есть ли у вас предложения? Заранее спасибо.

0

database-design ip-geolocation mysql node.js php

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Одна таблица на пользователя — еще хуже; не делай этого

Миллионы строк в день — десятки, может быть, сотни в секунду? Это, вероятно, требует некоторой формы «постановки» — сбор нескольких строк, а затем их пакетная вставка. Перед дальнейшим обсуждением, пожалуйста, уточните поток данных: один против нескольких клиентов. Пользовательский интерфейс против пакетных процессов. предварительный CREATE TABLE, И т.п.

Статистический — План создания и поэтапного ведения «Сводных таблиц».

Вы пытаетесь сопоставить IP-адреса пользователей со страной? Это отдельный вопрос, и на него дан ответ.

«Должен», «в реальном времени», «миллисекунды». Признайтесь, вам придется сделать некоторые компромиссы.

Более подробная информация: Перейти к http://mysql.rjweb.org/ ; оттуда, посмотрите три блога по методам хранилища данных.

Как хранить по дням

InnoDB хранит данные в PRIMARY KEY порядок. Таким образом, чтобы получить все строки за один день, смежные друг с другом, необходимо Начните ПК с датой и временем. Для огромных баз данных может значительно улучшить некоторые запросы, позволяя запросу сканировать данные последовательно, минимизируя тем самым дисковый ввод-вывод.

Если у вас уже есть id AUTO_INCREMENT (и если вам это по-прежнему нужно), то сделайте следующее:

PRIMARY KEY(datetime, id),  -- to get clustering, and be UNIQUE
INDEX(id)  -- to keep AUTO_INCREMENT happy

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

Ведение сводных таблиц с изменением данных

это может быть возможным; Мне нужно лучше понять данные и изменения.

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

Сожмите данные

Не использовать BIGINT (8 байт), если INT (4 байта) будет достаточно; не использовать INT если MEDIUMINT (3 байта) будет делать. И т.п.
использование UNSIGNED где уместно.
Нормализовать повторяющиеся строки.

Меньшие данные сделают его более кэшируемым, и, следовательно, будут работать быстрее, когда вам придется попадать на диск.

0