什麼是這個數據最好的MongoDb模式

好吧，我會開始說我不是新手，但我正在尋找最佳的解決方案。什麼是這個數據最好的MongoDb模式

我有4路的關係，爲簡單起見：

Busines 
{ 
bid: unique, 
name: string 
} 

Client 
{ 
cid: unique, 
name: string 
} 

Product 
{ 
pid: unique, 
name: string 
} 

Order 
{ 
oid: unique, 
bid: FK, 
cid: FK, 
pid: FK 
}

什麼將是蒙戈打造最好的方法？

請注意，相同的客戶端也可以在許多業務和相同的產品中使用。

因此有時我需要通過客戶的所有訂單進行選擇，並將數據按業務和其他時間按產品分組。

來源

2013-02-26 Alex Frenkel

考慮您的評論：

我同意，但問題是在速度和MongoDB的分片/複製是更好的那麼MySQL例如...而我將有小幅整理的大量的元素（百萬）和這裏的RDBS都會有它的缺點... :(

我相信你看這是錯誤的。MongoDB的只會比一個RDBMS更快，如果它適合您的方案以這樣的方式使其更快。

數以百萬計的行甚至沒有值得在大多數數據庫中的碎片，甚至商品服務器可以處理至少幾TB的信息。分片來自需要增加寫入容量，就像它在RDBMS技術中所做的那樣，而不是從數據的大小來決定。

但是作爲回答架構的問題，我會離開它，因爲它是目前除我會刪除訂單和更換客戶端裏面：

{ 
    _id: ObjectId(), 
    name: 'sammaye', 
    orders: [ 
     {oid:{},bid:{},cid:{},pid:{}}, 
     { //etc } 
    ] 
}

這是一個小而麥格對象，不應該造成太多問題，並且不會每天增加100個，所以不應該導致嚴重和立即的碎片化。

如果您發現它確實會導致您的流量和訂單費率出現碎片，您可以隨時使用兩種尺寸分配（http://docs.mongodb.org/manual/reference/command/collMod/）的功率來幫忙，但是我應該警告這實際上在短期內表現較差，所以不要無需使用此選項。

也就是說，您提供給我們的信息。我將如何設計該模式。

來源

2013-02-26 11:10:58 Sammaye

首先，我同意你上面的評論，關於信息的大小，我也有數據庫，可能不是TB，但有一個GB，但我的問題不是規模，它是在小操作的數量訂單）。在這裏，NoSQL比SQL有明顯的優勢。我確實喜歡你把這個命令嵌入到客戶端的方法......但是我將不得不使用它。 – 2013-02-26 12:31:01

@AlexFrenkel是的，如果你正在看很多操作，那麼它可能會更高性能，它聽起來像你基於你需要分片的數據大小是所有:) – Sammaye 2013-02-26 12:35:10

不，抱歉...是我的錯誤:)數據大小實際上非常小，這次...我第一次，我不期望我的數據庫超過1GB磁盤空間... – 2013-02-26 12:51:56

爲了給出一種替代方法，您可以將Clients作爲單獨的集合保存，並將Product信息嵌入（至少部分）Order。

通常很重要的一點是要知道客戶在下單時點的訂單（以及他們支付的價格，貨幣等）。您仍然會提及產品，但這意味着您可以查看歷史訂單，並實際瞭解當時客戶購買的產品。產品細節隨着時間的推移而合法變化

這仍然意味着快速讀取;我假設業務集合將比客戶小得多，所以也許可以在應用程序級別處理（即緩存業務，所以你沒有在數據庫上查找每一個）

我很欣賞我所說的信息目前不在產品文檔中，但可能需要考慮一些事情。

當然有一個文件大小限制，如果你denormalising產品信息（或其中一些），並且一個客戶可以爲許多企業下訂單，你需要檢查你有餘地把這些信息保存在客戶收集 - 但這取決於訂單數量和大小等。

無論如何，已經有一些很好的答案處理性能等技術問題，只是認爲我會提出不同的意見。

來源

2013-02-27 08:54:44 sambomartin

什麼是這個數據最好的MongoDb模式

回答

相關問題