我是googledatastore和python的新手，但我有一个关于它的项目。即使有了伟大的google文档，我还是错过了一个真实的数据建模示例。所以这里是我项目的一部分，一个模型化的提议和一些关于它的问题…
我相信您可以帮助我更清楚地理解数据存储，我认为这些问题可以帮助一些像我这样的初学者了解如何建模我们的数据，使其具有一个伟大的应用程序！
足球feed包含一些关于比赛本身的一般信息，例如：所属比赛的名称、游泳池名称、赛季、比赛日、赢家球队。
对于每一支球队，无论是赢家还是失败者，我们都有比赛中发生的动作细节：扑克牌和进球。
对于这些卡片，我们有这些信息：颜色，发生的时间，玩家身份，原因，发生的时间。
对于进球，我们有时间段，球员编号，时间，球员助理编号。
我们也有每个队的细节：球员姓名，他们的位置（中间，中间…）和出生日期。
在这里，我想使用python将来自soccer feed的数据摄取到数据存储：
我有一些实体：团队，球员，比赛，团队数据，卡片和进球。
对于每场比赛，我们将有两个团队数据，每个团队一个，以及行动的细节（卡片和目标）
我使用了TeamData和Match之间以及Card/Goal和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数据库和nosql数据库（如datastore）之间的区别，只是数据存储处理的是键，而不是我们。你能清楚地告诉我这种nosql建模有什么好处吗？
谢谢你帮我！
最佳答案
nosql使其速度更快，而且不依赖于扫描数据的大小。对于sql中的3terabytes表，无论您返回什么，它都将占用相同的“计算时间”服务器端。在数据存储中，由于它直接扫描您需要的位置，因此返回的行/列的大小实际上决定了它将花费的时间。
另一方面，它需要更多的时间来保存（因为它需要保存到多个索引），并且它不能进行服务器端计算。例如，对于数据存储，不能求和或求平均值。数据存储只扫描和返回，这就是为什么它这么快。它从未打算代表您进行计算（所以回答“它能做更复杂的查询吗？”不是，但那不是你的模型，那是数据存储）。有一件事可以帮助完成这些总和，那就是在不同的实体中保留一个计数器，并根据需要更新它（让另一个实体“totalgoals”使用“keyofplayer”和“numberofgoals”）。
值得一提的是最终的一致性。在sql中，当您“插入”时，数据就在表中，并且可以立即检索。在数据存储中，一致性不是即时的（因为它需要复制到不同的索引，所以您无法知道插入何时完全完成）。有一些方法可以强制保持一致性。祖先查询是其中之一，直接按键查询或打开数据存储查看器也是如此。
另一件事，即使它不会触动你（同样的想法是“提供一个问题给其他初学者，我尽量包括我能想到的）是祖先查询，使他们安全，实际上冻结他们使用的实体组（实体组=父母+孩子+孩子的孩子+等）当你查询一个。
其他问题？请参阅有关entities、indexes、queries和modeling for strong consistencies的文档。或者随便问，我会修改我的答案：）