Google App Engine数据存储区中最有效的一对多关系？ [英] Most Efficient One-To-Many Relationships in Google App Engine Datastore?

问题描述

对不起，如果这个问题太简单了，我只进入9年级。

我正在努力学习NoSQL数据库设计。我想设计一个Google数据存储模型，以最大限度地减少读/写数量。

以下是一个博客文章的玩具示例和一对多评论关系。哪一个更有效率 - 将所有评论存储在StructuredProperty中，或者在评论模型中使用KeyProperty？

同样，目标是尽量减少读/写次数到数据存储区。您可以做出以下假设：

• 评论将不会独立于各自的博客文章检索。 （我怀疑这会使StructuredProperty更受欢迎。）


• 注释需要按日期，评分，作者等进行排序（数据存储中的子属性不能编入索引，所以也许这个）
  
• 博客文章和评论可能会在创建后被编辑（甚至删除）。

使用StructuredProperty：

from google.appengine.ext import ndb

class评论（ndb.Model）：
各种属性...

class BlogPost（ndb.Model）：
comments = ndb.StructuredProperty（ Comment，repeated = True）
各种其他属性...


使用KeyProperty： p>

from google.appengine.ext import ndb

class BlogPost（ndb。模型）：
各种属性...

class评论（ndb.Model）：
blogPost = ndb.KeyP roperty（kind = BlogPost）
各种其他属性...


随时提出任何其他考虑与有效地表示一对多关系有关最小化对数据存储的读/写数量有关。

谢谢。

解决方案

我可能是错的，但据我所知，一个StructuredProperty只是一个实体内的属性，但是具有子属性。 p>

这意味着阅读BlogPost及其所有评论只需花费一次阅读。所以当你渲染你的页面时，你只需要为整个页面使用一次读取操作。

每个写入也会更便宜。您需要一次读取操作来获取BlogPost，并且只要您不更新任何索引属性，它就只是一个写操作。

您可以在您从数据存储中读取实体后自行处理评论排序。

您必须将您的评论更新/编辑与交易同步，才能确保一条评论不会覆盖另一条评论，因为它们都修改同一个实体。如果每个人都在同一时间评论和编辑同一篇博文，您可能会遇到难以解决的问题。

在优化成本方面，您会遇到困难最大实体大小为1MB。这将限制每篇博文的评论数量。

使用KeyProperty会比较昂贵。

您需要阅读一篇文章才能获得博客文章，再加上1条查询以及1条针对每条评论的小型阅读。

每条评论都是新的实体，所以它至少会有4个写操作。您可能需要对排序顺序进行索引，这样最终会花费更多的写操作。

从好的一面来看，每篇博文都有无限的评论，您不必担心同步新评论。您可能需要担心编辑注释的同步，但如果将编辑限制为创建者，那应该不是问题。你不必自己排序。

这是一个成本与功能的折衷。

Sorry if this question is too simple; I'm only entering 9th grade.

I'm trying to learn about NoSQL database design. I want to design a Google Datastore model that minimizes the number of read/writes.

Here is a toy example for a blog post and comments in a one-to-many relationship. Which is more efficient - storing all of the comments in a StructuredProperty or using a KeyProperty in the Comment model?

Again, the objective is to minimize the number of read/writes to the datastore. You may make the following assumptions:

• Comments will not be retrieved independently of their respective blog post. (I suspect that this makes the StructuredProperty most preferable.)
• Comments will need to be sortable by date, rating, author, etc. (Subproperties in the datastore cannot be indexed, so perhaps this could affect performance?)
• Both blog posts and comments may be edited (or even deleted) after they are created.

Using StructuredProperty:

from google.appengine.ext import ndb

class Comment(ndb.Model):
    various properties...

class BlogPost(ndb.Model):
    comments = ndb.StructuredProperty(Comment, repeated=True)
    various other properties...

Using KeyProperty:

from google.appengine.ext import ndb

class BlogPost(ndb.Model):
    various properties...

class Comment(ndb.Model):
    blogPost = ndb.KeyProperty(kind=BlogPost)
    various other properties...

Feel free to bring up any other considerations that relate to efficiently representing a one-to-many relationship with regards to minimizing the number of read/writes to the datastore.

Thanks.

解决方案

I could be wrong, but from what I understand, a StructuredProperty is just a property within an entity, but with sub-properties.

This means reading a BlogPost and all its comments would only cost one read. So when you render your page, you only need one read op for your entire page.

Writes would be cheaper each too. You'll need one read op to get the BlogPost, and as long as you don't update any indexed properties, it'll just be one write op.

You can handle the comment sorting on your own after you read the entity out of the datastore.

You'll have to synchronize your comment updates/edits with transactions, to make sure one comment doesn't overwrite another, since they are both modifying the same entity. You may run into unsolveable problems if everyone is commenting and editing the same blog post at the same time.

In optimizing for cost though, you'll hit a wall with the maximum entity size of 1MB. This will limit the number of comments you can store per blog post.

Going with the KeyProperty would be quite a bit more expensive.

You'll need one read to get the blog post, plus 1 query plus 1 small read op for each comment.

Every comment is a new entity, so it'll be at least 4 write ops. You may want to index for sort order, so that'll end up costing even more write ops.

On the plus side, you'll have unlimited comments per blog post, you don't have to worry about synchronizing new comments. You might need to worry about synchronization for editing comments, but if you limit the edit to the creator, that shouldn't really be a problem. You don't have to do sorting yourself either.

It's a cost vs features tradeoff.

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