googleappengine:使用属性值作为键

2024-03-29 11:55:44 发布

您现在位置:Python中文网/ 问答频道 /正文

我还有下一个问题:

class Player(ndb.Model):
    player_id = ndb.IntegerProperty()

以及

class TimeRecord(ndb.Model):
    time = ndb.StringProperty()

所以TimeRecord的实例是Player的某个实例的子实例。 如果我需要在某个播放器上放置一个TimeRecord实例,我会这样做:

tr = TimeRecord(parent = ndb.Key("Player", Player.query(Player.player_id == int(certain_id)).get().key.integer_id()), time = value)

这个查询既昂贵又复杂。根据doc

qry = Account.query(Account.userid == 42)

如果您确定只有一个帐户具有该userid,那么您可能更愿意使用userid作为密钥。帐户。按id获取(…)比帐户.查询(…).get()。你知道吗

据我所知,我需要更改数据存储的结构:

使用player\ id作为player的键,并将TimeRecord(time)移动到player的属性。玩家id是唯一值。你知道吗

class Player(ndb.Model):
    time = ndb.StringProperty()

问:这是正确的方法吗?你知道吗

这类似于混合不同级别的实体继承,因为我认为每个数据都应该是不同的实体。以及由祖先键实现的继承。你知道吗

升级版: 但在这种情况下,我只能为某个玩家存储一个TimeRecord值。 我需要一套球员的时间记录。这个问题的解决方案是重复的吗?你知道吗


Tags: 实例idgetmodeltime帐户accountquery
1条回答
网友
1楼 · 发布于 2024-03-29 11:55:44

从关系数据库用户的角度来看,您提议的重新设计本质上是“去规范化”,这在关系领域几乎是一个坏词,但一旦您进入NoSQL,它绝对是“正常的”(哈哈)。你知道吗

如果您知道将如何查询和更新内容,反规范化可以提高性能(通常)和/或存储(有时)而牺牲一些灵活性。你知道吗

不过,一定要注意取舍。通常,反规范化会提高查询/读取的性能,但在更新过程中会增加额外的负担,这是可以接受的,因为通常读取的频率要比写入的频率高很多,但是您需要知道您的应用程序是否是这种情况。你知道吗

在检查您的特定用例时,我看到了存储方面的明显节省(特别是如果您可以为时间属性使用更专门的类型,请参见https://cloud.google.com/appengine/docs/python/ndb/properties#Date_and_Time),并且在检索时与后端的交互更少(因此性能更好)。它还简化了您的代码(简单性很好:更少的bug风险,更容易进行单元测试)。你知道吗

然而如果玩家经常需要保存新的“时间记录”,那么重复的属性会变得越来越大(在某个点上,尽管它仍然是一个单一的交互,但这会减慢速度;在最坏的情况下,它会“撞头”撞到单个实体的最大大小,即1兆字节,这将需要每个玩家数万条“时间记录”,但是,根本不知道你的应用程序,我无法判断这是否有风险。。。只有你才能!-). 你知道吗

查询也可能是一个问题,同样完全取决于你的应用程序需要什么。我特别想到了不等式问题。假设您需要所有时间记录大于'20141215-10:00:00',小于'20141215-18:00:00'的播放器。唉,对重复属性的不等式查询不会为您做到这一点!也就是说,如果你查询

ndb.AND(Player.time > '20141215-10:00:00',
        Player.time < '20141215-18:00:00')

你会得到一个时间大于第一个常数,时间小于第二个常数的玩家不一定是相同的时间!这意味着查询可能会返回比您希望的更多的玩家,您需要在应用程序代码中“过滤”生成的一堆玩家。你知道吗

如果您有一个实体,其中time不是一个重复的属性(比如您原来的TimeRecord实体),那么类似于这个查询的查询将正好返回一组感兴趣的实体(不过如果您需要在这些时间内获取玩家,那么您需要与存储后端,通常是一个ndb.get_multi,因此如果不了解应用程序的操作参数,就很难预测性能影响!)。你知道吗

这就是去规范化通常归结为:在“期望”的不同方面(简单性、节省存储、较少的后端交互、较少的数据进出后端)之间进行权衡,我们甚至不涉及原子事务和异步技术的适用性!-)只有深入了解应用程序的操作参数才能做出权衡。你知道吗

事实上,在选择“确定的”(ha!)之前,部署两个或多个原型(每个原型只针对一小部分用户)来获取有关其性能的实际数据(新的云监控产品可以帮助“获取实际数据”部分)架构,尽管将数据从原型迁移到“确定的”模式会产生开销。你知道吗

如果这个应用一夜之间就成功了,突然间你每秒会收到上万个查询,而不是你计划的数量级的减少,那么性能特征可能会突然改变,重新设计和迁移的痛苦可能是必要的(当然,这是一个很好的问题,但还是。你知道吗

相关问题 更多 >