Thanks for the follow-up. I guess one could still use the "geotoken" (my own term) idea, but only save one token (map-graph-square) per saved point. Then, when someone searches on a given point, tokenize the search point, search for anything that shares the same token, and then go back for for data in the surrounding tokens. In my example, that means 9 DB calls instead of one, but that's pretty manageable... I don't know how it scales if you want to have greater variability in your search range, but you could either define your tokens to cover more ground, or increase the number of tokens searched.
Looking at the current quota limits, with 2.5 million datastore requests per day, I could handle 200,000 searches per day (250,000 * 9 = 2.45 million), which leaves room for 50,000 posts per day (one datastore operation per post), all under quota. Once this turns into a paid service, if I have to pay for more than that, I think I'll be happy to do so. -B On Sep 9, 2:52 pm, uprise78 <[EMAIL PROTECTED]> wrote: > The exploding index issue can occur with list properties readily. > > "Properties with multiple values, such as using a list value or a > ListProperty model, store each value as a separate entry in an index." > > With a 9 element list you just created 9 indexes. If you expand the > box to get some more resolution such as the 13 box example, you will > then have 13 indexes on that property alone. You can see where this > is going. It gets compounded if you even 1 single other list element > in your model. If you had another list element with just 2 records > you would have a total of 20 indexes (18 for the 2 lists and then 2 > for the basic indexing). > > This causes a number of issues. The two you pointed out, updating and > data storage. Updating has to hit each and every index so updates > would be a huge bottleneck if the model is updated often. The other > issue is (and correct me if I'm wrong on this anyone with more > experience) is that because lists are stored as separate entities Big > Table has to do multiple queries to return your result set. > > A bit of testing would probably be a good idea to see what the speed > is. If you have a small dataset, you definitely won't have an issue. > > Check out this: > http://code.google.com/appengine/docs/datastore/queriesandindexes.htm... --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
