Как реализовать интернет-рекорды в Google App Engine

Я хочу использовать в своей игре рекорды из интернета. И сообщать игрокам, какое у них место (не только топ100 или что-то в этом роде). В обычном SQL это выглядело бы так:

ВЫБРАТЬ СЧЕТЧИК (*) ОТ Очки ГДЕ очки>: newUsersPoints

и в GQL есть что-то похожее

db.GqlQuery ("ВЫБРАТЬ * ИЗ Score WHERE points>: 1", newUsersPoints) .count ()

но поскольку count () ограничен только 1000, в моем случае это не будет очень полезно. У вас есть идеи, как это реализовать?

У меня два

Первый:

  1. Идея использования счетчиков сегментирования (http://code.google.com/intl/pl/appengine/articles/sharding_counters.html) Создайте новую «таблицу», в которой хранится, сколько баллов находится в некотором диапазоне (from_points, to_points)

  2. Просуммируйте все счетчики из приведенной выше таблицы, где range.to_points ‹newUsersPoints

  3. Найдите, на сколько баллов больше баллов в диапазоне, где новый балл - db.GqlQuery («ВЫБРАТЬ * ИЗ баллов ГДЕ баллов>: 1 И баллов> =: 2 И баллов‹: 3 », newUsersPoints, range.from_points, range. to_points) .count () + sumfrom2

  4. Найдите диапазон, в котором находится новый счет, и увеличьте его счетчик

  5. Разделите диапазоны, счетчик которых больше 1000 (или 999), чтобы 3. не достигала предела.

  6. Добавить новый счет в таблицу результатов

Что довольно сложно и подвержено ошибкам. Мы могли бы увеличить некоторый диапазон и тайм-аут перед добавлением оценки. (не транзакционный)

Вторая идея:

Время от времени (один раз в день?) Сортируйте все результаты по баллам и присваивайте им новые позиции (сценарий может Тайм-аут, поэтому мы должны делать это по частям)

Чтобы узнать, в каком месте новый счет, мы просто делаем

db.GqlQuery ("SELECT * FROM Score WHERE points>: 1 LIMIT 1", newUsersPoints) .get (). precalculated_position + 1

Есть другие идеи?


google-app-engine gql gqlquery
person Przemyslaw Zych    schedule 04.03.2009    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Я реализовал Ranker в нескольких приложениях GAE. Это приложения Facebook, в которые играют от тысяч до сотен тысяч человек. Он работает хорошо, но для моих целей у него есть один большой недостаток: вам нужно заранее объявить окончательный диапазон, в который упадут баллы участника. Так что это плохо по двум причинам:

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

  2. в начале конкурса, когда все собраны вместе около нуля, древовидная структура, используемая ranker.py, неэффективна. дерево уходит очень глубоко и почти не использует свою ширину.

Другими словами, ranker.py отлично подходит для случаев, когда у вас есть участники, чьи оценки случайным образом равномерно распределяются по известному диапазону значений. Для других целей это менее чем оптимально.

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

person mainsocial    schedule 10.06.2009

arrow_upward
4
arrow_downward

Этот , вероятно, будет интересна. Также похоже, что есть библиотека, ranklist, специально для этого .

По сути, похоже, что они сделали что-то похожее на сегментированные счетчики.

person Richard Levasseur    schedule 04.03.2009