以MongoDB為例與關係型資料庫比較

思維之上發表於2017-08-09
MongoDB資料庫

宣告：本文屬於探討性話題，肯定存在很多疏漏和錯誤，不要盲目相信，大家發現什麼錯誤或者有什麼想法請求務必告知

在比較之前，先介紹一個重要的概念：資料庫事務

作為單個邏輯工作單元執行的一系列操作，要麼完全地執行，要麼完全地不執行。

一個邏輯工作單元要成為事務，必須滿足所謂的ACID（原子性、一致性、隔離性和永續性）屬性。事務是資料庫執行中的邏輯工作單位，由DBMS中的事務管理子系統負責事務的處理

由此再簡要說明一下ACID

  • Atomic：原子性，無論包含多少操作，事務是一個不可分割的整體
  • Consistency：一致性，每個事務必須保證資料之間存在的各種關係和約束
  • Isolation：隔離性，事務之間的操作是相互獨立的，互相之間沒有交叉。（影響資料庫效能的關鍵）
  • Duration：永續性，事務完成後對於系統的影響是永恆的，不會隨時間而改變

有了資料庫事務的概念後，我們再來看MongoDB（同時代表大部分NoSql，下文不再重述）和MySql（代表大部分關係型資料庫，下文不再重述）的區別，分為三部分。

1 儲存結構

資料庫MongoDBMySQL
第一層CollectionTable
第二層documentrow
結構固定否是
預先定義表結構否是
允許儲存列表是否
允許巢狀document可以巢狀否

MongoDB主要以鍵值對的形式儲存，隨時可以以任意形式插入，且document可以巢狀，所以在資料的存取和查詢上相當靈活、高效。但同時由於形式不嚴謹，對於有一定邏輯的操作，不容易實現。
相比較之下，mysql雖然不那麼靈活，但結構嚴謹，能實現較為複雜的關係和業務。

2 資料庫事務

資料庫事務原本就是關係型資料庫中發展出來的概念，所以MySQL肯定全部滿足。而MongoDB是不支援事務的（這也是其靈活的關鍵），但對於事務中的ACID值得討論。

  • 原子性：mongodb對於document的基本操作是滿足原子性的，對於較為複雜的集合操作（同時又很多操作）也提供了很多函式確保原子性。
  • 一致性：MongoDB是很難滿足資料的一致性的（雖然有Read Concern和Write Concern），尤其對於分散式資料庫，根據CAP理論，MongoDB在損失了一致性的同時，有一定的分割槽容錯性。這種情況對於併發性不是很高，邏輯不是很嚴謹的系統是合適的，如果有某些業務需要保證較高的一致性，MongoDB可以借用鎖實現。
  • 隔離性：由於隔離性的實現代價較高，對於效能的影響較大，並且MongoDB保證了原子性，所以對於大部分情況，是不保證隔離性的，即事務之間有交叉，但原子操作之間是沒有的。
  • 永續性：滿足，基本上對於所有的資料庫都是滿足永續性的吧，除了記憶體資料庫。

還有很重要的一點是資料的完整性。包括實體完整性，引用完整性，使用者自定義完整性。MongoDB是可以實現實體完整性的，引用完整性可以用DBRef實現。使用者自定義完整性，既然是自定義肯定就有很多實現和方法，MongoDB自帶的使用者自定義完整性肯定是沒有MySQL豐富和方便的。

3 效能及應用場景

由以上可以得到各自的顯著特點：
MongoDB：存取靈活，弱結構，鍵值對（JSON）形式適合很多應用場景。
MySQL：結構嚴謹，邏輯嚴密，有完整的數學理論支援。

應用場景：
MongoDB：
1. 弱結構很適合第三方資訊的抓取，不需要為各種來源設計表結構，直接儲存，極大的減少了資料庫設計維護的工作量。
2. 存取靈活適合於一些隨時存取，結構化要求又不高的業務場景，比如日誌檔案、資料分析處理等
3. 鍵值對是接近很多有匹配關係業務的真實應用場景，如物流（訂單、點到點）、遊戲（玩家對應的裝備）、社交（使用者之間的關係和動態）等，都能直接匹配，高效存取。

MySQL：
1. 需要嚴密的資料結構的人事管理、大型企業網站。
2. 對於事務一致性和隔離性有高要求的金融、電商、軍事等高併發的網站。

綜合來看MongoDB沒有事務機制，不能很好地滿足許多複雜業務，更多的是當做一種工具，去實現某些區域性、零散的需求，提高效率，而MySQL有完善的理論，可以應對絕大部分業務場景，更適合去服務各種實際應用和業務。

繼續完善補充中

相關文章