GAE數據存儲緩存鍵VS過濾

比方說你有一個實體是這樣的。GAE數據存儲緩存鍵VS過濾

postid=db.StringProperty() 
comment=db.StringProperty()

用於存儲對由帖子ID標識的某個帖子的評論。評論可以打到數十億條記錄。現在，如果你想獲得屬於某個職位，你可以做所有的意見，

query=Comment.all() 
query.filter('postid = ','id').

還是不要做，你可以這樣定義

class Post(db.Model) 
    commentids=db.StringListProperty()#store list of comment ids

這樣你就可以直接將意見後通過做

comment=Comment.get_by_key_name('commentkey')

從長期來看（在評論擊中千萬甚至上億馬克），這一個更有效。換句話說哪一個更合適。

來源

2012-09-07 specialscope

如果你打算擁有數十億的評論還可以考慮使用最新NDB API，其中，除其他事項外，支持自動緩存。

而不是通過postid篩選它們，你可能應該爲你的Comment實體使用父項。下面是一個例子（使用DB，但使用NDB這是非常相似）：

如果你有模型像這樣的：

class Post(db.Model): 
    desc = db.StringProperty() 

class Comment(db.Model): 
    desc = db.TextProperty()

您可以創建文章和評論，如：

post_db = Post(desc='Hello World') 
post_db.put() 

comment_db = Comment(parent=post_db, desc='Nice post') 
comment_db.put()

最後如果你想獲得某個post_db實體的所有評論：

comment_dbs = Comment.all().ancestor(post_db)

來源

2012-09-07 17:47:05 Lipis

通過這樣做，雖然，在HR數據存儲你限制自己的每秒每實體組約1-2寫。如果你希望評論每篇文章的頻率很高，那麼你將有減輕（嘗試使用拉隊列或推式隊列，執行速率爲2/s）或顯式捕獲爭用異常並在稍後重試該帖子。 – someone1

當您需要交易時，將使用實體組，而不是作爲父子關係。 –

@PeterKnego我認爲有，即使你不需要交易，你可以使用祖先其他例子。例如，如果您有用戶和設置實體，則可以使用相同的'key_name'進行不同類型的設置以獲得以下優點：'設置。get_or_insert（background_color，parent = user_db，value ='＃ff0000'）'沒有在key_name中包含難看和唯一的東西:) – Lipis

個實體的大小限制爲1MB。此外，實體可以有最多5000個索引條目，所以如果你commentids被索引，則最大規模爲5000個條目。

因此，方案二將不會是一個不錯的選擇以百萬計的意見（我從來沒有見過的每個帖子一百萬的網站，但沒有書籤交易渡過5K的熱門職位。

而且，你倒是可能需要一種方法來列出一個漸進的方式（pagging，進行滾動）的意見。在這種情況下，選擇一個通過查詢會更好，因爲你可以通過遊標progressivelly列出的意見和（你也可以排序通過不同的標準特性的時候，票等。）。

來源

2012-09-07 21:53:20

謝謝，我的問題不是每個帖子的評論數量。當您從Comment.all（）進行過濾時，我擔心的是執行速度，當Comment下的實體數量達到大數時。我非常瞭解5k的限制，我不認爲我會在單個帖子中達到這個限制。 – specialscope

GAE數據存儲緩存鍵VS過濾

回答

相關問題