鍵或單獨模型的列表？

我正在構建一個包含用戶及其活動的應用程序。現在我正在考慮設置數據存儲模型的最佳方式。哪一個是最快/首選的，爲什麼？鍵或單獨模型的列表？

甲

class User(db.Model): 
    activities = db.ListProperty(db.Key) 
    ... 
class Activity(db.Model): 
    ... 

activities = db.get(user.activities)

或

乙

class User(db.Model): 
    ... 
class Activity(db.Model): 
    owner = db.ReferenceProperty(reference_class=User) 
    ... 

activities = Activity.filter('owner =', user)

來源

2012-03-27 pthulin

儘管答案很好，但值得注意的是，您並未真正提供足夠的信息。關於哪個解決方案更好的問題是如何使用數據。你會做什麼樣的查詢？每個用戶會有多少活動？等等。 – 2012-03-28 13:38:41

新的活動將在用戶互動時創建，例如遵循彼此或推薦的東西。在這種情況下，將爲用戶提交活動存儲傳出活動，如果存在任何活動，則會存儲用於接收用戶的存儲活動。用戶活動將在訪問該用戶個人資料頁面或該用戶登錄時提取。 – pthulin 2012-03-28 17:31:29

如果一個給定活動可以只具有單個所有者，絕對使用ReferenceProperty。

這是什麼ReferenceProperty s的專爲
它會自動爲你設置反向引用，它可以很方便，因爲它爲您提供了一個雙向鏈路（不像ListProperty這是一個單向定向鏈接）
它強制被連接的東西是正確的類型/類
它強制執行，只有單個用戶鏈接到某一活動
它可以讓你自動獲取鏈接的對象，而不必寫一個明確的查詢，如果你這麼願意

來源

2012-03-27 21:32:00 Amber

即使我不必從活動中查找所有者？ – pthulin 2012-03-27 21:35:26

是的，即使你沒有。查看所有其他要點。（也就是說，我認爲你可能會發現你希望能夠在某個時候從某個活動中查看所有者的道路 - 最好是有能力可用。） – Amber 2012-03-27 21:35:45

我猜測這種差異將會很小，並且很可能取決於你的應用程序，而不是基於你的模型的讀寫時間的一些具體差異。

如果您打算使用用戶每次獲取用戶所完成的每項活動的信息，那麼可以使用第一個選項。換句話說，如果用戶在應用程序中做的幾乎所有事情都與他們活動的一大部分相符，那麼總是有可用的活動是有意義的。

如果您不需要所有的活動，請使用選項B.每當需要使用該活動時，這將導致對數據存儲的單獨請求，但也會使請求更小。提出額外請求可能會增加更多開銷而不是提出更大的請求。

所有這些被說，如果你有這兩種方法之間的顯着差異，我會感到驚訝。您將要獲得更明顯的性能改進的領域是使用memcache。

來源

2012-03-27 21:38:48 Dave

我不知道性能差異，我懷疑它會是類似的。當涉及到perf時，GAE數據存儲很難控制。如果所有的查詢碰巧碰到相同的平板電腦（bigtable服務器），那可能會比查詢本身限制你的性能。

最大的區別是A會比B便宜。既然你有一個你想要的活動列表，你不需要爲你寫的每個活動對象編寫一個索引。如果活動寫得很多，你的儲蓄就會加起來。

既然你有活性的關鍵，你也必須做一個高度一致的get（），而不是最終一致性過濾器（）

在另一面的能力，你將不能夠做到向後引用，如查看給定活動的所有者。您的ListProperty也可能導致您達到您的最大實體大小 - 最終會限制每個用戶的活動數量。如果你和B一起去，你可以爲每個用戶開展大量的活動。

編輯：我忘了，你可以有向後引用，如果你索引你的ListProperty，但那樣，寫你的用戶對象會變得昂貴，並且索引屬性數量的限制會限制你的大小名單。所以即使有可能，如果你需要向後引用，B仍然是可取的。

來源

2012-03-27 22:59:37 dragonx

A會更快，因爲它純粹使用鍵。用鍵查找對象直接進入BigTable中的數據節點，而B需要首先查找索引，速度較慢（並且成本將隨活動實體的數量而增加）。

如果您永遠不需要測試所有權，您可以修改A以不索引密鑰列表。這絕對是最便宜和最有效的路線。不過，據我瞭解，如果您以後需要爲它們編制索引，則應用程序引擎不能追溯更新密鑰列表中的索引。所以如果你確定你永遠不需要它，只需禁用索引。

來源

2012-03-28 03:37:17 Dustin

C：如何將Activity的父級設置爲用戶密鑰？這樣你就可以使用Activity.query（ancestor = user.key）獲取用戶的活動。

這樣你就不需要額外的鍵/屬性+將HR實體數據存儲的實體分組的好方法。

來源

2012-03-28 10:29:27 alex

鍵或單獨模型的列表？

回答

相關問題