On Thursday, April 14, 2016 at 3:31:10 AM UTC+2, Susan Lin wrote: > > Thank you very much for the detail response ! One question as I am not > famiar with the parent type entities. If I need to list all the contacts > would this result in 1 read operation of 200 read operations (considering > 200 friends)?
It depends on the implementation. Considering the "most expensive" user with 200 friends and 100 friend request: For a keys-only query, as used for counting the number of friends to validate if the 200+100 limits is reached, these are 300 small ops (all free). If you run a projection query, which should be possible for many of your use-cases of this query, the results would also be 300 small ops (all free). If you retrieve fully all objects with the query, it is 300 read ops in the old pricing model, or 300 entity reads in the new pricing model. In other queries or use-cases, it could be much less if a recently read object with this key already is in memcache, so that read hits the memcache instead of the datastore. Since all 300 friends are unique in the result, memcache may only get a chance for hits in subsequent requests for the same friend list. So, for each non-hit entity read, it is a read op (or entity read). memcache hits are free. Another option to reduce the reads would be to run the query page-wise only, e.g. 5 or 20 friends, maybe the newest first, because that's likely the most interesting for users. That would be potentially up to 20 read ops (or entity reads) for a page size of 20. In the use-case where you want to show the current user all their friends and friend requests, or display the list on the profile page of a user, it could make sense to use Search API instead (if that is available on your environment). If the app mirrors any writes to Friend entites also into one search document per friend/request, the app doesn't even need to ask the Datastore. Although search documents are not transactional and can be a little stale (depending on the implementation maybe 1 or 2 seconds) the Search APi calls are free (some limitations and quotas to consider). Extra benefit: users can run full text search in the list, sorting and filtering is all possible. I think this solution would be more interesting for EMails, rather than running datastore queries. So your app uses datastore for reading/writing transactionally, but for users to read and browse, your app uses Search API. Given a current user can only search through their own mails of course :) Finally, one alternative I want to re-iterate: the use of big entities, here with repeated properties, although I don't think we are safely with-in the entity size limit of 2MByte per entity. You use the Friend kind model as suggested, but whenever the app creates/updates/deletes a Friend object, also mirror the change into a big entity, e.g. the FriendParent kind. If the write happens in the same transaction with the Friend objects, it doesn't affect the 1 write / sec limit, as it happens in the same entity-group anyway. It causes more write-ops (or 1 entity write, I guess), but also reduces the read ops (or entity reads) to 1 for showing all friends. The application code would be a little more complex to make this work fail-safe though: FRIENDCOPY (Model with no own ID) -key (of friend2) -name (of friend2) -imgURL (of friend2) -status FRIENDPARENT -friends (repeated structured property of kind FRIENDCOPY) As I've mentioned, I have my doubts your app could take this approach given the 300 potential values, unless you come up with a good idea of splitting the list up into multiple entities which the app still can maintain programmatically and safely. However, it can be a useful pattern in other cases. -- HATZIS Edelstahlbearbeitung GmbH Hojen 2 87490 Haldenwang (Allgäu) Germany Handelsregister Kempten (Allgäu): HRB 4204 Geschäftsführer: Paulos Hatzis, Charalampos Hatzis Umsatzsteuer-Identifikationsnummer: DE 128791802 GLN: 42 504331 0000 6 http://www.hatzis.de/ -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/1cedeb72-55ee-4c21-a8fa-da0650858a5c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
