In general, the 'appengine way' is *definitely* to create fewer, fatter
entities. Denormalization is the way of things. Because GAE is
schemaless, it's relatively easy to store an entire entity graph in a
single entity.

Also, the 'appengine way' is to precalculate aggregations rather than
computing them at runtime.

Your pre-calculated Nav tree is probably the solution I would use, caching
the entity in memcache for performance.

Jeff

On Wed, Feb 22, 2012 at 9:08 AM, adamd <adambones@xxxxxxxxx> wrote:

> Hi all
>
> I'm testing the waters with App Engine (Java) and wondered if anyone
> could help with my understanding of the "app engine way of doing
> things" with regards to queries and efficiency.
>
> Essentially my question is this: given that AE charges for each query
> made, and not for CPU usage, isn't it better to serialize and pack
> your data in to fewer, larger entities than to follow the standard
> data modeling approach of giving each business object it's own table
> row?
>
> Lets say I have a website with 100 pages. For each page served, I need
> to render a navigation tree of links requiring page names, their URLs,
> and their position in the tree. So say I request a level 3 page in the
> tree like "Page 1 > Page 1.2 > Page 1.2.3", I need all names and urls
> for all pages at levels 1,2 and 3.
>
> A conventional approach would be to have a Page table, with properties
> for "name" and "path" (containing the position of the page in the
> tree). When a page is requested, I then need to look it up, find out
> it's path, and then request all other pages that will be shown in the
> navigation according to that path.
>
> Translating this to app engine, I would need to run a query like
> "path" IN [level_1_path, level_2_path, level_3_path], which I have
> learned in reality boils down to a separate query for each tree level.
>
> (side note: I know that using AE's built in ancestor hierchary makes
> queries faster, but Entities can't be moved after being assigned a
> parent, and this is a feature i need. So I believe I need to manage by
> own tree the "path" property, which would look something like "1.2.3")
>
> So the conventional wisdom of building a single big query to do
> everything you want being the most efficient thing you can do doesn't
> seem to apply.
>
> Alternative approach: have a single "site" Entity with a property in
> which I would store a big HashMap containing all the essential page
> information. This can be serialized and compressed and stored as a
> String. Each request then only needs to load this one Entity for the
> purpose of building the nav.
>
> In the conventional setup, this wouldn't be as efficient because it
> would probably be faster to run the big query than to load and
> unserialize the hash map data for every request. But since I'm being
> billed for queries and not CPU usage on AE, is this not the better
> approach?
>
> Or can anyone suggest a better one?
>
> Many thanks for your time
>
> Adam
>
> --
> 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@xxxxxxxxxxxxxxxxx
> To unsubscribe from this group, send email to
> google-appengine+unsubscribe@xxxxxxxxxxxxxxxxx
> 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 google-appengine@xxxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to
google-appengine+unsubscribe@xxxxxxxxxxxxxxxxx
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.