1

I have a question-answer-comment application(similar to stackoverflow). The questions and their related answers and comments logically form part of entity groups as defined in App Engine Docs .

I want to use entity groups/ancestor paths to group my entities together for 2 reasons:

  1. Improve query efficiency by storing Question and Answer entities together physically
  2. Allow me to perform ancestor queries thus eliminating the need for me store the Answer keys on the Question entity (relationships)

I do not want strong consistency as it will eventually cause contention.

Does App Engine always lock an entity group when updating or only when the update is being done in a transaction? In other words, do entity groups force updates to happen in transactions or simply provide the option to use transactions?

ThierryMichel
  • 487
  • 1
  • 5
  • 20

1 Answers1

3

About your 1st reason for choosing an ancestry-based approach - I don't think I ever saw any kind of promise with respect to the physical location in the datastore - I imagine any such constraint would collide with its high scalability. I wouldn't worry about it, IMHO the gain of such efficiency optimisation, if any, would be negligible.

You should be aware that contention isn't directly related to (strong) consistency (consistency really boils down to just the accuracy of query results).

Contention is however directly related to accessing the same entity group simultaneously, even for read operations, not only for write - see Contention problems in Google App Engine. Using ancestry is only making it worse as all entities in an ancestry tree are in the same entity group.

For your 2nd reason (if I understand your goal correctly) you don't need to store Answer keys into your Question entity or use ancestry. If you store the Question key (or key ID) into the Answer entity you can obtain the answers to a question by making regular (non-ancestor) queries for Answer entities with the matching question key/ID.

The entity group "locking" is only visible in transactions (and no, transactions aren't enforced, but think twice before attempting to write outside transactions - unintended overwrites will occur). But note that such locking is only effective as protection against conflicting write ops, but not against contention.

Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97
  • 1
    Thank you @Dan Cornislescu, this is really helpful. However, I may be misreading this but this article does mention that entity groups are stored together. See Ancestor Query and Entity Group -> Locality: https://cloud.google.com/datastore/docs/articles/balancing-strong-and-eventual-consistency-with-google-cloud-datastore/#ancestor-query-and-entity-group. Please let me know what you think. – ThierryMichel Feb 04 '20 at 00:06
  • Yup, now I know such promise exist. I must have missed it as I went through that article several times. Or it's a new addition to it? OK, maybe the performance gain might not be as negligible as I thought. Other than that I don't think it changes the rest of my answer. – Dan Cornilescu Feb 04 '20 at 04:56
  • Thank you @Dan Cornislescu and i agree it does not change the rest of the answer. – ThierryMichel Feb 05 '20 at 00:09