Hi Didier, Thanks for the reply.
Interesting answer, I don't know the intrinsics of the datastore, but commons sense at least suggests that with a batch put you save the individual round trips. Plus you save latency when responding to users, you just enqueue the operation and return. Regarding contention - in my case the "news items" belong to different entity groups, so contention should not increase. But you're right on that one... in case of entity group contention, it would be a problem. By the way what is your source - google blog, video, book? This would be very useful info, I have only found very scarce information regarding that topic. Thanks, Ivan On Jan 20, 6:39 pm, Didier Durand <durand.did...@gmail.com> wrote: > Hi, > > I don't see how you will save: puts are unitary actions -> they can > not be optimized like queries for big sets of data. By using a task, > you will add the cost of saving / starting / running a task to the > cost of your put operation that you will do anyway. > > In addition, you may even generate more contentions on the datastore > servers if your puts go all to the same server. So, more cpus, > additional contention exceptions to handle, etc... > > Really, if you puts are spread, I would try to let them so. > > Spread writes are usually simpler to handle than concentrated ones. > > Did I miss something ? > > regards > didier > > On Jan 20, 12:18 pm, Ivan <ivdelc...@gmail.com> wrote: > > > Hi guys, > > > What is the best way to batch time-non-critical datastore operations? > > The use case is the following: > > > In my app users can perform certain actions, which result in news > > items being generated: 0 - 4 per action, depending on the action. > > Currently I put them immediately to the datastore in a batch put. What > > would be much more optimal is to somehow batch them in groups > > (although they were created in totally different contexts, probably > > gae instances as well) and persist them as soon as group size > X or > > time elapsed since group was created > Y mins. My impression is that > > task queues are a good candidate but at the moment they rather serve > > to split a big task into smaller ones rather than vice versa. Any > > suggestions on how to optimize the above problem? > > > Cheers, > > Ivan -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
