0

I'm searching for the best practice to store a large amount of Comment Entities which have a one to many relationship to another entity.

I read a lot about the limitations about the datastore and don't know how to solve this.

I can't store them as structured properties due to the 1MB Entity Limitation.

Also Guido van Rossum answered the question about repeated properties with "if you have more than 100-1000 values" do not use repeated properties. So repeated properties are no solution for my comments, too.

Final Question: What is the best practice to solve this problem? Are ancestors an opportunity?

Edit: In this question about ancestor or reference properties Nick Johnson mentioned that "Every entity with the same parent will be in the same entity group, and writes to entity groups are serialized, so using ancestors here will slow things down if you're writing multiple entities concurrently. Since all the entities in a group are 'owned' by the user that forms the root of the group in your instance, though, this shouldn't be a problem - and in fact, what you're doing is actually a recommended design pattern."

What exactly does " writing multiple entities concurrently mean" ? When different user comment at the same time to that entity?

Community
  • 1
  • 1
ChrisS
  • 736
  • 2
  • 8
  • 21

1 Answers1

2

Depends on the amount you read / write per bill.

You can store references for more than 1000 (until an amount depending by the key size and how you reference them) as json compressed unindexed properties. But take care then with referencing and dereferecing that amount. Plus your overhead and data amount that you will transfer on each request will be big. You don't want though to be doing ops on 1000000 compressed entity keys on the server for just a simple request. If you take this way trying to optimize this approach do it on the client as smart as you can.

Go for ancestors and/or optimize your logic not to be consistent (eg it doesn't matter if a comment is not shown immediately) and use iterators or pointer or seeks (whatever it's called)

Jimmy Kane
  • 16,223
  • 11
  • 86
  • 117
  • Thanks Jimmy for your quick answer , so ancestors would be a good practice for comments. I will only query a limit of 10 comments once and then cursor to the next. I have updated my question with a topic about Ancestor, What exactly does " writing multiple entities concurrently mean" ? Are there some disadvantages? – ChrisS Jan 02 '14 at 21:51
  • 1
    @Yoda Exactely what Nick Johnson says is the best answer to what you need. What he means is if there are many writes at the same time that will take more for the request to be complete. If you don't get something like 60 comments per minute for every post (ancestor) then probably you are fine. Even if you get 120 reads though per minute there you have more bandwidth (from experience talking even though some stat's are around to compare these stuff). GAE is expensive on writes. Major thing to keep in mind. – Jimmy Kane Jan 02 '14 at 22:01
  • Thanks, for your explanation. Then i will go with ancestors! – ChrisS Jan 02 '14 at 22:09
  • @Yoda you can also store the key of the post in the comment as a reference property. Keep that in mind as well as more optimized approach. Ancestors best offer consistency. – Jimmy Kane Jan 02 '14 at 22:35