Well.. seems like the only way to tell the costs is to build out a prototype to test.
The cost will mostly depend on how well you build this system.. (and not really on some theoretical lower limit on cpu cost). As Robert suggests, your indexes will probably need to be like the Relation Index that Brett Slatkin mentions in (he starts discussing that concept around 16 minutes in): http://www.youtube.com/watch?v=AgaL6NGpkB8 <http://www.youtube.com/watch?v=AgaL6NGpkB8>All the extra hard stuff like consistency and transactions.. well.. I can't imagine it being worth the effort to figure all of those hard problems out.. unless this is just a theoretical exercise. If this is for practical reasons, explain more particulars of the problem.. maybe there is a way around you needing to build your own custom indexes on top of GAE and then dealing with transactions and consistency across all of these custom indexes. (Granted, I can see one rolling their own full text search methods using custom indexing like this. But, in that case you could pretty much relax any transaction or consistency requirements.) On Tue, Oct 5, 2010 at 6:45 AM, rvjcallanan <[email protected]>wrote: > Hi all, > > I have an unusual data retrieval requirement which cannot be fulfilled by > the built-in indexing mechanism of the GAE (or any other Cloud platform for > that matter). This got me thinking about managing my own index tables and > just using barebones GAE indexing for retrieving individual entities from > the Datastore by key. The new Mapper API offers distinct possibilities. > > Yes, I realise that this almost sounds like an "App Engine" within an App > Engine but please humour me a little: > > Outside of framework integration issues, my main concerns are cost and > performance: > > 1. Will my indexing-related CPU cycles have a similar cost overhead to > using the GAE's built-in indexing? > 2. What about record retrieval (e.g. thousands of items), cursors, etc? > 3. How do I maintain index consistency, transaction control, etc. > > I suppose these questions can be distilled down to one: > > Sitting higher up the stack, is my code at a serious disadvantage compared > to the GAE internals when it comes to indexing control? > > ...and as an afterthought, might it be a good idea in general for > applications to have this level of control over their indexes? I'm thinking > of the many problems which frequently crop up with GAE indexes which are of > course part of a massive indexing super-structure encompassing all apps? > > TIA > > -- > 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.
