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

Question

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

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

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

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

В принципе, я нахожу, что лучшие решения для:

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

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

Answer 1

Один стол на пользователя хуже, не делайте этого.

Миллионы строк в день - десятки, может быть, сотни, в секунду? Вероятно, это требует некоторой формы «постановки» - сбор нескольких строк, а затем их включение в пакетную загрузку. Прежде чем обсуждать, пожалуйста, подробно расскажите о потоке данных: Single или multiple clients. UI и пакетных процессов. Предварительно 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, где это необходимо.
• Нормализовать повторяющиеся строки.

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