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

Question

我是Google Datasore和Python的新手，但我有一个关于它的项目。即使有了很棒的Google文档，我也错过了一个真实的数据建模示例。所以这里是我的项目的一部分，还有一个模型化的命题和一些关于它的问题…我相信您可以帮助我更清楚地理解Datastore，我认为这些问题可以帮助像我这样的初学者了解如何对我们的数据进行建模，从而拥有一个出色的应用程序！

足球提要包含有关比赛本身的一些常规信息，例如:比赛所属的比赛名称、游泳池名称、赛季、比赛日期、获胜球队。

对于每一支球队，无论是胜利者还是失败者，我们都有比赛中发生的动作的细节:卡片和目标。对于卡片，我们有这些信息:颜色、发生的时间、玩家id、原因、发生的时间。对于目标，我们有句点，球员id，时间，球员助理id。

我们还有每个球队的细节:球员的名字，他们的位置(中心，中间的…)，和出生日期。

在这里，我想使用python将足球提要中的数据摄取到数据存储中的模型：

我有一些实体:团队，球员，比赛，TeamData，卡片和目标。对于每一场比赛，我们将有两个TeamData，每个团队一个，以及行动的细节(卡片和目标)我使用了TeamData和match之间以及卡片/目标和TeamData之间的关键属性，但我认为我可以使用父级关系，我不知道哪个是最好的。

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数据库和像DataStore这样的NoSQL数据库有什么区别，只是数据存储处理的是键，而不是我们。你能清楚地给我解释一下这种NoSQL模型化有什么优势吗？

谢谢你帮我！

Answer 1

NoSQL让它变得更快，而且不依赖于扫描的数据大小。对于SQL中的一个3TB的表，无论你返回什么，服务器端的“计算时间”都是一样的。在数据存储中，由于它直接扫描您需要的位置，因此返回的行/列的大小实际上决定了它将花费的时间。

另一方面，它需要更多的时间来保存(因为它需要保存到多个索引)，并且它不能进行服务器端计算。例如，对于数据存储，您不能求和或求平均值。数据存储只扫描并返回，这就是它如此之快的原因。它从来没有打算代表您进行计算(所以答案是“它能做更复杂的查询吗？”不是。但这不是你的模型，那是数据存储)。在不同的实体中保存一个计数器，并根据需要更新它(让另一个实体"totalGoals“与"keyOfPlayer”和"numberOfGoals")可以帮助完成这些类型的求和。

值得一提的是最终的一致性。在SQL中，当您“插入”时，数据在表中，并且可以立即检索。在数据存储中，一致性不是即时的(因为它需要复制到不同的索引，您无法知道插入何时完成)。有一些方法可以强制一致性。祖先查询就是其中之一，就像通过键直接查询一样，或者打开您的数据存储查看器。

另一件事，即使它不会触动你(在相同的想法中“为其他初学者提供一个问题，我试图包括我能想到的尽可能多的问题)是祖先查询，以使他们安全，实际上冻结了他们正在使用的实体组(实体组=父母+孩子+等)，当你查询一个实体组时。

还有其他问题吗？请参阅有关entities、indexes、queries和modeling for strong consistencies的文档。或者请随意提问，我将根据结果编辑我的答案:)