Какой более эффективный способ вести ежедневный журнал рейтинга для каждого пользователя с MySQL?

Question

У меня есть база данных под названием RankHistory, которая ежедневно заполняется именем пользователя каждого пользователя и ранжированием в течение дня (ранжирование, как в 1,2,3, ...). Я продолжаю вести журналы по 90 дней для каждого пользователя, но моя пользовательская база выросла до такой степени, что база данных MySQL, содержащая эти журналы, теперь превышает 20 миллионов строк.

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

Answer 1

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

Вы также упоминаете о сохранении данных за 90 дней.на пользователя, но данные используются только для отображения графика изменений в рейтинге за последние 30 дней.Используются ли дополнительные 60-дневные данные для анализа изменений за предыдущие периоды?Если нет необходимости хранить эти данные (или, по крайней мере, не хранить их в первичном хранилище данных, согласно моему первому предложению), вы аккуратно сократите количество ваших данных на две трети.

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

Обновление:

Основываясь на комментариях ниже, я подумаю: если у вас сотни тысяч пользователей, и вы должны сохранить часть данных для каждого изих, каждый день в течение 90 дней, то в конечном итоге у вас будут миллионы фрагментов данных - не существует простого способа обойти это.То, что вы можете посмотреть, это минимизация этих данных.Если все, что вам нужно представить, это вычисленный ранг на пользователя в день, и предполагать, что ранг - это просто числовая позиция для данного пользователя среди всех пользователей (например, целое число от 1 до 200000), хранение двадцати миллионов таких записей не должнонеоправданно напрягать ресурсы базы данных.

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

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

Answer 2

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

- э-э-э ... упс ... это звучало так, как будто вы БЫЛИ, и ОСТАЛОСЬ более 20 миллионов записей ... это правильно?Это означает, что вы имеете дело с более чем 220 000 пользователей ???20 000 000 записей / 90 дней = около 222 222 пользователей

РЕДАКТИРОВАТЬ - по отзывам.

Имея 222 тыс. Пользователей +, я бы серьезно подумал о том, насколько важно «ранжирование», когда кто-то из 222 2222-е местоЯ бы спарил ежедневный рейтинг вниз, чтобы сказать 1000 лучших.Опять же, я не знаю, насколько это важно, но если кто-то не входит в топ-1000, разве это имеет значение ???

Answer 3

Не могли бы вы запустить автоматизированное задание, например, задание cron, которое проверяет базу данных каждый день или неделю и удаляет записи, которые старше 90 дней?