建模的NoSQL數據庫（從SQL數據庫轉換時）

Question

我有我想轉換到NoSQL的一個（我目前使用RavenDB）

這裏是我的表SQL數據庫：

跟蹤：

ID (PK, bigint, not null) 
DeploymentID (FK, int, not null) 
AppCode (int, not null) 

部署：

DeploymentID (PK, int, not null) 
DeploymentVersion (varchar(10), not null) 
DeploymentName (nvarchar(max), not null) 

應用：

AppID (PK, int, not null) 
AppName (nvarchar(max), not null) 

目前，我有我的表這些行：

跟蹤：

ID: 1 , DeploymentID: 1, AppCode: 1 
ID: 2 , DeploymentID: 1, AppCode: 2 
ID: 3 , DeploymentID: 1, AppCode: 3 
ID: 3 , DeploymentID: 2, AppCode: 1 

部署：

DeploymentID: 1 , DeploymentVersion: 1.0, DeploymentName: "Test1" 
DeploymentID: 2 , DeploymentVersion: 1.0, DeploymentName: "Test2" 

應用：

AppID: 1 , AppName: "Test1" 
AppID: 2 , AppName: "Test2" 
AppID: 3 , AppName: "Test3" 

我的問題是：如何構建我的NoSQL文檔模型？

如果它看起來像：

trace/1 
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ], 
"Application": "Test1" 
} 

trace/2 
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ], 
"Application": "Test2" 
} 

trace/3 
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test1" } ], 
"Application": "Test3" 
} 

trace/4  
{ 
"Deployment": [ { "DeploymentVersion": "1.0", "DeploymentName": "Test2" } ], 
"Application": "Test1" 
} 

而如果部署1得到改變？我應該按照每個文檔去更改數據嗎？

何時應該在NoSQL中使用引用？

Answer 1

你如何建模你的文檔主要取決於你的應用程序和它的域名。從那裏開始，可以通過理解數據訪問模式來改進文檔模型。

盲目試圖將關係數據模型映射到非關係數據模型可能不是一個好主意。

更新：我認爲馬特在這裏得到了我的觀點的主要想法。我想說的是，沒有規定的方法（我知道無論如何）在沒有理解的情況下將關係數據模型（如規範化的SQL模式）轉換爲非關係數據模型（如文檔模型）考慮應用程序的領域。讓我在這裏詳細說明一下......

看完您的SQL架構後，我不知道除了似乎加入應用程序和部署的表之外還有什麼跟蹤。我也不知道你的應用程序通常如何查詢數據。稍微瞭解一下這一點會在您爲文檔建模時發揮作用，就像在模型化應用程序對象（或域對象）的方式上會產生變化一樣。

因此，您的問題中提出的文檔模型可能適用於您，也可能不適用於您的應用程序。

Answer 2

諸如Raven之類的文檔數據庫不是關係數據庫。您不能先構建數據庫模型，然後再決定各種有趣的查詢方式。相反，您應該首先確定要支持的訪問模式，然後相應地設計文檔模式。

所以爲了回答你的問題，我們真正需要知道的是你打算如何使用這些數據。例如，顯示按時間排序的所有跟蹤與顯示與特定部署或應用程序關聯的跟蹤完全不同。這些要求中的每一個都會規定不同的設計，同樣會支持它們。

這本身可能是有用的信息給你（？），但我懷疑你想要更具體的答案:)所以請添加一些額外的細節，你的預期用法。

有幾個「做」和「注意事項」一項戰略決定時：

DO：優化了常見的用例。 20％的用戶體驗驅動80％的負載時經常出現20/80的崩潰 - 網頁應用的主頁/着陸頁是一個典型的例子。首要任務是確保這些儘可能高效。確保你的數據模型允許A）加載那些在單個IO請求或B）緩存友好

不要陷入可怕的「N + 1」陷阱。當您的數據模型強制您進行N次調用以載入N個實體時，會出現此模式，通常在進行額外的調用之前獲取N個ID的列表。這是一個殺手，尤其是＃3 ...

DO：始終限制（通過UX）您願意獲取的數據量。如果用戶有3729條評論，你顯然不會一次抓取所有評論。即使它從數據庫的角度來看也是可行的，用戶體驗將會非常糟糕。這就是爲什麼搜索引擎使用「下一個20個結果」範例。因此，您可以（例如）將數據庫結構與UX對齊，並將註釋保存在20個塊中。然後每個頁面刷新都涉及一個數據庫獲取。

DO：平衡讀寫要求。某些類型的系統是重讀的，你可以假設每次寫入都會有很多讀操作（StackOverflow就是一個很好的例子）。因此，爲了獲得讀取性能的好處，使寫入更加昂貴是有意義的。例如，數據非規範化和重複。其他系統均衡均衡，甚至寫入重量，並要求其他方法

做：使用TIME的維度您的優勢。 Twitter是一個典型的例子：99.99％的推文永遠不會在第一個小時/一天/周/之後被訪問。這將在您的數據模式中打開各種有趣的優化可能性。

這只是冰山一角。我建議讀一下基於列的NoSQL系統（如Cassandra）