我有一個像User,Message和MessageFeatures這樣的實體的應用程序。每個用戶可以有許多消息,每個消息都有一個MessageFeatures實體。目前,關係模型表示爲:Couchbase 4.0數據建模
User{
UUID id
String email
...
}
Message{
UUID id,
UUID userId
String text
....
}
MessageFeatures{
UUID id
UUID messageId
UUID userId
PrimitiveObject feature1
....
PrimitiveObject featureN
}
最重要的疑問是:
- 獲取用戶
- 所有消息獲取用戶的所有信息功能
- 找UUID 消息
- uuid獲取/更新留言功能
- 通過留言uuid獲取留言功能
不太重要的(可能是緩慢的)查詢是這樣的:
- Get消息設有其中USER_ID = someuuid和featureX =值
- 獲取所有/計數用戶的UUID爲哪些featureX =值
- 更新消息功能集featureX = newValue其中featureX = oldValue
在評估couchbase時,我無法得到正確的數據模型。我不認爲將用戶的所有消息和消息功能放在單個文檔中是一個不錯的主意,因爲它的大小會不斷增加,並且基於當前數據,對於2年的數據,它很容易在4-5 MB範圍內。同樣爲了保持一致性,我可以一次只更新一個消息特徵,因爲原子性是每個文檔。
如果我沒有將它們放在單個文檔中,它們將散佈在羣集中,並且像查詢用戶的所有消息/消息特徵這樣的查詢將導致分散和聚集。
我已簽出全球二級指標和N1QL但即使消息只會在獲取該用戶的message_uuids,加載所有的消息將導致散射和收集幫助我指數user_uuid場...
有沒有辦法強制將一個user_uuid的所有消息,消息特徵映射到同一物理節點,而不將它們嵌入到同一文檔中,如redis中的hashtags。
需要一些更多的說明...根據http://www.couchbase.com/nosql-databases/downloads多維和獨立縮放不可用社區版...這是否意味着我將不得不運行所有3個服務(查詢,索引,數據)在每個節點上,因爲如果是這種情況,GSI不會有多大用處?我是正確的還是圍繞這一點有一個聰明的機動......例如。考慮一個由6個節點組成的集羣,並且用戶消息分散在所有節點上......即使GSI考慮網絡延遲,查詢如何獲得用戶ID的所有消息仍然有效......我錯過了什麼? – gladiator
儘管您將在每個節點上運行所有三項服務,但每個單獨的GSI索引將僅存在於一個節點上,因此您不會進行分散收集。 – geraldss
你能否指點我一些資源,所以我可以肯定 – gladiator