Knowing about shards, I like them to be transparent when possible. Using defined entity groups everywhere I write data gives me control, but also seems to be an extra step in the model design that would have major implications if I wanted to change them. With the limited capabilities of GQL, reorganizing data appears to be a major chore with the datastore.
In the world of shared data, having a design of one entity group per user seems too limiting. I will try to design the entity groups around the sharing model (what is shared) and hopefully not the opposite (where technology drives the business decisions rather than the other way around). Thank you all for the good answers. On Oct 21, 1:37 pm, Jeff Schnitzer <[email protected]> wrote: > You have a mild conceptual misunderstanding - you are always using entity > groups whenever you use the datastore, both for M/S and HR. If you do > nothing special, every entity will go into its own entity group so you can > write to each one at 1/sec. But this involves tradeoffs WRT transactions > and eventual consistency. > > Another alternative is to put your entire database in a single entity group, > which gives you perfect consistency and transactionality but limits you to 1 > write per second. Obviously this is pretty preposterous, so in reality you > will need to create a balance of entity grouping. The rule of thumb of "one > user's data" is not a bad one, but it's not a hard and fast rule. > > Jeff > > > > > > > > On Fri, Oct 21, 2011 at 1:03 PM, Philip <[email protected]> wrote: > > So that's what seems odd to me. The HR datastore is best used with > > entity groups and yet there is such a huge limit on its throughput. > > > Since we can't rely on memcached values staying around (since they > > might be purged at any time), there seems to be no decent workaround > > for having immediately consistent reads (in case memcache is purged) > > without being limited to 1 write per second. > > > Do I have that write (pun intended)? > > > On Oct 21, 12:32 pm, Steve Sherrie <[email protected]> wrote: > > > This just refers to the entity group write limit that is the same in > > > both MS and HR datastores. > > > > On 11-10-21 03:30 PM, Philip wrote: > > > > > I am concerned about the statement: > > > > > "This allows queries on a single guestbook to be strongly consistent, > > > > but also limits changes to the guestbook to * 1 write per second * > > > > (the supported limit for entity groups)." > > > >http://code.google.com/appengine/docs/python/datastore/hr/overview.html > > . > > > > > Is it true that writes are limited to 1 per second when using the high > > > > replication datastore or is this an old limitation? > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > >http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
