如果我有一個帶有索引屬性的實體,說「名稱」,該屬性上==查詢的性能會是什麼樣子?GAE - 對索引屬性的查詢性能
當然,我知道沒有確切的答案是可能的,但是性能如何與某個x的name == x
的實體總數相關聯,數據存儲區中的實體總數等等。
如果我有1000個名稱等於x的實體,而不是100個實體,那麼對name == x
的查詢要慢多少?有沒有對此做過任何基準測試?
如果我有一個帶有索引屬性的實體,說「名稱」,該屬性上==查詢的性能會是什麼樣子?GAE - 對索引屬性的查詢性能
當然,我知道沒有確切的答案是可能的,但是性能如何與某個x的name == x
的實體總數相關聯,數據存儲區中的實體總數等等。
如果我有1000個名稱等於x的實體,而不是100個實體,那麼對name == x
的查詢要慢多少?有沒有對此做過任何基準測試?
AppEngine以非常優化的方式進行查詢,因此從性能角度看,無論您是對名稱屬性執行查詢,還是僅對鍵進行批量獲取,都無關緊要。要麼返回的實體數量是線性的。存儲在數據庫中的實體總數沒有什麼區別。不過,有一點細微差別的是數據庫中出現的「名稱」的不同值的數量(因此,返回的1000個實體幾乎比返回的100個實體慢10倍)。
這樣做的方式是通過與您的數據一起存儲的索引(或首選索引)。 「名稱」屬性的索引由一個表格組成,該表格按字母順序排列所有名稱(如果在任何查詢中使用降序排列,則第二個排序按字母順序排列),然後查詢將簡單地查找首先在表格中查詢您要查詢的名稱,然後按順序開始返回結果。這被稱爲「掃描」。
這視頻是有點技術,但它詳細解釋這一切是如何工作的,如果你很在意編碼以獲得最佳性能,可能是一個好時機投資:
Google I/O 2008: Under the Covers of the Google App Engine Datastore
(中視頻質量相當差,但他們也有在線幻燈片(請參閱上面的視頻鏈接))
我的一些不是很費力的測試表明響應時間與返回結果的數量大致成線性增加。請注意,即使您有1000個實體,但如果您爲查詢添加限制= 100,它的執行方式與您只有100個實體相同。
這與表明perf隨所返回實體數量變化的文檔一致。
當我說不是很費勁時,我的意思是響應時間到處都是,而且這是一個非常粗略的估計。我經常會在同一個請求中看到一個數量級的差異。