oops, maybe I've confused things then ... :)

I was referring to Dave's comment, "If you do a bunch of processing on
groups of
entities in a single request then you can put them in a entity group,
which should make that processing faster because they will be kept
close."

I took that to mean locality in the sense of "next to each other in
bigtable", and the API docs seem to suggest that won't have much of an
effect. Anyway, it seems a good guideline is to use the smallest
groups you can.

cheers
Michael

On Feb 11, 9:11 am, Michael Hart <michael.hart...@gmail.com> wrote:
> Hmm? I think Stu was asking about Dave's reference to locality,  
> assuming that it was for geographical purposes - I was just stating  
> that I think the reason locality was brought up was to highlight how  
> each entity group can actually be persisted on a separate machine,  
> thus speeding up read/write performance. Locality referring more to a  
> machine, not a location (as such).
>
> In any case, I think we're saying the same thing (as Dave originally  
> mentioned too) - smaller entity groups are going to be faster.
>
> On 11/02/2009, at 7:35 PM, mcobrien wrote:
>
>
>
> > I'm not sure how much locality helps, but putting entities in a group
> > for performance sounds like it could go wrong, depending on your data.
> > Writes to entities within a group are serialized so having too many
> > within in a single group can seriously hurt performance.
>
> > The API doc has some good hints:
> > * Only use entity groups when they are needed for transactions
> > * A good rule of thumb for entity groups is that they should be about
> > the size of a single user's worth of data or smaller
>
> > (fromhttp://code.google.com/appengine/docs/python/datastore/keysandentityg...)
>
> > I think the scalable apps talk has some detail on this as well (and
> > it's definitely worth watching anyway):
> >http://sites.google.com/site/io/building-scalable-web-applications-wi...
>
> > cheers
> > Michael
>
> > On Feb 10, 11:26 pm, Michael Hart <michael.hart...@gmail.com> wrote:
> >> Not quite right - I think the "faster" property refers to the fact
> >> that reads/writes can happen in parallel (because they're split over
> >> multiple machines), not because of the actual geographical location  
> >> of
> >> the servers (not that this wouldn't help as well, but I don't believe
> >> GAE currently has support for specifying geographical data location)
>
> >> I could be wrong though.
>
> >> On 11/02/2009, at 1:43 AM, Big Stu wrote:
>
> >>>> It also benefits from locality. Entity groups are stored close
> >>>> together (needed to make transactions fast), which is why lots of
> >>>> small entity groups makes the overall application faster (because
> >>>> they
> >>>> can be spread out). If you do a bunch of processing on groups of
> >>>> entities in a single request then you can put them in a entity  
> >>>> group,
> >>>> which should make that processing faster because they will be kept
> >>>> close.
>
> >>>> Dave.
>
> >>> I don't quite have my head wrapped around the entity group thing
> >>> either.  The transaction part I get...other benefits I don't quite  
> >>> get
> >>> yet.  If I were to build an app for managing dollar store  
> >>> inventory or
> >>> something like that would I want to make all the data related to a
> >>> particular store part of the same entity group?  So that the data  
> >>> for
> >>> a store in Toronto is part of one group, and the data for  
> >>> Vancouver is
> >>> part of another, and then as far as teh datastore and access times  
> >>> are
> >>> concerned the storage of the datasets will be best suited to the
> >>> geography of the situation?  Am I getting this right?
>
> >>> Thanks.
>
> >>> Stu
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to