我正在考虑将应用程序从RoR移植到以地理搜索为中心的Python App Engine。我一直在使用开源GeoModel（即geohashing）库中的一个，以允许应用程序处理回答诸如“这附近的餐馆（lat / lng对）”等问题的查询以及那种性质的事情。
GeoModel使用ListProperty创建了一个重型索引，让我关注定价，因为我有大约1000万个需要加载到生产中的实体。
我今天早上发现的这篇文章在成本方面看起来非常可怕：
https://groups.google.com/forum/?fromgroups#!topic/google-appengine/-FqljlTruK4
所以我的问题是 - 现在谷歌已经发布了支持地理搜索的全文搜索，这是一个没有实际意义的概念吗？目前还不清楚这个新API背后会发生什么，我担心索引大小可能与我使用GeoModel方法一样大。
搜索API的另一个问题是，似乎我不仅需要在数据存储区中创建我的模型，而且还要将其中的一些数据（GeoPtProperty和至少它所代表的模型的entity_key）复制到Documents中。大大增加了我的数据集。
对此有何想法？目前我正在考虑把这个端口刮得太贵，虽然到目前为止我真的很喜欢在App Engine环境中工作，并且很想从我的某些应用程序中脱离EC2。
答案 0 :(得分：1)
你在这里问了很多问题：
正在设计一个没有实际意义的概念：可能不是，我怀疑Search API使用geohashing或其类似的位置搜索。
您可以使用搜索API与自己实施：是的，但我不知道这种或那种费用。
在app引擎上的地理位置非常昂贵：在消息线程中，由于高索引写入成本，成本很差。您必须设计地理数据以最小化索引。如果GeoModel在列表中放入了很多索引值，那么您可能会遇到麻烦 - 我不会直接使用它而不知道索引的工作原理。我的猜测是，如果降低位置精度，可以减少索引条目的数量，这可以为您节省大量成本。
如线程中所述，您可以在CloudSQL中运行geohashing。