Question

首先有一些背景知识：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个实体，而其中包含13个实体的1个索引，那么前者在存储方面要比后者差得多吗？

根据this article，似乎（1）的答案是否定的，但我只想知道是否有人有过不同的经历。

现在，我正在考虑调整GeoModel库，使得只有一个名为location_geocells的StringListPropert，而不是13个字符串属性，即：

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）的答案是，this blog post中的每个提示＃6都会产生相同的查询性能，但同样，我想看看是否有人有任何不同的实际经验有这个。

最后，如果有人有任何其他建议或提示可以帮助提高存储利用率，查询性能和/或易用性（特别是w.r.t. index.yaml），请告诉我们！可在此处找到来源geomodel＆amp; geomodel.py

Answer 1

你是正确的，每个索引没有明显的开销 - 一个索引中的13n个条目或多或少等同于13个索引中的n个条目。但是，总索引计数限制为100，因此这会占用可用索引的大部分。

也就是说，从可用性和索引消费的角度来看，使用ListProperty绝对是一种非常优越的方法。正如您所说，查询小索引和更大索引之间没有性能差异，假设两个查询都返回相同数量的行。

我可以考虑使用单独属性的唯一原因是，如果您知道您只需要对某些细节级别进行索引 - 但是在插入时可以通过指定要添加到其中的详细级别来更好地实现这一点。首先列出。

请注意，在任何一种情况下，如果您打算结合排序顺序或不等式过滤器查询地理单元属性，则只需要索引，但在所有其他情况下，自动索引就足够了。

Answer 2

最后，如果有人有任何其他建议或提示可以帮助提高存储利用率，查询性能和/或易用性

StringListproperty是出于上述原因的方法，但在实际使用中，人们可能希望将geocell添加到自己以前存在的StringList中，以便可以查询多个属性。

因此，如果您要提供较低级别的API，则可以使用bill katz's等全文搜索实现

def point2StringList(Point, stub="blah"):
    .....
    return ["blah_1:a", "blah_2":"a3", "blah_3":"a3f" ....]

def boundingbox2Wheresnippet(Box, stringlist="words", stub="blah"):
    .....
    return "words='%s_3:a3f' AND words='%s_3:b4g' ..." %(stub)

etc.

Answer 3

看起来你最终得到了13个索引，因为你用十六进制编码（人类可读性/地图级别？）。如果你已经利用了一个字节的全部潜力（ByteString），那么每个字符（字节）就有256个单元而不是16个单元。通过减少相同精度的索引数量减少到更少。

ByteString只是str的子类，如果长度小于500字节，则会被类似地索引。

然而，数量级别可能更低;对我来说，4或5级对于“地球”上的大多数情况来说实际上已经足够好了。对于较大的行星或对每个砂粒进行编目时，无论使用何种编码，都可能需要引入更多的划分。在任何一种情况下，ByteString都优于十六进制编码。并有助于减少索引基本。

为了代表40亿个低（est）级单元，我们需要的只是4个字节或只是 4个索引。（从基本的计算机拱或内存寻址）。
为了表示相同，我们需要 16 十六进制数字或 16个索引。

我可能是错的。可能是匹配地图缩放级别的索引级别数量更为重要。请指正。如果只有一个（其他）人在这里发现这个有意义的话，我打算尝试这个而不是十六进制：）

或者，当我们沿着层次结构向下时，具有较少大单元（16）但更多（128,256）的解决方案。有什么想法吗？

例如：

[0-15] [0-31] [0-63] [0-127] [0-255]给出1G低级别单元格，其中5个索引的大小为log2递减。
[0-15] [0-63] [0-255] [0-255] [0-255]给出具有5个指数的16G低水平细胞。

App Engine：13 StringPropertys vs. 1 StringListProperty（w.r.t。索引/存储和查询性能）

3 个答案: