Thanks for the explanation, Nick! :) On Tue, Aug 10, 2010 at 5:26 PM, Nick Johnson (Google) < [email protected]> wrote:
> Hi Jaroslav, > > 2010/8/10 Jaroslav Záruba <[email protected]> > >> >> >> On Tue, Aug 10, 2010 at 2:24 PM, Jeff Schwartz >> <[email protected]>wrote: >> >>> Your English is fine. >>> >>> Key ids (longs and strings) must be unique within entity groups. When >>> your key has an id of type long you can either generate the value yourself >>> or have the datastore autogenerate it for you depending on how you define it >>> in your model or in the code that creates the entity. The docs cover this >>> when discussing keys and indexes. >>> >>> If you are generating a key that contains an autogenerated id, type long, >>> then the datastore generates the id when you put the entity. >>> >>> If you are creating your own ids either as a longs or strings then I >>> believe there is no datastore access required to generate a key but perhaps >>> someone from Google can confirm this. >> >> >> I think we're misunderstanding each other, I do understand how keys work. >> I'm curious about what exactly happens when I call allocateIds()... whether >> allocating audo-IDs is as expensive/cheap as delete, or whether it happens >> one step above Datastore (yet still way below my persistence framework >> ofcourse). Another question related to that would be "What happens when I >> allocate bazillion IDs and don't use them? Where and for how long are they >> stored?" >> > > ID allocations - especially for small numbers of IDs, such as 1 - are very > cheap. The servers that handle allocations request batches of IDs from the > datastore service, and issue them to clients on demand, requesting a new > batch whenever they run out, so most requests don't require doing anything > other than updating a little bit of state in the ID allocator. I would > expect an ID allocation to take a similar amount of time to, say, a memcache > increment operation. > > So the short answer is that yes, an allocate ID call plus a batch put > should be quicker than two individual puts - but by how much, I can't say > offhand. > > -Nick Johnson > > >> What world would it be without secrets... :P >> >> Cheers >> JZ >> >> >>> >>> Jeff >>> >>> 2010/8/10 Jaroslav Záruba <[email protected]> >>> >>>> Excuse my english please. >>>> >>>> I used delete as example because I assume it is the quickest >>>> data-operation. >>>> >>>> Not that following would change outcome of this thread but... >>>> >>>> ... I wonder whether IDs are generated by the same %something% in the >>>> Datastore that later writes the data. >>>> Or whether it might look like this: >>>> > my code >>>> > > Objectify/JDO >>>> ... >>>> ... >>>> > > > > > Datastore - ?ID generator? <- maybe this is where >>>> allocateIds() gets its response from >>>> > > > > > > Datastore - Writer <- CRUD go here >>>> >>>> I imagine there might be kind of 'memcache' above the Datastore >>>> itself... >>>> >>>> On Tue, Aug 10, 2010 at 1:05 PM, Jeff Schwartz <[email protected] >>>> > wrote: >>>> >>>>> I am not sure exactly what you mean when you say "allocation does not >>>>> go the whole way to the very Datastore." Batch puts return a list of keys >>>>> associated with the items that were saved to the datastore. Deletes are >>>>> quick because they are done by key and there is no serialization required >>>>> because nothing is returned. >>>>> >>>>> Jeff >>>>> >>>>> >>>>> >>>>> 2010/8/10 Jaroslav Záruba <[email protected]> >>>>> >>>>>> Thanks. :) >>>>>> And I assume the allocation does not go the whole way to the very >>>>>> Datastore...? I.e. it is faster than let's say delete operation, isn't >>>>>> it...? >>>>>> >>>>>> On Tue, Aug 10, 2010 at 11:54 AM, Jeff Schwartz < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Batch puts and gets are always faster as they are done in parallel. >>>>>>> >>>>>>> Jeff >>>>>>> >>>>>>> 2010/8/9 Jaroslav Záruba <[email protected]> >>>>>>> >>>>>>>> Thank you, keakon! >>>>>>>> >>>>>>>> On Tue, Aug 10, 2010 at 4:34 AM, 风笑雪 <[email protected]> wrote: >>>>>>>> >>>>>>>>> As I know, pre-allocate is nothing about performance, and use >>>>>>>>> single >>>>>>>>> put to save entities is faster than put each of them. >>>>>>>>> ---------- >>>>>>>>> keakon >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2010/8/10 Jaroslav Záruba <[email protected]>: >>>>>>>>> > Hello >>>>>>>>> > Could someone tell me which approach is 'cheaper', please? >>>>>>>>> > Let's have two entities... >>>>>>>>> > - persistedBasket // already persisted entity, holds item IDs >>>>>>>>> > - newItem // does not have ID yet >>>>>>>>> > Should I put(newItem), pass its ID to persistedBasket and then >>>>>>>>> > put(persistedBasket), or is it 'cheaper' to pre-allocate single >>>>>>>>> ID for >>>>>>>>> > newItem and then do put(persistedBasket, newItem)? >>>>>>>>> > In other words, does it make sense to pre-allocate single ID to >>>>>>>>> make single >>>>>>>>> > put(item1, item2) instead of two consecutive put's? >>>>>>>>> > Regards >>>>>>>>> > JZ >>>>>>>>> > >>>>>>>>> > -- >>>>>>>>> > 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]<google-appengine%[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]<google-appengine%[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]<google-appengine%[email protected]> >>>>>>>> . >>>>>>>> For more options, visit this group at >>>>>>>> http://groups.google.com/group/google-appengine?hl=en. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> Jeff >>>>>>> >>>>>>> -- >>>>>>> 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]<google-appengine%[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]<google-appengine%[email protected]> >>>>>> . >>>>>> For more options, visit this group at >>>>>> http://groups.google.com/group/google-appengine?hl=en. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> Jeff >>>>> >>>>> -- >>>>> 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]<google-appengine%[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]<google-appengine%[email protected]> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/google-appengine?hl=en. >>>> >>> >>> >>> >>> -- >>> -- >>> Jeff >>> >>> -- >>> 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]<google-appengine%[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]<google-appengine%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> > > > > -- > Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. > :: Registered in Dublin, Ireland, Registration Number: 368047 > Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: > 368047 > > -- > 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]<google-appengine%[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.
