GAE对NDB层次结构和实体组的影响 [英] GAE Implications of NDB hierarchy and entity groups

问题描述

我正在尝试更好地了解中描述的深层次层次的含义GAE NDB文档

I'm trying to better understand the implications of the deep hierarchy described in the GAE NDB docs

例如，对所有者属于的邮件的修订版可能有一个看起来像

"For example, a revision of a message that "belongs to" an owner, might have a key that looks like"

rev_key = ndb.Key('Account', 'Sandy', 'Message', 'greeting', 'Revision', '2')

我解释这个意思是说如果我做 Revision（parent = rev_key ）.put（）然后我将在Revision = 2级别有一个实体组，意思是祖先查询，其中 ancestor = rev_key 将具有很强的一致性，写入 parent = rev_key 将被限制在1 /秒。

I interpret this to mean that if I do Revision(parent=rev_key).put() then I will have an entity group at the Revision=2 level meaning ancestor queries where ancestor=rev_key will have strong consistency and writes where parent=rev_key will be limited to 1/sec.

但是层次结构进一步的影响是甚么？

But what are the implications further up the hierarchy?

例如，说我有

rev_key_B = ndb.Key('Account', 'Sandy', 'Message', 'greeting', 'Revision', '3')

写入速度在 rev_key_B 级别限制为1 /秒，或者由于它们共享父级父级，即 ndb.Key（'帐户'，'桑迪'，'信息'，'问候'），写入速度限制在祖先路径上更高，最终到整个实体组一直到 ndb.Key（'Account'，'Sandy'）？

Is write speed limited to 1/sec at the rev_key_B level or, since they share a parent's parent, i.e. ndb.Key('Account', 'Sandy', 'Message', 'greeting'), is write speed limited even higher up the ancestor path and, ultimately, to the entire entity group all the way up to ndb.Key('Account', 'Sandy')?

同样的问题re：强一致性。 Revision.query（ancestor = ndb.Key（'Account'，'Sandy'，'Message'，'greeting'））具有很强的一致性？

Same questions re: strong consistency. Would Revision.query(ancestor=ndb.Key('Account', 'Sandy', 'Message', 'greeting')) have strong consistency?

推荐答案

我们来看看

rev_key = ndb.Key('Account', 'Sandy', 'Message', 'greeting', 'Revision', '2')

意味着每个实体在实体路径之后具有很强的一致性。所以你是正确的。

Means that every entity has strong consistency following the entity path. So you are correct.

让我们看到它在行动中：创建实体

Lets see it in action: Create the entities

account_sandy = Account.get_or_insert('Sandy')
sandy_message = Message.get_or_insert('greeting', parent=account_sandy.key)
sandy_message_rev = Revision.get_or_insert('2', parent=sandy_message.key)

这将赋予您强大的一致性，并授予您查询所有上述实体的能力交易也是如此。

That will give you strong consistency and grant you the ability to query all the above entities inside transactions as well.

我正在使用 get_or_insert 提供的密钥不存在。这要求密钥或ID是唯一的。所以这样你不能有2个消息与 Greeting 和 Sandy作为父。

I am using the get_or_insert which does what it says inside a transaction efficiently creating an entity if it does not exist with the key provided. This requires the key or id to be unique. So this way you cannot have 2 messages with Greeting and Sandy as parent.

键的工作方式就像二叉树。

The way keys work is like a binary tree.

S = Sandy，M =消息，R =修订

S = Sandy, M=Message, R=Revision

    Sandy
   / |   \
  M1 M2   M3 
 / |  \   | \
R1 R2  R1 R1 R2

每个路径到最后或更短可以在交易中运行并提供强大的一致性*。

在评论中回复：

As这个例子不足以表明GAE和NDB的效率可能在下面。

As this example is not sufficient to show the efficiency of GAE and NDB maybe the below will.

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

Imagine that you have a jukebox with queues per room let's say. And people are queueing songs to each queue of each jukebox.

J = Jukebox，Q =队列，S = Song

J=Jukebox, Q=queue, S=Song

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

在这个例子中，使用路径很方便，所以每个操作由一个用户，知道你的自动点唱机，排队可以CUD的歌曲实体与一致的点唱机，队列和歌曲。

In this example it is convenient to use paths, so each operation by a user, knowing wich jukebox, queue can CUD the song entity with consistency to jukebox, queue and song.

* Btw你也可以锁定路径不启动从根

*Btw you can also lock paths not starting from root

另请记住，事务中的查询必须包含祖先过滤器

这篇关于GAE对NDB层次结构和实体组的影响的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！