数据存储中的祖先关系 [英] Ancestor relation in datastore

问题描述

我有三个实体： user ， post 和 comment 。一个用户可能有多个帖子和一个帖子可能有多个评论。

我知道我可以像这样添加祖先关系：
$ b $ p $ user $（Grand Parent ）post（parent）comment（child）

我对祖先有点困惑。我从文档和搜索中读取祖先用于事务处理，每个祖先处于同一个实体组中，实体组存储在同一个数据存储节点中，这使得它的可伸缩性较差。这是正确的吗？

创建用户作为文章和 post 作为注释的一个好东西？

相反除此之外，我们可以在 post 实体（如示例中所示的 user_id >）中添加一个额外的属性并按它进行过滤。 / p>

哪个更好/更具可扩展性：由祖先过滤帖子或在<$ c $中添加额外属性 user_id 我知道这两种方法可以得到相同的结果，但我想知道哪一种更好？性能和可扩展性？

对不起，我是数据存储新手。

更新11/4/2017

大量用户正在使用此应用程序。很可能有更多的
比每秒一个职位。但单个用户不能创建超过每秒一个帖子。但多个用户可能会。如文档中所述，最大实体组写入速率为1 / s。还有可能使用祖先吗？

相同的评论。多个用户可以在同一个实体组中添加评论。这是
很可能在一秒内超过一个评论。

祖先查询更快？ 我在很多地方看过祖先查询比其他人快得多。

我知道他们之所以快速的原因是因为它创建实体组和存储相关数据在同一个节点中。因此，与单个节点相比，从单个节点获取数据所需的时间更少。 $ b

举例：如果 Asia节点中存有 strong>和 comment 存储在欧洲节点中，我希望获得帖子和评论那么数据存储API需要获取两个节点来完成请求。这使其变慢。而不是如果我创建祖先关系并使实体组创建更好的性能。



但是如果我不需要同时获取发布和评论数据会怎么样。如果我在单独的网页中需要 post 并且在单独的页面中需要 comment 。在这种情况下，数据存储区api只需要获取一个一次只能保存一个节点，不保存在单个节点或保存在多个节点中。在这种情况下，祖先使查询性能如何快速

？

解决方案

是的，您是正确的：所有与祖先有关的实体都在同一个实体组中，这提出了两个可扩展性问题：数据争用和最大实体组写入速率为1 / s。请参阅相关的是否存在实体组的最大尺寸？

使用祖先有一些优点，有些可能愿意为它们牺牲可伸缩性（参见将所有数据存储实体放入单个组的目的是什么？ / a>），但恕我直言，不适合您的应用程序：我认为您会同意，在创建后立即查看立即的每个新用户/帖子/评论并不重要即强一致性） - 它最终出现的事实是恕我直言，足够好。

根本没有祖先，并添加了额外的模型属性（实体密钥或者甚至只是实体从来没有祖先的实体密钥ID）允许交叉引用实体是更具可扩展性的方法，恕我直言适合您的应用程序。

I have three entities: user, post and comment. A user may have multiple posts and a post may have multiple comments.

I know I can add ancestor relations like this:

user(Grand Parent) post(parent) comment(child)

I'm little bit confused about ancestors. I read from documention and searches that ancestors are used for transactions, every ancestors are in same entity group and entity groups are stored in same datastore node which makes it less scaleable. Is this right?

Is creating user as parent of posts and post as parent of comments a good thing?

Rather than this we can add one extra property in the post entity like user_id as shown in example and filter by it.

Which is better/more scalable: filter posts by ancestors or add an extra property user_id in the post Entity and filter by it?

I know both approaches can get the same results but I want to know which one is better in performance and scalability?

Sorry, I'm new in datastore.

Update 11/4/2017

A large number of users is using this App. It's is quite possible there are more than one posts per sec. But A single user can not create posts more than one per sec. But multiple user may be. As described in documentations maximum entity group write rate of 1/s. Is it still possible to use Ancestor ?

Same for comments. Multiple user can add comment in a same entity group. It's is quite possible more than one comment in one sec.

Ancestor Queries are faster ?

I read in many places that ancestors queries are much faster than others.
As I know the reason why they are fast is that because it create entity group and store related data in same node. So, it require less time to get data from single node as compare to multiple nodes.

For Example: If post is store in Asia node and comment is store in Europe node and I want to get posts and comments then datastore API need to fetch two nodes to complete request. Which make it slow. Rather than if I create ancestor relation and make entity group which create a better performance.

But what if I don't need to get post and comment data at same time. If I need post in separate web page and comment in separate page.In this scenario datastore api need to fetch only one node at a time.It is not matter data save in single node or save in multiple node. What about query performance can ancestor make it fast in this case ?

解决方案

Yes, you are correct: all ancestry-related entities are in the same entity group, which raises 2 scalability issues: data contention and maximum entity group write rate of 1/s. See somehow related Is there an Entity Group Max Size?

There are advantages of using ancestries and some may be willing to sacrifice scalability for them (see What would be the purpose of putting all datastore entities in a single group?), but IMHO not for your kind of app: I think you'll agree that it's not really critical to see every new user/post/comment in random searches immediately after it is created (i.e. strong consistency) - the fact that it eventually appears is IMHO good enough.

Simply having no ancestry at all and adding additional model properties (entity keys or even just entity key IDs for entities which never have ancestors) to allow cross-referencing entities is the more scalable approach and IMHO fits well with your app.

这篇关于数据存储中的祖先关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！