2015-11-12 106 views
0

我有一個像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。

回答

1

您應該將上面的關係模型直接轉換爲Couchbase。您應該爲所有關係(id字段)創建GSI索引。使用EXPLAIN來確保每個查詢都使用索引。要通過id直接查找,請使用USE KEYS。

Couchbase中的分散/聚集意味着與您描述的不同。這是當一次索引掃描必須訪問多個節點,然後合併掃描結果(分佈式索引)。相反,每個GSI索引都位於單個節點上,因此GSI索引可以避免分散/聚集。

最後,請注意,即使跨節點,Couchbase在鍵值提取上也很快,因此您不必擔心數據的局部性。

+0

需要一些更多的說明...根據http://www.couchbase.com/nosql-databases/downloads多維和獨立縮放不可用社區版...這是否意味着我將不得不運行所有3個服務(查詢,索引,數據)在每個節點上,因爲如果是這種情況,GSI不會有多大用處?我是正確的還是圍繞這一點有一個聰明的機動......例如。考慮一個由6個節點組成的集羣,並且用戶消息分散在所有節點上......即使GSI考慮網絡延遲,查詢如何獲得用戶ID的所有消息仍然有效......我錯過了什麼? – gladiator

+0

儘管您將在每個節點上運行所有三項服務,但每個單獨的GSI索引將僅存在於一個節點上,因此您不會進行分散收集。 – geraldss

+0

你能否指點我一些資源,所以我可以肯定 – gladiator