python - 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 个索引有 13n 个实体，前者在存储方面是否比后者差得多？

似乎 (1) 的答案是否定的，根据 this article ，但我只是想看看是否有人有过不同的经历。

现在，我正在考虑调整 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_ 个实体的搜索空间。

根据 this blog post 中的技巧 #6，似乎 (2) 的答案是两者的查询性能相同，但同样，我想看看是否有人对此有任何不同的现实体验。

最后，如果有人有任何其他建议或技巧可以帮助提高存储利用率、查询性能和/或易用性(特别是 w.r.t. index.yaml)，请告诉我!来源可以在这里找到 geomodel & geomodel.py

Answer 1

您是正确的，每个索引没有显着的开销 - 一个索引中的 13n 个条目或多或少相当于 13 个索引中的 n 个条目。不过，总索引数限制为 100，因此这会占用相当一部分可用索引。

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

我能想到的使用单独属性的唯一原因是，如果你知道你只需要在特定的细节层次上建立索引——但在插入时通过指定你想添加到的细节层次可以更好地完成列在第一位。

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