Оптимизация расчета рейтинга ЭЛО

Здравствуйте. Пытаюсь посчитать рейтинги ЭЛО для теннисистов. Есть такая исходная таблица (Пример ~27к строк). Я попытался реализовать это с помощью функций, цикла и справочника. Мне необходимо делать ежедневный расчет на базе с 500к+ строк, и я столкнулся с проблемой скорости выполнения. Файл ELO_test, который прикрепил ниже, считает число игр (они используются в дальнейшем расчете), общий рейтинг + рейтинг на каждом покрытии и результирующий рейтинг. Можно ли решить эту задачу без циклов и справочника, если да, то как? Еще была идея сделать это через две таблицы: просчитать все один раз, сохранить в отдельной таблице, а для будущих матчей извлекать необходимые данные из сохраненной таблицы и после расчета также сохранять их в эту главную таблицу. Но тоже не знаю как это сделать... Хочу добиться результата при котором все будет считаться за 3-5 мин, ну или быстрее( если это возможно). Сейчас это мин под 30 (с учетом расчета всех перечисленных выше рейтингов на базе данных 500к+ строк)

Немного про рейтинг: Изначально у каждого игрока рейтинг 1500 пунктов, после игры он изменяется, в худшую либо в лучшую сторону в зависимости от результатов игры.Скажем у победителя рейтинг стал 1510, у проигравшего 1490 . И на следующий матч нужно уже брать этот обновленный рейтинг

P.S в файле показан расчет только общего рейтинга Эло, для покрытий методология расчета такая же

Вложения

Documents.rar (353.3 Кб, 12 просмотров)

0

1.

Сообщение от Xelar93 Мне необходимо делать ежедневный расчет на базе с 500к+ строк

Зачем ежедневно пересчитывать всю таблицу?
2. Оптимизировать надо только этот кусок:
или расчет параметров тоже?
Сколько времени занимает каждый блок?

0

Расчет каждого блока идёт мин по 7. Таких блока 4. А это вы мне ещё с играми помогли, до этого я их тоже через справочник считал. Про пересчет в этом и вопрос. Новые матчи появляются каждый день. Я представляю себе это так: 1). Сделать расчет по моему коду для 2010 года. Потом сгруппировать данные так,чтобы были только колонки Player, общий рейтинг+рейтинги на покрытиях+результирующий рейтинг и количество игр, сохранить это в отдельную таблицу. А на новый сезон в условие где идёт проверка нахождения имени в словаре добавить как-то чтобы брало те конечные рейтинги из сохранённой таблицы для нужного игрока. Но возможно и как-то по-другому все это можно сделать

0

Тут очень много моментов. Пересчет рейтинга надо делать построчно, это не sql-ная операция и если делать это в массиве numpy на данной выборке это займет около секунды, вместо 13 как сейчас.
Но дело даже не в этом. 500К - это очень маленькая таблица и расчеты должны вестись максимум порядка нескольких секунд. При правильном подходе, конечно.
Во-первых, нет смысла делать пересчет всей таблицы. Можно сделать срезы рейтингов по годам (или даже полугодам или месяцам) и делать пересчет только по тем игрокам и с той даты, по которым прошли изменения.
Во-вторых, вы очень нерационально подходите к пересчету, начиная со сбора параметров (самый затратный join у вас выполняется на каждый параметр, хотя его достаточно было сделать один раз) и заканчивая самими функциями расчета рейтинга, которых должно быть ровно 1, а не сколько вы наплодили. И пересчет всех рейтингов можно провести за один проход. Если все это сделать, то пересчет будет мгновенный. Даже без срезов рейтингов, полный пересчет будет измеряться секундами, а не минутами.
Есть много других нюансов, эффект от которых на такой маленькой таблице не скажется (или скажется незначительно), но считаются просто правилами хорошего тона для sql-щика. Например, работать не со строковыми значениями (player), а только с числовыми (player_id). Или выделять под поля в таблицах ровно столько места сколько необходимо, а не 64 бита как это делает панда по умолчанию.
Мог бы привести ваш код в божеский вид, но сделать это смогу не ранее следующей недели.

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

Добавлено через 7 минут
Это дело не быстрое. Просто смотрите на примеры кода и в голове прокручивайте, насколько вам ясно, что в нем написано. И откладывайте себе где-нибудь на подкорке, каким образом достигается читабельность. Код - это как книга и стиль имеет такое же важное значение, как сюжет и прорисовка деталей.

3

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

0

Одним из вариантов оптимизации и ускорения вычислений -> преобразование колонок Player1 и Player2 с помощью pd.get_dummies : https://pandas.pydata.org/pand... mmies.html
В дальнейшем с помощью numpy вычисления существенно ускорятся...

1

Gdez, dummy, как правило, нам нужны для регрессии. А здесь get_dummies приведет к появлению тысячи переменных и непонятно, что потом с этим богатством делать.

0

Red white socks, обработка логического массива существенно быстрее строкового.
Но как вариант можно и pd.factorize - количество уникальных игроков существенно меньше строк фрейма. Экономия памяти и опять же обработка типа int быстрее str (для pandas и numpy)

0

Gdez, просто мне казалось что в данном случае с дамми неудобно работать будут. Я упоминал, что работать нужно с числовыми значениям, но на такой таблице оценивал прирост всего процентов на 20-30. Сам факт работы в numpy (пусть даже с словарем со строковыми ключами ) увеличит скорость на порядок.

0

Xelar93, скинь полную входную таблицу

0

Разделитель ;

Вложения

SQL.rar (6.68 Мб, 7 просмотров)

0