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低水平細胞。