Rom*_*rik 3 python google-app-engine google-cloud-datastore
首先介绍一下背景:GeoModel是我编写的一个库,它为App Engine应用程序添加了非常基本的地理空间索引和查询功能.它与geohashing的方法类似.GeoModel中的等效位置哈希称为"geocell".
目前,GeoModel库为每个位置感知实体添加了13个属性(location_geocell__n_,n = 1..13).例如,实体可以具有属性值,例如:
location_geocell_1 = 'a'
location_geocell_2 = 'a3'
location_geocell_3 = 'a3f'
...
这是在空间查询期间不使用不等式过滤器所必需的.
13属性方法的问题在于,对于任何想要运行的地理查询,必须定义和构建13个新索引.这绝对是一个维护麻烦,因为我在为项目重写演示应用程序时痛苦地意识到了这一点.这导致了我的第一个问题:
问题1:每个索引是否有任何重要的存储开销？也就是说,如果我有13个索引,每个索引中有n个实体,而1个索引中有13个实体,那么前者在存储方面要比后者差得多吗？
根据这篇文章,似乎(1)的答案是否定的,但我只想看看是否有人有过不同的经历.
现在,我正在考虑调整GeoModel库,以便代替13个字符串属性,只有一个名为location_geocells的StringListProperty,即:
location_geocells = ['a', 'a3', 'a3f']
这导致更清洁index.yaml.但是,我确实质疑性能影响:
问题2:如果我从13个字符串属性切换到1个StringListProperty,查询性能会受到不利影响; 我当前的过滤器看起来像:
query.filter('location_geocell_%d =' % len(search_cell), search_cell)
并且新的过滤器看起来像:
query.filter('location_geocells =', search_cell)
请注意,第一个查询的搜索空间为_n_个实体,而第二个查询的搜索空间为_13n_个实体.
似乎(2)的答案是,在这篇博客文章中,每个提示#6都会产生相同的查询性能,但同样,我想看看是否有人对此有任何不同的实际经验.
最后,如果有人有任何其他建议或提示可以帮助提高存储利用率,查询性能和/或易用性(特别是wrt index.yaml),请告诉我!源代码可以在这里找到geomodel&geomodel.py
你是正确的,每个索引没有明显的开销 - 一个索引中的13n个条目或多或少等于13个索引中的n个条目.但是,总索引计数限制为100,因此这会占用可用索引的一大部分.
也就是说,从可用性和索引消费的角度来看,使用ListProperty绝对是一种非常优越的方法.正如您所说,查询小索引和更大索引之间没有性能差异,假设两个查询返回相同数量的行.
我可以想到使用单独属性的唯一原因是,如果您知道您只需要对某些细节级别进行索引 - 但是在插入时可以通过指定要添加到列表中的详细信息级别来更好地完成.第一名.
请注意,在任何一种情况下,如果您打算结合排序顺序或不等式过滤器查询地理单元属性,则只需要索引,但在所有其他情况下,自动索引就足够了.