Google Cloud Datastore真实世界的python模型示例

时间:2014-08-26 21:34:19

标签: python google-app-engine google-cloud-datastore database nosql

我是Google Datasore和Python的新手,但我有一个项目。即使有很棒的Google文档,我也想念一个真实世界的数据建模示例。所以这是我项目的一部分,以及模型化的主张和一些关于它的问题...... 我相信你可以帮助我更清楚地理解数据存储,我认为这些问题可以帮助像我这样的初学者看看如何建模我们的数据以获得很好的应用!

足球Feed包含有关比赛本身的一些一般信息,例如:比赛名称,比赛名称,赛季,比赛日,冠军队。

对于每个团队,胜利者和宽松者,我们都有比赛期间发生的行动的详细信息:卡片和目标。 对于卡片,我们有这些信息:颜色,发生的时间,玩家ID,原因,发生的时间。 对于目标,我们有时间段,玩家ID,时间,玩家助手ID。

我们还有每个团队的详细信息:玩家姓名,他们的位置(中心,中间......)和出生日期。

这里我想使用的模型使用python从足球Feed中将数据提取到数据存储中:

我有一些实体:团队,玩家,比赛,团队数据,卡片和目标。 对于每场比赛,我们将为每支球队提供两个TeamData,以及行动的细节(牌和目标) 我在TeamData和Match之间以及Card / Goal和TeamData之间使用了Key Property,但我认为我可以使用父关系,我不知道什么是最好的。

class Team(ndb.Model):
name = ndb.StringProperty()

class Player(ndb.Model):
teamKey = ndb.KeyProperty(Kind=Team)
name = ndb.StringProperty()
date_of_birth
position = ndb.StringProperty()

class Match(ndb.Model):
name_compet = ndb.StringProperty() 
round = ndb.StringProperty()
season
matchday
team1Key = ndb.KeyProperty(Kind=Team)
team2Key = ndb.KeyProperty(Kind=Team)
winning_teamKey = ndb.KeyProperty(Kind=Team)

class TeamData(ndb.Model):
match = ndb.ReferenceProperty(Match, collection_name=’teamdata’)
score
side(away or home) = ndb.StringProperty()
teamKey = ndb.KeyProperty(Kind=Team)

class Card(ndb.Model):
teamdata = ndb.ReferenceProperty(TeamData, collection_name=’card’)
playerKey = ndb.KeyProperty(Kind=Player)
color = ndb.StringProperty()
period = ndb.StringProperty()
reason = ndb.StringProperty()
time
timestamp

class Goal((ndb.Model):
teamdata = ndb.ReferenceProperty(TeamData, collection_name=’goal’)
period = ndb.StringProperty(Kind=Player)
playerkey = ndb.KeyProperty(Kind=Player)
time = ndb.StringProperty()
type = ndb.StringProperty()
assistantplayerKey = ndb.KeyProperty(Kind=Player)

我的问题在这里:

这种模式化是否“正确”并允许基本查询(哪支球队在某一天比赛,对于特定比赛的牌和目标(球员,助理,理由,时间)的细节结果是什么)

和更复杂的查询(某个玩家在某个赛季中有多少个进球)?

我并没有真正看到SQL数据库和NoSQL数据库(如DataStore)之间的区别,除了数据存储区处理密钥而不是我们。你能清楚地解释一下我对NoSQL模型的优势吗?

谢谢你的帮助!

1 个答案:

答案 0 :(得分:1)

NoSQL使其更快,并且不依赖于扫描的数据大小。对于SQL中的3TB表,无论你返回什么,它都会采用相同的"计算时间"服务器端。在数据存储区中,由于它直接扫描您需要的位置,因此RETURNED行/列的大小实际上决定了它将花费的时间。

另一方面,它需要更多的时间来保存(因为它需要保存到多个索引),并且它不能进行服务器端计算。例如,使用数据存储区,您不能使用SUM或AVERAGE。数据存储区仅扫描并返回,这就是为什么它如此之快。它从来没有打算代表你做计算(所以答案是"它可以做更复杂的查询吗?"不是。但那不是你的模型,那是数据库)。有助于做这些总和的一件事是将计数器保存在不同的实体中并根据需要进行更新(有另一个实体" totalGoals"" keyOfPlayer"" numberOfGoals&#34)

值得一提的是最终的一致性。在SQL中,当您"插入"时,数据在表中并可立即检索。在数据存储区中,一致性不是立竿见影的(因为它需要复制到不同的索引,您无法知道插入是否完全完成)。有办法强制一致性。祖先查询就是其中之一,直接通过密钥查询或打开数据存储区查看器。

另一件事,即使它不会碰到你(同样的想法"为其他初学者提供一个问题,我尽量包括我能想到的)是祖先查询,为了使它们安全,当你查询它们时,实际上冻结它们正在使用的实体组(实体组=父母+孩子+孩子的孩子+等)。

其他问题?请参阅有关entitiesindexesqueriesmodeling for strong consistencies的文档。或者随意问,我会编辑我的答案:)