The way I see it, if I want transactions (on a per-user basis), I will need some kind of root user entity as the parent of all entities that are part of the hierarchy of her data, no matter how thin this entity would actually be i.e. basically no properties.
I wouldn't just create a root user entity and throw everything in its entity group. Think about what you need transactions for. If you have no properties on your user entity, what would you be using it in transactions with?
I don't know about your data, but let's assume it's a blog system and you have users, posts and comments. The Post model holds a number_of_comments so you don't have to count them. You might want transactions to ensure when you create a comment, the number_of_comments property can be updated safely.
In this case, it would be an unnecessary overhead to have all of a users posts and comments in a single entity group. Instead, you can post the comments in the same entity group as the post they belong to. There would be no need to put the posts into the same group as a user, and in fact this would be a bad idea, since comments posted in any of a users post would all be contending to write the same entity group.
I wrote a short article about entity groups on my blog today. You might find it useful.
App Engine is a Platform-as-a-Service. It means that you simply deploy your code, and the platform does everything else for you. For example, if your app becomes very successful, App Engine will automatically create more instances to handle the increased volume.
Read more about App Engine
Compute Engine is an Infrastructure-as-a-Service. You have to create and configure your own virtual machine instances. It gives you more flexibility and generally costs much less than App Engine. The drawback is that you have to manage your app and virtual machines yourself.
Read more about Compute Engine
You can mix both App Engine and Compute Engine, if necessary. They both work well with the other parts of the Google Cloud Platform.
EDIT (May 2016):
One more important distinction: projects running on App Engine can scale down to zero instances if no requests are coming in. This is extremely useful at the development stage as you can go for weeks without going over the generous free quota of instance-hours. Flexible runtime (i.e. "managed VMs") require at least one instance to run constantly.
EDIT (April 2017):
Cloud Functions (currently in beta) is the next level up from App Engine in terms of abstraction - no instances! It allows developers to deploy bite-size pieces of code that execute in response to different events, which may include HTTP requests, changes in Cloud Storage, etc.
The biggest difference with App Engine is that functions are priced per 100 milliseconds, while App Engine's instances shut down only after 15 minutes of inactivity. Another advantage is that Cloud Functions execute immediately, while a call to App Engine may require a new instance - and cold-starting a new instance may take a few seconds or longer (depending on runtime and your code).
This makes Cloud Functions ideal for (a) rare calls - no need to keep an instance live just in case something happens, (b) rapidly changing loads where instances are often spinning and shutting down, and possibly more use cases.
Read more about Cloud Functions
Best Answer
When you're doing queries, you can use ancestor() to restrict the query to children of a particular entity - in your example, you could look for only descendants of
B
, which you couldn't do if they were all at the top level.There's more on Ancestor Queries in Programming Google App Engine
The Keys and Entity Groups doc also says that:
edit: The same document also lists some of the reasons why you don't want your entity groups to grow too large:
Any transaction on an entity in a Group will cause any other writes to the same entity group to fail. If you have a large entity group with lots of writes, this causes lots of contention, and your app then has to handle the expected write failures. Avoiding datastore contention goes into more detail on the strategies you can use to minimse the contention.