尋找適用於Google App Engine的非規範化建議

Question

我正在開發一個系統，該系統將在GAE上運行，該系統將具有多個相關實體，並且我不確定存儲數據的最佳方式。這篇文章是對其他人可能有類似經驗的建議的請求....

該系統將有用戶，配置文件數據和圖像。這些用戶將能夠創建「事件」並向其添加日記條目。爲了系統的目的，「事件」可能會有1或2個日誌條目，超過10的條目可能永遠不會發生。其他用戶也可以向用戶的條目添加評論，其中流行的評論可能有數百甚至上千條評論。當一個隨機訪問者使用該系統時，他們應該能夠看到最新的事件（最新的，由最新的日記條目定義的），通過標籤進行搜索以及執行基本的文本搜索。然後，在選擇要查看的活動時，應該顯示所有日記條目和所有用戶評論，並在用戶圖片旁邊添加評論。用戶還應該有一個自我管理頁面，以查看/修改/刪除他們的事件，並查看/修改/刪除他們對其他事件做出的評論。因此，在正常的RDBMS上執行所有這些操作只需要在幾個表中進行一些大連接的查詢。在GAE上，顯然需要以不同的方式工作。下面是我在實體設計的初步想法：

• 事件實體 - ID，姓名，timstamp，列表的標籤 屬性，查看次數， 創建者的用戶名，創作者的個人資料 圖片ID，日記條目的數量 它包含，總評論 它包含的數量，最後更新包含日記條目，搜索的索引詞列表屬性（內置/從文本更新從包含日記帳分錄）
• JournalEntry的實體的時間戳 - ， 雜誌文本，事件的名稱， 創建者的用戶名，創建者的配置文件Ë 圖片ID，評論 （含評論者的用戶名和 圖片ID）
• 用戶實體列表屬性 - 用戶名，密碼哈希，電子郵件，訂閱事件的列表屬性，創建日期，圖片ID，評論數的時間戳發佈，創建的事件的數量，創建日記條目的數量，最後雜誌活動的時間戳
• UserComment在實體 - 用戶名，事件的ID評論，事件的標題評論
• 對tagdata實體 - 標籤名，與標籤事件的數對他們

所以，我會升希望聽到人們在這裏思考設計，並且應該做出什麼樣的改變來幫助它的擴展。謝謝！

Answer 1

• 而不是商店Event.id作爲一個屬性，使用自動嵌入在每個實體的key，或者你創建它們設置唯一key names對實體的ID。
• 你有很多的建模Event和JournalEntry之間的關係選擇：你可以使用一個ReferenceProperty，你可以父JournalEntries到Events與祖先查詢檢索它們，或者你可以存儲在Event的JournalEntry鑰匙ID或名稱的列表並用密鑰查詢批量檢索它們。用實際分佈的虛擬數據嘗試一些事情，並使用appstats來查看最佳效果。
• UserComment引用了Event，而JournalEntry引用了UserComments的列表，這有點令人困惑。UserComment和JournalEntry之間有關係嗎？或者只是在UserComment和Event之間？
• 堅持如此多的計數是昂貴的。當我發表評論時，您將寫一個新的實體UserComment，並更新我的User實體和一個JournalEntry實體和一個Event實體。您期望的UserComments的數量是Event，因此將所有內容包含在同一個實體組中是不明智的，這意味着您無法事務性地執行這些寫入操作，因此您可以連續執行這些寫入操作，並且實體可能存儲在不同的網絡節點上，使整個行動緩慢;而且你也會對一致性問題持開放態度。你可以不做這些計數，並考慮將其他人存儲在memcache中嗎？
• 當您從數據存儲中獲取Event時，實際上並不關心其搜索索引字列表，並且從協議緩衝區中檢索和反序列化它們會產生成本。您可以通過將每個Event的搜索索引詞拆分爲單獨的子實體來解決此問題。然後你就可以查詢您的搜索字詞EventIndex，取只爲EventIndexes符合搜索條件的EventIndex鍵，推導出相應的Events「鍵，帶key.parent()，以及主要獲取Events，從來沒有支付你的搜索索引詞的檢索和反序列化名單。 Brett Slatkin在14:35解釋了這個策略here。
• 更新Event.viewCount將失敗，如果你有很多觀點的任何Event快速連續，所以你應該嘗試計數sharding。

祝你好運，並告訴我們你通過嘗試的東西瞭解你。