Organizing groups of people in the Google App Engine for writing

I am a little confused about the "Entity Groups" in the Google App Engine (HRD) high-level replication data warehouse. The Google documentation mentions that HRD only allows 1 entry per second per entity group.

What exactly does this mean? Whether it is 1 record per user request or 1 record per entity (which I assume is a similar concept for a โ€œtableโ€).

For example, if I have a User object and a Mail table. If Mail is the ancestor of User:

  • Does this mean that one "User" can create one "Post" per second
  • ... or does this mean that all records in the Mail object are limited to 1 record per second, regardless of the user? (i.e. the system can save only one message at a time, regardless of the number of users sending messages).
  • ... or does it mean that one "user" object cannot create more than 1 "post" at the same time (even if thousands of other users are created by "Post" entities)?

What are my options for mitigating this? Is it reasonable to create both root User and Post objects? Can I create multiple instances of Post beyond the limit of 1 record per second? I want to avoid any potential problems if, say, 1000 users have to create "Post" posts at the same time.

+6
source share
2 answers

A "group of objects" is not like a "table." There is nothing that would mean a โ€œtableโ€ in the appengine data store. You should only think about objects and indexes.

You use groups of objects only if you want to perform transactions transactionally. In the case of a blog with Posts, it probably doesn't matter if you add or delete posts transactionally, so they donโ€™t need to be in an entity group.

In my application there are about 15 different types of objects and about 1.5 M of them. Each of them is a root entity, even related, and I think this is perfect for AppEngine. As far as I can tell, the only goal for groups of entities is to support atomic operations on several objects - they are not an organizational tool.

PS: as for your questions about the limitations of the Entity Group (which, in my opinion, will be mostly controversial for you now): the record limit for each object, not for the request. 1. Objects do not create other objects. 2. If all messages were in one group of entities, then yes, you could save only 1 second. 3. If each user was in his group of entities, you could write 1 message in each group at a time, how many times per second, as you liked. It is simply that no group can be written more than once per second. Yes, I think User and Mail should be both root objects.

+8
source

Using entity groups also allows you to make your data in a group very consistent.

For example, without groups of people, if you create a message and then quickly go to the last list of messages, you may not see your new entry immediately. For a blog, this may not be a problem.

But if you make a task management system ... you go to the task details screen, close the task, and this puts you back in the task list, the task can still be displayed as open. This is unacceptable. Here you will need entity groups or another value to make the task list consistent for the current user.

In some data models, it is easy to create entity groups. For example, completing tasks from a group of projects will solve the problem, assuming that you can only display tasks for one group. If your user interface allows you to list tasks from multiple groups, itโ€™s harder to find a model that works.

+1
source

Source: https://habr.com/ru/post/906422/


All Articles