MySQL и оперирование с рейтингом игроков

Question

[soulburner]

Допустим есть табличка с игроками, где у каждого игрока есть поле «score».

И мы хотим создать общий рейтинг игроков с сортировкой по этому полю.

Вопрос в том, можно ли как-то получить позицию заданного игрока в этом рейтинге? Т.е. есть игрок со score=12 и при сортировке по этому полю он будет в списке всех игроков на 50000-м месте.

Можно как-то определить это самое место легким движением руки?

Или вариант тут только один — раз в N времени выполнять проход по отсортированной таблице и запоминать рейтинги?

Объемы данных планируются от 100 тыс. юзеров до миллиона. Каким вообще образом создаются отсортированные рейтинги при таких больших объемах?

Answer 1

[SSoft]

Пусть есть таблица table: id, PlayerName, score

есть данные:

1 player1 12
2 player2 15
3 player3 14
4 player4 14
5 payer5 15
6 player6 12

SELECT COUNT(DISTINCT score) as position FROM table WHERE score >= (SELECT score FROM table WHERE PlayerName='player1' LIMIT 1)

Результат будет:

SELECT COUNT(DISTINCT score) FROM table WHERE score >= 12

15
count = 14 = 3 = position
12

Comments

[SSoft]

парсер лох.
count (12,14,15) = 3 = position

Answer 2

[Антон Корзунов]

UPDATE table SET spore=spore+1/rand(1,10000000000000)
берем и молча добавляет флуктуацию после запятой.
Если у вас spore — определена до 0.001 например — определите флуктуацию как 0.001\rand

Как вариант — фиксиовать эту флуктуацию на определенного юзера при создании этого самого пользователя.

Ну это детали.
Главное — в том что вы всегда можете выполнить

SELECT COUNT(*) FROM table WHERE spore<?

И получить точное значение, даже если ищем spore=12 и этих 12 несколько сотен тысяч

Comments

[justabaka]

Система «корейский топ». Если Великий Корейский Рандом к вам благосклонен, даже при одинаковом количестве очков вы будете всегда чуть выше в рейтинге, чем ваши соперники-неудачники!

Answer 3

[netAn]

Дальше пятидесятой позиции не так важно — какая именно по счету позиция у геймера. Поэтому часто обновлять «по честному» рейтинг имеет смысл для top50, где идёт рубка между самыми ярыми фанатами игры за первое место.
далее — движение по рейтингу не будет резким и будет кратно времени одной игры (интервал обновления рейтинга одного игрока) и не скакнет дальше среднего числа очков за один сеанс. Таким образом, рейтинги можно обновлять «на глаз» и бить их по группам.
Это уж если игроков совсем миллионы.
Но одновременно онлайн будут максимум сотни, так что сильно не мучайтесь оптимизацией этой таблицы.
А когда одновременно играть будут тысячи, сделаете рефакторинг кода и баз, а может и смените сервер.

Comments

[netAn]

И да — итоги сортировки рейтинга одинаковые для всех игроков, и нужна эта информация не чаще, чем пользователь смотрит на общий рейтинг.
Так что можно создавать временную таблицу, куда записывать соответствия айди пользователя, очков и рейтинга. По крону, раз в минуту, например.
А всем уже читать от туда, включая строку «рейтинг» в анкете юзера.

Answer 4

[justabaka]

Оффтопик: если юзеров планируется действительно так много, то лучше использовать разбиение на дивизионы/лиги, чем показывать «чистое» место. Мало кому приятно видеть, что он на 239676 месте.

Comments

[mdevils]

Очень плохая идея. Близард так сделал в СтарКрафте и нифига вообще непонятно. Мои друзья из другого дивизиона растут быстрее или медленнее меня в рейтинге с одинаковым числом побед. Одни в бронзе, другие в платине. Какой тут рейтинг нафиг?

[justabaka]

Дело не в количестве побед, а в их качестве. Все передвижения в рейтингах производятся на основе получения/потери очков, которые прямо отражают то, кто при каком текущем рейтинге кого победил: вынес алмазный бронзу — ничего не получил, вынесла бронза алмазного — вагон и маленькая тележка очков. При этом и у того, и у другого прибавилось по 1 победе.

Далее, низкоуровневых дивизионов очень много, а топовых — всего ничего. Есть самый-самый алмазный, он вообще один. Чем больше дивизионов, тем меньше требуемое до следующего места количество очков (хорошее распределение игроков), поэтому в бронзе расти легко.

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

Answer 5

[torsten]

партиционировать таблицу по полю score
тогда COUNT(*) FROM table WHERE score<? будет выполняться с использованием primary key на каждой из партиций, что должно работать очень быстро
)

Comments

[WebByte]

Чо-чо-чо, какой такой primary key на неуникальном наборе данных?
Ну и range скан даже на партиционированных данных или даст неточное число (превед, myISAM), или будет достаточно медленным.

[torsten]

primary key как раз уникальный, но так как таблица партиционирована, значит и primary key индекс тоже партиционирован, т.е. фактически мы получаем count'ы по таблицам без условия where, а MySQL такие запросы оптимизирует и выполняет очень быстро
MyIsam даст точный ответ, а вот InnoDB из-за конкурентных транзакций может и не точный вернуть результат

[WebByte]

С чего бы score быть уникальным, чтобы стать первичным ключем?
У двух пользователей не может быть одинакового количества баллов?

InnoDB как раз в силу транзакционности даст корректный ответ при уровне изоляции, отличном от READ UNCOMMITED. Только надо понимать на какой момент времени этот ответ будет корректным. MyISAM на моей памяти частенько выдавал разные значения для select (*) и select(id). Особенно, если давно не анализировался. Надо понимать, откуда MyISAM берет данные о количестве и почему они могут быть некорректными.

Answer 6

[Аркадий]

Можно создать переменную.

SELECT *, (@position:=@position+1) FROM `users`, (SELECT @position:=0) `a` WHERE 1

Comments

[netAn]

Пробовали. вычисления внутри запроса могут хорошо поднапряч сервер. Особенно со вложенными запросами

Answer 7

[Аркадий]

Но лучше «Или вариант тут только один — раз в N времени выполнять проход по отсортированной таблице и запоминать рейтинги?»