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

思維之上發表於2017-08-09

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


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

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

一個邏輯工作單元要成為事務,必須滿足所謂的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有完善的理論,可以應對絕大部分業務場景,更適合去服務各種實際應用和業務。


繼續完善補充中

相關文章