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

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个实体，而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

Answer 1

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

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

我可以想到使用单独属性的唯一原因是，如果您知道您只需要对某些细节级别进行索引 - 但是在插入时可以通过指定要添加到列表中的详细信息级别来更好地完成。第一名。

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

Answer 2

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

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

因此，如果您要提供较低级别的api，它可以与bill katz的全文搜索实现一起使用

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-255] [0-255]给出具有5个指数的1G低水平细胞，其大小为log2递减。
• [0-2] [0-255] [0-255] [0-255]给出具有5个指数的16G低水平细胞。