Google Appengine:这是一组好的实体组吗?
我正在尝试了解 Google AppEngine 中的实体组。我总体上理解它们,但由于听起来一旦创建对象就无法更改关系,并且我要进行大数据迁移,所以我想尝试第一次就正确。
我正在制作一个艺术网站,会员可以作为普通会员或少数非多态实体“类型”(艺术家、场地、组织、艺术家代表等)之一进行注册。例如,艺术家可以拥有艺术品,而艺术品又可以拥有其他关系(画廊、媒体等)。所有这些事情都通过引用连接起来,我知道您不需要实体组来仅仅进行引用。然而,一些引用需要存在,这就是我正在考虑实体组的原因。
来自文档: “对于实体组来说,一个好的经验法则是它们的大小应该约为单个用户的数据价值或更小。”
也就是说,我有几个希望是/否的问题。
问题 0:我认为您不需要实体组来进行交易。然而,由于实体组存储在大表的同一区域中,这有助于减少一致性问题和竞争条件。这是否可以公平地看待实体组和交易?
问题 1:保存子实体时,是否会隐式访问/保存任何父对象?即,如果我设置具有路径成员/艺术家/艺术品的实体组,如果我保存艺术品对象,成员和艺术家对象是否会更新/访问?我想不会,但我只是确定一下。
问题 2:如果问题 1 的答案是肯定的,则访问/更新是否仅沿路径向上传播,不会影响其他子级。即,如果我更新艺术品,则不会更新会员的其他艺术品子项。
问题 3:假设用户注册时会员及其关联帐户类型实体的存在非常重要,并且只有用户才会更新其会员和关联帐户类型实体,那么将它们放在实体组中是否有意义?
即会员/艺术家、会员/组织、会员/场地。
同样,假设只有用户能够更新 Artwork 实体,那么包含这些实体是否有意义?注意:引用艺术品的媒体/画廊/等可能与许多艺术品相关,而不仅仅是用户拥有的艺术品(即多对多关系)。
如果它按照我怀疑的方式工作(即 Q1/Q2 为“否”),那么将所有用户的位都放在一个实体组中是有意义的,因为它们都将位于 BigTable 的同一区域中。然而,将艺术品添加到实体组似乎可能违反“保持小”原则,并且老实说,除了在用户上传艺术品图像时节省带宽/重试之外,可能不需要处于交易中。
有什么想法吗?我处理实体组的方法错了吗?
I am trying to wrap my head around Entity Groups in Google AppEngine. I understand them in general, but since it sounds like you can not change the relationships once the object is created AND I have a big data migration to do, I want to try to get it right the first time.
I am making an Art site where members can sign up as regular a regular Member or as one of a handful of non-polymorphic Entity "types" (Artist, Venue, Organization, ArtistRepresentative, etc). Artists, for example can have Artwork, which can in turn have other Relationships (Gallery, Media, etc). All these things are connected via References and I understand that you don't need Entity Groups to merely do References. However, some of the References NEED to exist, which is why I am looking at Entity Groups.
From the docs:
"A good rule of thumb for entity groups is that they should be about the size of a single user's worth of data or smaller."
That said, I have a couple hopefully yes/no questions.
Question 0: I gather you don't need Entity Groups just to do transactions. However, since Entity Groups are stored in the same region of Big Table, this helps cut down on consistency issues and race conditions. Is this a fair look at Entity Groups and Transactions together?
Question 1: When a child Entity is saved, do any parent objects get implicitly accessed/saved? i.e. If I set up an Entity Group with path Member/Artist/Artwork, if I save an Artwork object, do the Member and Artist objects get updated/accessed? I would think not, but I am just making sure.
Question 2: If the answer to Question 1 is yes, does the accessing/updating only travel up the path and not affect other children. i.e. If I update Artwork, no other Artwork child of Member is updated.
Question 3: Assuming it is very important that the Member and its associated account type entity exist when a user signs up and that only the user will be updating its Member and associated account type Entity, does it make sense to put these in Entity Groups together?
i.e. Member/Artist, Member/Organization, Member/Venue.
Similarly, assuming only the user will be able to update the Artwork entities, does it make sense to include those as well? Note: Media/Gallery/etc which are references to Artwork may be related to lots of Artwork, not just those owned by the user (i.e. many to many relations).
It makes sense to have all the user's bits in an entity group if it works the way I suspect (i.e. Q1/Q2 are "no"), since they will all be in the same region of BigTable. However, adding the Artwork to the entity group seems like it might violate the "keep it small" principal and honestly, may not need to be in Transactions aside from saving bandwidth/retrys when users are uploading artwork images.
Any thoughts? Am I approaching Entity Groups wrong?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
出于许可目的,无需将艺术品作为儿童。但如果您需要对它们进行事务性修改(包括例如创建和删除),那可能会更好。例如:如果您删除帐户,则会删除用户实体,但在删除子实体之前,您会收到 DeadlineExceeded 消息或服务器崩溃。现在你有了一件孤儿艺术品。如果您的艺术家作品超过 1,000 件,则必须批量删除。
祝你好运!
It is not necessary to have the the Artwork as a child for permission purposes. But if you need transactional modification to them (including e.g. creation and deletion) it might be better. For example: if you delete an account, you delete the user entity but before you delete the child, you get DeadlineExceeded or the server crashes. Now you have an orphaned Artwork. If you have more than 1,000 Artworks for an Artist, you must delete in batches.
Good luck!