MongoDB的Schema設計場景關係說明

文:Johnson Wu

MongoDB是著名的NoSQL資料庫,不同以往的RDBMS的ROW-COLUMN格式每個物件的欄位不一定相同,且在NoSQL資料庫較可以動態擴充欄位。

但更高的彈性也意味著需要有更好的設計規劃,為了讓資料更好被維護,應該需要針對業務邏輯規劃Schema。

有很多剛從RDBMS轉換到MongoDB的初學者只是把在只是把在RDBMS的作法照搬一份到MongoDB將Collection當Table在使用,反而會質疑為何要轉換MongoDB?

也沒有獲得太多MongoDB帶來的好處,且有可能造成存取上的負擔。

設計場景

初探MongoDB時遇到幾個問題個問題,何時應該進行正規化?

相關資料如何進行關聯?

如何跨Collection進行存取?

如何處理ACID相關問題?

MongoDB支援JSON格式儲存,因此單一Document可以直接存入多層格式的物件,但單一Document還是有最大16MB最大深度100的上限限制。

在這兩個條件下,我們以資料基數將基本的設計模式分為:

  • One-to-Few (少量)
  • One-to-Many (多量)
  • One-to-Squillions (海量)

One-to-Few

當預主體的欄位所包含的資料是有限且可預期的,且符合Document的限制(16MB),就可以使用One-to-Few的模式,這樣的方式稱為Embedding

優點:在於不需再執行額外的查詢來獲取詳細的資訊
缺點:則是無法將嵌入的資訊當作個體(stand-alone entities)單獨查詢

One-to-Many

當預期主體的欄位資料數量雖然可預期,但Embedding物件全部都放在同一個Document可能會超過16MB的上限,且若考慮資料獨立性問題,就可以參考RDBMS的關聯做法,將關聯的資料放在另一個Collection,並在Parent Document紀錄關聯的ObjectId,實際查詢時透過Application-Level Join進行反查。此種方法可滿足多量級的一對多關係,並保有資料獨立性,這種方式稱為Child-Referencing

優點:優點在於每個關聯物件都是獨立的Document,因此很容易對關聯的Document進行查詢及更新
缺點:需要執行至少兩次查詢才能取得完整資訊

One-to-Squillions

當預期主體參照的另一個主體可能為海量級(資料會無限增長),不論是儲存多個物件或是多個ObjectId,都無法保證在單一Document最大16MB的限制。當遇到這個情況時可以換成反向參考,在海量級主體中紀錄主體的ObjectId,此種方式稱為Parent-Referencing

優點:適合存放資料量會隨著時間成長,例如系統日誌、交易日誌等等
缺點:需要執行至少兩次查詢才能取得完整資訊

專人協助

由偉康業務人員為您詳細說明偉康的解決方案,以及相關產業經驗。

訂閱偉康科技洞察室部落格,掌握最新科技趨勢!

立即訂閱電子報

掌握最新科技趨勢!