Most Efficient One-To-Many Relationships in Google App Engine Datastore?

后端 未结 3 1134
耶瑟儿~
耶瑟儿~ 2021-02-04 05:28

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 min

3条回答
  •  别跟我提以往
    2021-02-04 06:25

    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.

提交回复
热议问题