2012-02-27 39 views
3

您好iam是Dynamo數據庫中的新成員,據我所知它是一個非關係數據庫,即我們無法加入表格。我的疑問是我們如何設計表格結構。請用下面的例子來說明。我們如何設計與兩個實體保持關係的Dynamo db

我有以下各表 1)用戶 - user_ID的,用戶名,密碼,電子郵件,電話號碼,角色 2)角色 - ID,名稱[即管理員,主管等..]

一)我的第一個疑問是,我們有任何規定爲user_id字段設置自動增量? b)將主鍵設置爲user_id是否正確? c)這是在Dynamo數據庫中存儲用戶角色的正確方法嗎?即一個角色表包含​​ID和標題,並在用戶表中存儲角色ID? e)這可能與每個用戶一起檢索兩個表格數據嗎?我使用的軌道3和AWS-SDK寶石

如果有人回覆這將是對我很大的幫助像一個新的dynamodb用戶

回答

6

通常與NoSQL的風格數據庫您需要提供唯一的標識符,而不是一個自動遞增PK領域爲你做。這通常意味着你將有一個GUID作爲每個用戶記錄的關鍵。

至於用戶角色,有很多方法可以做到這一點,每個人都有優點和存在的問題:

一個簡單的方法將是一個「角色」屬性添加到用戶表,並且每個一個條目該用戶的角色。然後你可以抓住用戶,你將在一個查詢中擁有所有角色。 DynamoDB允許屬性具有多個值,因此一個屬性每個角色可以有一個值。

如果您需要能夠查詢特定角色的用戶(即「給我所有用戶是主管」),那麼您將在DynamoDB中執行表掃描,這可能是一項昂貴的操作。但是,如果您的用戶數量相當小,並且需要進行此類查找的頻率不高,那麼對於您的應用程序而言,這仍然可以接受。

如果您確實需要經常執行這種昂貴的查找類型,那麼您需要創建一個類似於「RolesWithUsers」的新表,每個Role具有一條記錄,用戶的userIds位於角色記錄中。對於大多數應用程序,我建議不要這樣做,因爲現在您有兩個表格代表一個事實:特定用戶具有什麼角色。所以,每次需要在兩個地方完成刪除或更新。這不是不可能做到,但需要更多的警惕和測試,以確保您的應用程序不會得到錯誤的數據。這種方法的另一個缺點是您需要兩次查詢來獲取信息,這可能比表掃描更昂貴,這取決於記錄的數量。

另一個對這個特定用例有意義的選擇是使用SimpleDb。它具有更好的查詢能力(所有屬性都默認爲索引),並且具有多值屬性角色的單個表在這種情況下比DynamoDB要好得多。

希望這會有所幫助!

+0

非常感謝史蒂夫,我得到了DB結構的想法。 – merahulpk 2012-02-28 12:39:21

+0

如果您擁有10,000,000個用戶,所有角色都是「標準」,該怎麼辦?這是否適合64kb的限制(因爲對於具有該角色的用戶將有一個「讀取」條目和10,000,000個GUID)?我沒有得到什麼嗎? – cmcculloh 2012-04-17 20:42:21

+0

該場景非常具體,是的你必須考慮尺寸限制。對於角色的具體情況,如果10m用戶具有相同的角色,我會質疑具有「標準」命名角色的實用程序,如果找不到其他角色,那麼這只是默認角色。但是,是的,您需要考慮您的應用使用情況並針對任何解決方案進行擴展。 – Steve 2012-05-10 15:47:46

0

我們有類似的情況,我們只使用兩個DB,一個關係型和一個NoSQL(Dynamo)。對於「用戶」對象,與其他事物(如角色,項目,技能等)相關聯的所有內容以及用戶的所有內容(屬性等)都放在Dynamo中。如果我們需要向用戶添加新屬性,那很好,因爲NoSQL不關心這些屬性。經驗法則是,如果我們只在該對象頁面上需要某些東西(也就是說,我們不需要與其他對象關聯),那麼我們就放入Dynamo。否則,它是關係型的。

使用上的NoSQL數據庫的表掃描是不是一個真正的選擇你穿越即使是很小的閾值之後(到這一點,你可以使用內存中的DB反正)。