App Engine datastore Модель для ранжирования игры для 4 игроков - PullRequest
Новая
       9

App Engine datastore Модель для ранжирования игры для 4 игроков

0 голосов
/ 15 марта 2011

Здравствуйте, я пытаюсь изучить хранилище данных движка приложения, моделируя БД для хранения рейтинга пользователя и игровых баллов для игры для 4 игроков.

Пропускная способность записи будет низкой, поэтому я пытаюсьоптимизировать для чтения, так как будет много запросов, чтобы показать такие вещи, как:

  • Получить 100 лучших игроков по рангу
  • Показать детали игры (участники игроков и оценки) для10 последних игр, сыгранных любыми игроками
  • Показать сведения об игре (участвующие игроки и счета) за последние 10 игр, сыгранных определенным игроком

Я подумываю использоватьlistproperty заполнен ключами игроков на стороне Many, например: 

  class Player(db.Model):
      username = db.UserProperty()
      rank = db.IntegerProperty()

  class Game(db.Model):
      date_played = db.DateTimeProperty(auto_now_add=True)

      players = db.ListProperty(db.Key) 
      #this will always have 4 participant player keys

      scores = db.ListProperty(db.IntegerProperty)
      #the 4 game scores corresponding to the 4 participating players

У меня есть ощущение, что использование параллельных ListProperties для игроков и очков в классе Game не очень эффективно, можете ли выувидеть какие-либо недостатки в этом подходе?Есть ли лучший способ?

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

спасибо pmanacas

1 Ответ

0 голосов
/ 07 апреля 2013

с точки зрения проектирования базы данных, я думаю, что ваш лучший подход к ранжированию по-прежнему остается подходом log-aggregate-snapshot. При таком подходе у вас будет три основных компонента модели:

  1. Данные профиля игрока и другие вспомогательные данные для системы рейтинга. Чтение / запись в основном.

  2. Записи итоговых результатов в играх. Это будет только для добавления. Обновления не будут разрешены

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

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

...