Лучший и самый эффективный способ расчета ELO-баллов для пользователей в базе данных - PullRequest
0 голосов
/ 27 сентября 2018

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

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

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

У меня было две идеи:

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

Обеспокоенность по поводу этих двух, которые у меня есть:

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

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

Вычисления-запросы для одной переменной вa вся формула, состоящая примерно из 12 переменных, в основном представляет собой простую 'COUNT FROM table', но некоторые из них похожи на подсчет "всех соединений моих соединений", который занимает несколько объединений.Для этого в таблицу нужно добавить значения счетчиков и увеличивать / уменьшать их при каждом действии, а также запускать формулу с этими значениями (запись в неделю).Это работает, но не может быть применено для каждой переменной (например, для соединений соединений).

Примечание: наша серверная часть основана на PHP с MySQL.

Мы также используем Redis, но я не уверен, что это может улучшить эти кусочки.

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

Мой основной пример - приложение 'Tinder', которое использует подобный алгоритм сортировки (возможно, с менее сложными переменными данных, потому что они не используют группы и сообщества, к которым вы можете присоединиться)

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

Где этовсе сводится к.Каков наиболее эффективный способ / без блокировки таблиц базы данных, чтобы сделать это, имея в виду, что будет момент, когда у нас будет 50 000 пользователей, например?

1 Ответ

0 голосов
/ 27 сентября 2018

Как бы я справился с этим:

  1. Реализация алгоритма в реальном времени.
  2. Измерение.Это действительно медленно?Попробуйте оптимизировать
  3. Все еще медленно?Переместите алгоритм в отдельный асинхронный процесс.Запустите процесс всякий раз, когда есть обновление.На самом деле это то же самое, что и 1, но оно не замедляет запросы PHP, и если оно будет загружено, может потребоваться больше времени, чтобы наверстать упущенное.
  4. Все еще медленно?Теперь вы можете оптимизировать, выполнив несколько изменений.

Если у вас сейчас 5000 пользователей, убедитесь, что он работает хорошо с 5000 пользователей.Вы не собираетесь расти до 50.000 в одночасье, поэтому приспособьтесь и инвестируйте в это по мере изменения вашей проблемы.Вы можете быть удивлены, где ваши проблемы с производительностью.

Хотя измерение является ключевым.Если вы действительно хотите поддержать пользователей 50K прямо сейчас, смоделируйте и измерьте.

...