App Engine：13 StringPropertys與1 StringListProperty（w.r.t.索引/存儲和查詢性能）

Question

有點背景優先：GeoModel是我寫的一個庫，它爲App Engine應用程序增加了非常基本的地理空間索引和查詢功能。它與地理散亂相似。 GeoModel中的等效位置散列稱爲「地理單元」。

目前，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，但我只想看看是否有人有不同的經歷。

現在，我正在考慮調整地質模型庫，這樣，而不是13點的屬性，有好多隻能是一個StringListProperty叫location_geocells，即：

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 this blog post，但同樣，我想看看如果任何人有任何與此不同的現實世界的經驗。

最後，如果有人有任何其他建議或提示可以幫助提高存儲利用率，查詢性能和/或易用性（特別是w.r.t. index.yaml），請告訴我！ 13N條目在一個索引或多或少相當於N個項目在13個指標 - 源可以在這裏geomodel & geomodel.py

Answer 1

你是正確的，有沒有顯著的開銷每個索引中找到。儘管如此，總索引數量限制爲100，因此這會佔用大量可用索引。

也就是說，使用ListProperty絕對是一個遠遠優於可用性和索引消費觀點的方法。假設兩個查詢都返回相同的行數，如您所想的那樣，查詢小索引和更大的索引之間沒有性能差異。

我可以考慮使用單獨屬性的唯一原因是，如果您知道只需要在特定級別的細節上進行索引 - 但是可以在插入時通過指定要添加的細節級別該列表在第一位。

請注意，在任何情況下，只需要索引（如果您打算查詢與排序順序或不等過濾器相關的地理單元屬性），但在所有其他情況下，自動索引就足夠了。

Answer 2

最後，如果任何人有任何其他建議或提示，可以幫助提高存儲利用率，查詢性能和/或易用性

的StringListproperty是去的方式上面提到的原因，但在實際使用中，人們可能想要將地理單元添加到自己以前存在的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都比十六進制編碼要好。並幫助減少索引大幅。

• 對於代表4十億低（EST）水平的細胞，我們需要的是4個字節，或只是4指數。 （從基本的計算機拱形或內存尋址）。
• 對於相同的表示，我們需要十六進制數字或16個索引。

我可能是錯的。可能是匹配地圖縮放級別的索引級別數量更重要。請糾正我。如果在這裏只有一個（其他）人發現這個有意義的話，我打算試試這個而不是十六進制：

或者當我們沿着層次結構走下去的時候，一個解決方案只有更少的大單元（16）但更多（128,256）。 有什麼想法？

例如：

• [0-15] [0-31] [0-63] [0-127] [0-255]給出1G低電平細胞與5個索引與大小的log 2減量。
• [0-15] [0-63] [0-255] [0-255] [0-255]給出16個具有5個索引的低電平單元。