0

我正在考虑将应用程序从 RoR 移植到以地理搜索为中心的 Python App Engine。我一直在使用其中一个开源 GeoModel（即 geohashing）库，以允许应用程序处理诸如“附近有哪些餐馆（纬度/经度对）”之类的问题的查询以及类似的事情。
GeoModel 使用 ListProperty 创建了一个沉重的索引，这让我担心定价，因为我有大约 1000 万个实体需要加载到生产环境中。

我今天早上发现的这篇文章在成本方面似乎相当可怕：

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

所以我的问题是——既然谷歌已经发布了支持地理搜索的全文搜索，地理散列是一个没有实际意义的概念吗？不过，目前尚不清楚这个新 API 的幕后发生了什么，而且我担心索引大小可能与我使用 GeoModel 方法一样大。

搜索 API 的另一个问题是，看来我不仅必须在数据存储中创建我的模型，而且还要将其中一些数据（它所代表的模型的 GeoPtProperty 和 entity_key）复制到 Documents 中，这大大增加了我的数据集。

对此有什么想法吗？目前我正在考虑刮掉这个端口太昂贵了，尽管到目前为止我真的很喜欢在 App Engine 环境中工作并且很想在我的一些应用程序中摆脱 EC2。

4

1 回答 1

1

你在这里问了很多问题：

  • 地理散列是一个没有实际意义的概念：可能不是，我怀疑搜索 API 使用地理散列或类似的东西来进行位置搜索。

  • 您可以使用搜索 API 还是自己实现它：是的，但我不知道哪种方式的成本。

  • 应用引擎上的地理散列很昂贵：在消息线程中，由于索引写入成本高，成本很差。您必须设计您的地理哈希数据以最小化索引。如果 GeoModel 在列表中放置了很多索引值，您可能会遇到麻烦 - 在不知道索引如何工作的情况下，我不会直接使用它。我的猜测是，如果您降低定位精度，您可以减少索引条目的数量，这可以为您节省大量成本。

  • 如线程中所述，您可以在 CloudSQL 中运行 geohashing。

于 2012-07-16T16:28:15.807 回答