python - 用于一致性和性能的 GAE 实体组/数据建模

Question

作为 in this post 的延续, 这是一个顶点式的问题来巩固我对 gae-datastore 的理解并对我的数据建模决策提出一些批评。我将修改由@Jimmy Kane 创建的自动点唱机示例，以更好地反射(reflect)我的真实案例。

在原始设置中，

---

假设您有一个自动点唱机，每个房间都有队列。人们正在将歌曲排队到每个自动点唱机的每个队列。

J=Jukebox, Q=queue, S=Song

   Jukebox       
   / |   \        
  Q1 Q2   Q3     
 / |  \   | \
S1 S2  S3 S4 S5

---

首先，填写歌曲模型:

Song(ndb.Model):
    user_key = ndb.KeyProperty()
    status = ndb.StringProperty()
    datetime_added = ndb.DateTimeProperty()

我的修改是添加一个User 可以CUD 歌曲到任何队列。在前端，用户将访问一个 UI 以查看每个队列中的歌曲，并进行更改。在后端，应用程序需要知道每个队列中有哪些歌曲，从每个队列中播放正确的歌曲，并在播放后从队列中删除歌曲。

为了让用户能够在队列中看到它的歌曲，我假设每个用户都是一个根实体，并且需要存储一个歌曲键列表

User(ndb.Model):
    song_keys = ndb.KeyProperty(kind='Song', repeated=True)

然后，为了检索用户的歌曲，应用程序将(假设 user_id 已知)

user = User.get_by_id(user_id)
songs = ndb.get_multi(user.song_keys)

而且，由于 get 是高度一致的，用户总是会看到非陈旧的数据

然后，当队列 1 播放完一首歌曲时，应用程序可以执行如下操作:

current_song.status = "inactive"
current_song.put()
query=Song.query(ancestor=ndb.Key('Jukebox', '1', 'Queue', '1')).filter(Song.status=="active").order(Song.datetime_added)
next_song = query.get()

我认为祖先查询确保当前歌曲的先前停用以及来自用户的任何 CUD 的一致表示是否正确？

最后一步是在交易中更新用户的 song_keys 列表

user = current_song.user_key.get()
user.song_keys.remove(current_song.key)
user.put()

总结和一些优缺点

• 一致性似乎是在正确的地方做正确的事情如果我的理解是正确的？
• 我应该关注 Jukebox 实体组的争用吗？
  • 我不希望它成为高吞吐量类型的用例，但我的现实生活场景需要随着用户数量的增加而扩展，并且 queue 的数量可能与user 的数量可能比 queue 多 2 到 5 倍。如果整个组被限制为每秒 1 次写入，并且很多用户以及每个队列都可能正在创建和更新歌曲，这可能是一个瓶颈
  • 一个解决方案是取消 Jukebox 根实体，让每个 Queue 成为其自己的根实体
• User.song_keys 可以很长，比如 100 个 song.key。 This article建议“避免在 ListProperty 中存储过大的键列表”。这里有什么问题？这是一个 db 概念，并且与 ndb 使用 repeated=True 属性选项处理列表的方式无关吗？

对这种方法的看法或对我根本误解的事情的批评？

• 大概，我也可以选择，只是对称翻转数据模型和实体组看起来像 User ->Song 并在Queue 模型中存储song_keys 列表

Answer 1

我认为您应该重新考虑强一致性对您的用例有多重要。据我所知，所有这些实体都具有很强的一致性并不重要。在我看来，最终一致性会很好。大多数时候你会看到最新的数据，只有在某些时候(阅读:真的很少)你会看到一些陈旧的数据。想一想您始终获得最新数据的重要性与它对您的应用程序的不利程度。就每秒读取次数而言，需要强一致性的实体不会以最有效的方式存储。

此外，如果您查看文档 Structuring Data for Strong Consistency ，您会看到它提到在使用该方法时每秒写入次数不能超过 1 次。

根据 AppEngine Model Class docs，实体组也会影响数据局部性.

如果您还阅读了关于 Google Spanner 的著名 Google 文档，第 2 节您将看到它们如何处理具有相同父键的实体。从本质上讲，它们靠得更近了。我假设 Google 可能对 AppEngine Datastore 使用类似的方法。在某些时候，根据 this来源 Google 将来可能会使用 Spanner 来处理 AppEngine Datastore。

还有一点，没有比通过 key 获取更快的获取更便宜的方法了。话虽如此，如果您能以某种方式避免查询，这可能会降低运行应用程序的成本。假设您正在开发 Web 应用程序，您可以将歌曲调存储在 JSON/文本对象中，然后使用 Prospective Search API 获取最新结果。这种方法需要做更多的工作，并且需要您接受最终一致性模型，因为数据在到达客户端时可能已经稍微过时了。根据您的用例(这显然不适用于小型应用程序和小型用户群)，节省的费用可能会超过成本。当我说成本时，我的意思是数据可能会稍微过时。

根据我的经验，强一致性并不是大量应用的必要条件。可以使用稍微陈旧的数据的应用程序数量似乎多于不能使用的应用程序。以 YouTube 为例，如果我没有立即看到所有视频，我真的不介意(因为数量如此之多，我什至不知道我是否看到了所有视频)。当你设计这样的东西时，首先问自己一个问题，是真的有必要提供最新的数据还是有点陈旧的数据就足够了？用户甚至可以分辨出区别吗？最新的数据比过时的数据要贵得多。