0

I'm thinking of porting an application from RoR to Python App Engine that is heavily geo search centric. I've been using one of the open source GeoModel (i.e. geohashing) libraries to allow the application to handle queries that answer questions like "what restaurants are near this point (lat/lng pair)" and things of that nature.
GeoModel uses a ListProperty which creates a heavy index which had me concerned about pricing as i have about 10 million entities that would need to be loaded into production.

This article that I found this morning seems pretty scary in terms of costs:

https://groups.google.com/forum/?fromgroups#!topic/google-appengine/-FqljlTruK4

So my question is - is geohashing a moot concept now that Google has released their full text search which has support for geo searching? It's not clear what's going on behind the scenes with this new API though and I'm concerned the index sizes might be just as big as if I used the GeoModel approach.

The other problem with the search API is that it appears I'd have to create not only my models in the datastore but then replicate some of that data (GeoPtProperty and entity_key for the model it represents at a minimum) into Documents which greatly increases my data set.

Any thoughts on this? At the moment I'm contemplating scraping this port as being too expensive although I've really enjoyed working in the App Engine environment so far and would love to get away from EC2 for some of my applications.

earthtrip
  • 498
  • 5
  • 18

1 Answers1

1

You're asking many questions here:

  • is geohashing a moot concept: Probably not, I suspect the Search API uses geohashing, or something similar for its location search.

  • can you use the Search API vs implementing it yourself: yes, but I don't know the cost one way or the other.

  • is geohashing expensive on app engine: in the message thread the cost is bad due to high index write costs. you'll have to engineer your geohashing data to minimize the indexing. If GeoModel puts a lot of indexed values in the list, you may be in trouble - I wouldn't use it directly without knowing how the indexing works. My guess is that if you reduce the location accuracy you can reduce the number of indexed entries, and that could save you a lot of cost.

  • As mentioned in the thread, you could have the geohashing run in CloudSQL.

dragonx
  • 14,963
  • 27
  • 44