用于对 4 人游戏进行排名的 App Engine 数据存储模型
您好，我正在尝试通过建模数据库来存储 4 人游戏的用户排名和游戏分数来学习应用程序引擎数据存储。
写入吞吐量会很低，因此我尝试优化读取，因为会有很多查询来显示以下内容：
- 按排名获取前 100 名玩家
- 显示最后 10 名的游戏详细信息（参与玩家和分数）任何玩家玩过的游戏
- 显示某个玩家玩过的最后 10 场游戏的游戏详细信息（参与玩家和分数）
我正在考虑使用在多方上填充玩家键的列表属性，如下所示：
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
我有一种直觉在 Game 类下对玩家和分数使用并行 ListProperties 的效率不是很高，您能看出这种方法有什么缺点吗？有更好的方法吗？
我想过使用一个单独的关系类来存储游戏和玩家的引用属性，但这似乎有点矫枉过正，并使查询变得更加复杂。
谢谢 普马纳卡斯
Hi there I'm trying to learn the app engine datastore by modeling a db to store user rank and game scores for a 4 player game.
The write throughput will be low, so I'm trying to optimize for reads, as there will be lots of queries to show things like:
- Get the top 100 players by rank
- Show the Game details (participant players and scores) for the last 10 games played by any players
- Show the Game details (participant players and scores) for the last 10 games played by a certain player
I'm thinking of using a listproperty populated with player keys on the Many side, like this:
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
I have a gut feeling that using the parallel ListProperties for players and scores under the Game class is not very efficient, can you see any drawbacks in this approach? Is there a better way?
I thought of using a separate relationship class that stores reference properties to both games and players, but that seems a bit like overkill, and makes queries more complex.
thanks
pmanacas
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从数据库设计的角度来看，我认为最好的排名方法仍然是日志聚合快照方法。在这种方法中，您将拥有三个基本模型组件：
玩家档案数据和排名系统的其他辅助数据。主要是读/写。
比赛最终得分记录。这将是仅附加的。不允许更新
按时间范围划分的分数快照/摘要。例如，您可以对历史数据进行每周和每月快照，并能够根据当前统计数据生成排行榜，无论是从快照摘要前滚还是独立生成。快照只能附加，一旦某个时间段附加了快照，您就不能再将游戏/得分插入到封闭的时间段中。
这样做的优点之一是您可以非常快速且很好地生成历史报告。例如，如果您甚至基于每周生成快照，则可以通过总结整周然后将部分周的原始结果添加到其中来生成每月评级，这意味着聚合不超过几天的数据来生成这样的报告。年度排名可以根据月度排名生成。
from a database design perspective, I think your best approach for rankings is still the log-aggregate-snapshot approach. In this approach you will have three basic model components:
Player profile data and other auxiliary data for the ranking system. Read/write mostly.
Records of final scores in games. This will be append-only. Updates will not be permitted
Snapshot/summary of scores by time-frame. For example, you might do weekly and monthly snapshots for historical data and be able to generate a leaderboard based on current statistics either rolled forward from, a snapshot summary or generated independently. Snapshots are append-only and once a period of time has a snapshot attached you can no longer insert games/scores into a closed period.
One of the advantages of this is you can generate historical reports quite quickly and quite well. For example if you are generating snapshots even based per week, you can generate monthly ratings by summing up the whole weeks and then adding the partial weeks' raw results into it, meaning aggregating no more than a few days' data to generate such a report. Yearly rankings could be generated based on monthly rankings.