最近剛入坑MongoDB，感覺比MySQL擴展性更強，一張表可以存盤特別復雜的欄位，這點我非常喜歡，最近需要用MongoDB存盤一篇文章的資料，文章的評論和回復的資料存盤是個大問題，設計了好久感覺我設計的欄位好復雜，還不太合理，請求各位大佬指點一二，希望能參考你們的設計方案，
MongoDB的嵌套與外聯設計權衡
1.文章的評論和回復不要與博文檔案放到一起嵌套，這樣會導致文章集合過大，檔案結構過于復雜，最關鍵是操作檔案的各種行為太多，導致嚴重鎖性能，讓博文和評論回復通過外鍵關聯，
2.讓評論和回復形成獨立的一個集合檔案，回復作為評論檔案的一級陣列即可，形成兩層結構，不要搞成無限嵌套回復的樹形，回復在評論檔案內是一個串列檔案，回復通過回復者和被回復者，就確定評論內用戶的回復關系，
MongoDB的嵌套要慎用，對于頻繁變化和數量可能夠大的情況，最好獨立成集合，通過外鍵關聯，對于更新頻率低，數量小，例如字典等比較適合做成檔案嵌套，
再舉個藥品供應商的例子：
例如：設計藥品訂單，如果業務上幾乎所有訂單下面都是幾個或者二三十個藥品，而且這些藥品的名稱等基本資訊也不會輕易去變，那么訂單檔案的內嵌藥品陣列就沒有問題，可以按照兩種模式設計
（1）可以記錄所有藥品資訊，這樣應用層更容易查詢；
（2）只記錄藥品ID串列，應用層多費點心做個二次查詢，我認為都沒有問題，關鍵是看更細節的設計權衡，例如存盤量，極端情況下藥品名稱修改等等，
再例如說：藥品供應商的模型設計，假如一個供應商下面可能有上千種甚至上萬種需要供應的藥品，這個時候，再讓藥品供應商的檔案去內嵌藥品供應清單就不合適了，就需要反范式設計了，在多的那頭，也就是藥品檔案中加入供應商關鍵資訊的內嵌欄位，因為往往業務上藥品的供應商總是數量有限的，而且供應商基本資訊不會頻繁變化，應用層就可以從藥品檔案上直接用供應商作為條件查詢了，1.文章的評論和回復不要與博文檔案放到一起嵌套，這樣會導致文章集合過大，檔案結構過于復雜，最關鍵是操作檔案的各種行為太多，導致嚴重鎖性能，讓博文和評論回復通過外鍵關聯，
MongoDB設計程序中可能會遇到的坑
雖然MongoDB的易用性已經是分布式資料庫里面最舒服的了，但真實情況是，有些問題的存在只不過沒有露出真面目而已，
首先從團隊資料模型設計上的轉變上說說，MongoDB是檔案模型資料庫，特別強調樹形結構的設計，相當一部分的一對多關聯關系，基本上在Mongo一個檔案結構樹就能體現了，但是大多數的工程師，至少當下來看，習慣的設計還是關系表的范式，這就和第一節所說的情況走向了另一個極端，
如果按照這種習慣去設計并發展下去，就會形成大量的瑣碎集合，從而由于大量的外聯操作，產生大量的鎖競爭，開發也會陷入mongodb不擅長的集合間連接操作，極大降低性能，這會讓運維陷入到另一個泥潭當中，
其次就是這種資料型別的模式演化了，檔案型無論mongodb也好，elasticsearch也好，它們與傳統關系型資料庫最直接的不同，就是不強制預先定義欄位型別，就可以提交資料，由資料庫系統自動識別型別，修改型別的程序也非常方便，因為這是有利于應用系統的敏捷迭代開發，
但這一切都有一個前提條件，就是良好的工程管理能力和人員技能素質，若在一個專案混亂，團隊更換不斷，人員技能不熟的情況下，在資料可靠性壓倒一切的情況下，這種模式只會帶來更意想不到的坑，甚至問題錯在哪里都找不到，若是這種混亂的環境，建議還是老老實實地用傳統關系型資料庫，
最后再想說的就是分布式CAP理論這個本質問題了，MongoDB比MySQL在主從復制上選項中就更復雜了，
MongoDB副本集下的CAP理解
例如：關系型資料庫里面MySQL主從架構復制的異步模式下，滿足可靠性，就不管一致性了；復制的半同步模式下，主節點至少還要等到集群中任意一個從節點的復制重放完成才算結束；復制的全同步那就是強一致性了，以前專門講CAP的文章：CAP 理論常被解釋為一種“三選二”定律，這是否是一種誤解？說過MySQL的三種不同模式：異步、半同步和全同步，也簡單提到了MongoDB的majority選項，
我們再具體看MongoDB的分布式CAP取決的因素：write-concern、read-concern、read-preference三個配置條件：
- write-concern為1，read-concern為local，read-preference為primary的情況下，那么就是讀寫都在主節點，自然是強一致性，基本屬于單機操作，從節點相當于備份，
- write-concern為1，read-concern為local，read-preference為secondary的情況下，寫在主節點，讀在從節點，這個程序無法保證從節點實時能拿到最新的資料，但能保證可用性高，就和MySQL異步模式下的讀寫分離一個道理了，
- write-concern為1，read-concern為majority，這個majority的意思就是新資料被大多數的從節點都已經復制確認后才能被讀取，這種情況下無論在主節點或在從節點讀取資料，都有可能拿的不是最新的資料，這就是所謂的弱一致性，
- write-concern為majority，read-concern為majority，第一個majority的意思就是新資料被大多數的從節點都已經復制確認后寫入才算數，第二個majorit的意思同上—新資料被大多數的從節點都已經復制確認后才能被讀取，這種情況下read-preference是primary，也就是在主節點讀取，一定最新資料，強一致性，可用性差；read-preference若是secondary，也就是在從節點讀取，弱一致性，可用性高，
前往讀位元組創作中心——了解”讀位元組“更多創作內容
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/286083.html
標籤：其它
上一篇：Excel-宏與VBA-資料型別
下一篇：Redis資料結構