Thanks for the reply Kevin

99% of the time i would query for a list of child object using the
parent id, and a range of the timestamp field.

our child objects have these values

@Persistent
private Date timestamp;

@Persistent
private String parentFK;


so a query like this

Query q = pm.newQuery(ChildObject.class,"parentFK == k && timestamp >=
sd && timestamp <= ed");
q.declareImports("import java.util.Date");
Map args = new HashMap();
args.put("k", "theparentkeystring");
args.put("sd", startDate);
args.put("ed", endDate);
q.declareParameters("Long k, Date sd, Date ed");
q.setOrdering("timestamp descending");
List<ChildObject> data = (List<ChildObject>) q.executeWithMap(args);

Now, imagine each of my users with several 100 parent objects each
with many tens of thousands of daily child objects they will be
retrieving subsets of throughout their usage. I have solved
performance problems in the past when I used SQL Server for this by
moving older and less used child objects out of the main tables and
combining their data into flat files for archiving. I'm hoping i can
just leave everything in the data store this time around and store/
retrieve things correctly.




On Oct 13, 5:16 pm, Kevin Pierce <kpie...@vendasta.com> wrote:
> Some ideas,
>
> You may need to avoid using an entity group with that many records if you
> are concerned about contention.
>
> I would suggest generating key_names from your logical primary_key fields.
>
> Also understand how you could leverage a list property style model for
> filtering.
>
> Your children can have the composite key as the key_name allowing you to
> perform keys_only queries that you can pop out the parent key_name from.
>
> What types of queries do you want to perform on your child entities?
>
>
>
>
>
> On Tue, Oct 13, 2009 at 1:54 PM, Benjamin <bsaut...@gmail.com> wrote:
>
> > anyone have a recomendation on the best way to store millions of child
> > objects in data nuclues and maintain their relationship to a single
> > persistant parent?
>
> > On Oct 8, 10:21 am, Benjamin <bsaut...@gmail.com> wrote:
> > > sorry for the dup post
>
> > > I'm trying to find guidence on managing one to many releationships in
> > > the data store when the number of children the parent will have will
> > > be huge - 32000 children added to a parent a day
>
> > > a simple parent class:
>
> > > @PersistenceCapable(identityType = IdentityType.APPLICATION,
> > > detachable = "false")
> > > public class Parent  {
>
> > > �...@persistent(mappedBy = "parent")
> > > private  ArrayList<Child> points;
>
> > > a simple child class
>
> > > public class Child  {
> > > @Persistent
> > >  private Parent parent;
>
> > > and the parent arraylist is getting many children added to it and the
> > > datastore updated. I'm afraid that whenever i query for the parent
> > > object i'm going to get all of the children which i would never need
> > > to do - i would want to get parts of the children collection and i do
> > > want to maintain the relationship so parent deletes are cascaded.
>
> > > How do you query the datastore and get a parent without the children -
> > > it looks like the child collection gets populated by default when you
> > > just do a query like this:
>
> > >         Query q = pm.newQuery(Parent.class, "key== k");
> > >                 k.declareParameters("Long u");
> > >         List<Parent> result;
> > >         result = (List<Parent>) q.execute(key);
>
> > > with a huge number of children, wouldn't this query be very slow?
>
> --
> Kevin Pierce
> Software Architect
> VendAsta Technologies Inc.
> kpie...@vendasta.com- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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