Loading...

學習資料庫時,MySQLMongoDB 通常我們最先會碰到的。在「該用 MySQL,還是 MongoDB 呢?」這個問題的背後,兩者分別代表著不同的資料庫設計方式,各有各自的優勢與劣勢,用來解決不同的問題。

因此真正的問題在於,你準備要打造的應用程式在解決什麼問題?會如何設計、維護?有多少資源?未來如何 scale up 等等問題。確認了這些問題之後,才有辦法回過頭來,挑選最適合的資料庫,來幫助你完成任務。

-----這篇文章是寫給網路開發 (web development) 的初學者,如果你對於「要選 MySQL 或是 MongoDB」的這個問題還不確定的話,歡迎跟著本文一起探索資料庫的世界!

這篇文章也不是 MySQL 與 MongoDB 的介紹文,你也不會學到如何 setup database。如果想要深入瞭解兩者的的設計與操作,請參考分別的 documentation (MySQL | MongoDB)-----

在學習網路開發的時候,很早就會學到使用資料庫來儲存資料,並學習資料庫的相關操作。 MySQL 與 MongoDB 除了有免費使用的版本、容易上手之外,網路上的討論度也高,可以找到不少相關的資料。

但離開學習教材,自己準備開始一個新的專案的時候,有個問題就會立即浮上心頭:

「我應該用 MySQL,還是用 MongoDB 好呢?」

如果拿這個問題去問其他工程師朋友,得到答案可能大多數是「看情況囉」。別擔心,不是你的人緣差,也不是你的工程師朋友不想回答這個問題。而是應該先問問自己「問對問題了嗎?」

選擇資料庫時要回答的問題

在 MySQL 和 MongoDB 之間做選擇,並不是像選擇「火腿蛋餅還是玉米蛋餅」這種單純口味上的選擇,因為兩者的背後,分別代表著不同的資料庫設計方式,各有各自的優勢與劣勢,用來解決不同的問題。

因此真正的問題在於,你準備要打造的應用程式在解決什麼問題?會如何設計、維護?有多少資源?未來如何 scale up 等等問題。確認了這些問題之後,才有辦法回過頭來,挑選最適合的資料庫,來幫助你完成任務。

但,如果你對於資料庫沒有一定程度的瞭解,到了真正需要選擇的時候,也將無從下手。因此就讓我們先來看看 MySQL 與 MongoDB 這兩個資料庫管理系統 (Database Management System, DBMS) 背後的資料庫設計方式,也就是大家常聽到的關聯式資料庫 (Relational Database, RDB) 以及非關聯式資料庫 (NoSQL) 吧!

延伸閱讀:SQL/NoSQL是什麼?認識資料庫管理系統DBMS

關聯式資料庫(RDBMS)成為主流

早在當年電腦還是跟房間一樣大的年代,電腦只是一個大型的計算機,沒有儲存功能。人們會將需要計算的資料(卡片)放入這台機器當中,經過運算後,再把結果(卡片)吐回。人們之後就會把這個資料(卡片)收在辦公室或實驗室的某個櫃子當中,存放起來。

但後來發現電腦的功能越來越強大,不僅僅可以處理研究問題,也開始能夠處理商業問題,而在商業問題當中,資料是非常有價值的,因此人們開始思考如何儲存資料,如何集中管理並分享。

在 1960 年代開始,陸續出現了階層模型 (Hierarchical database model) 與網狀模型 (Network Model) 的資料庫設計方式。在 1970 年 6 月,IBM 電腦科學家 Edgar F. Codd 發表了「A Relational Model of Data for Large Shared Data Banks」,奠定了現今我們所普遍使用的關聯式資料庫的設計方式。

Hierarchical model

Hierarchical model 提供了類似階層結構的設計,將資料分門別類依序往下安排,這樣管理方式的好處是,簡單易懂,同時也符合日常生活的使用習慣(想想看我們平時是怎麼整理電腦裡面的資料夾)。但 Hierarchical model 的資料關係相對侷限,僅有上對下的父子關係,另外若是刪除一個父節點,將會影響到子節點的資料(譬如不小心誤刪了 D 槽)。

Relational model

相較之下, Relational model 雖然提供了較抽象的資料設計(將資料拆分成許多不同的 tables),不過提供了更多元的關係建立(譬如多對多關係),能夠拿來代表真實世界複雜的資料關係,同時提供了更高的資料操作彈性。



而 Network model 雖然提供了更高的彈性,能夠更直接、快速的在多對多的關係當中找到對應的資料,不需要透過額外的資料表(譬如 Relation model 的 join table)查詢,省下了儲存空間,但是 Network model  相對複雜,若要更新資料也是相對麻煩。在網狀結構當中,牽一髮可能就動全身。

因為以上種種原因,使得 Relational model 成為主流使用的資料庫設計方式,根據這種設計方式所建立的資料庫管理系統,就叫做關聯式資料庫管理系統 (Relational Database Management System, RDBMS)。 SQL (Structured Query Language) 也在此時根據 Relational model 的設計原則誕生。

目前常見的 RDBMS 有

雖然以上的 RDBMS 都是根據 Relational model 進行設計,但實際建構與操作上還是有所差異。因此不是所有的關聯式資料庫都是一樣的喔,使用前請記得參閱公開說明書喔。

另外,雖然乍看之下 Hierarchical model 和 Network model 好像沒有這麼優秀,但實際上不同工具有不同的使用場景,這兩個 model 至今還是持續有在使用。譬如圖書館所使用的杜威十進分類法 (Dewey Decimal Classification),其實就是 Hierarchical model 的一種。如果電腦中的檔案如果是用 Relational model 的方式分類,那使用起來也是相當麻煩呢。

關聯式資料庫的特色

  1. 資料存放在一個或多個資料表當中。資料都是透過資料表中行列的二元關係呈現。
  2. 資料表需預先設定架構 (schema)
  3. 資料表之間的關係也需要預先定義好,使資料之間有明確的關聯
  4. 可以透過 SQL 語言進行資料操作

另外,一個好的關聯式資料庫設計,也需要能夠確保每一個 transaction 能夠滿足 ACID 原則。ACID 分別代表

  • Atomicity (原子性) : 資料操作不能只有部分完成。一次的 transaction 只能有兩種結果:成功或失敗
  • Consistency (一致性):transaction 完成前後,資料都必須永遠符合 schema 的規範,保持資料與資料庫的一致性
  • Isolation (隔離性):資料庫允許多個 transactions 同時對其資料進行操作,但也同時確保這些 transaction 的交叉執行,不會導致數據的不一致
  • Durability (耐久性):transaction 完成後,對資料的操作就是永久的,即便系統故障也不會丟失

上面這些特色,讓關聯式資料庫看起來相當完美。但,事情總是沒有想像中的那麼簡單

關聯式資料庫的侷限性

隨著網路應用程式的普及,使得資料庫的使用、分享、與資料量飛快地增加,讓原本的資料庫設計遇到的挑戰。人們除了需要更快的速度來處理大量資料之外,也需要能夠及時地提供服務以滿足大量使用者的需求。

此時人們開始轉向非關聯式資料庫設計來尋找解決方法,NoSQL 也就開始站上了舞台。NoSQL 的意思不是「不要用 SQL 」或是「資料不需要關聯」,NoSQL 它真正的意思是 Not Only SQL,也就是「不是用 SQL 操作資料的資料庫設計」,因此實際上資料之間還是可以建立關聯的喔。

另外,NoSQL 也不是橫空出世,雖然這個詞看起來很新,但早在電腦科學發展初期,就有許多不同於 Relational model 的資料庫設計。

除了 ACID,你可能還聽過 BASE

剛剛我們提到過關聯式資料庫滿足 ACID 原則,那麼 NoSQL 呢?相對於 ACID,你可能還聽過 BASE(有酸就有鹼)

1999 年電腦科學家 Eric Brewer 提出的 CAP 理論,在一個分散式的資料儲存架構下,不可能同時滿足下面三個條件:

  • Consistency (一致性):在任何時刻,所有節點的資料須保持一致
  • Availability (可用性) :在正常的響應時間 (response time) 內,使用者都要能夠會得回應
  • Partition tolerance (分區容錯性):在部分區域故障的時候,仍然能夠提供滿足一致性與可用性的服務



為了達到 Partition tolerance,能夠持續提供不間斷的服務給今日大量的使用者,就需要在 Consistency 和 Availability 兩者之間做出妥協。因此你可能會聽到相對於 ACID 的 BASE 原則:

  • Basically Available:保持服務基本可用
  • Soft State: 狀態可以有一段時間的不同步
  • Eventual consistency (最終一致性):雖然有一段時間不同步,但追求最後結果一致

在這個 CAP 取捨的遊戲當中,有許多的「非關聯式資料庫設計」應運而生,但妥協不是全有或是全無,端看該資料庫設計想要著重在什麼價值與功能、解決什麼問題。

非關聯式資料庫(NoSQL)的特色

既然 NoSQL 的意思是非關聯式資料庫設計,代表它其實是很大的一個分類,當中有許多的設計方式,因此多少一定會有所不同。不過這裡還是可以歸納一下他們與 RDBMS 主要的差別

  1. 不需要事先定義好資料的 schema 以及資料之間的關聯
  2. 可以自由新增欄位,不需要回頭修改過去的資料文件 (document)
  3. 可以自由定義資料文件 (document) 的結構

不同於關聯式資料庫使用資料表行與列的的二元關係呈現,NoSQL 的儲存資料的方式相當多元,像是

  • Key-Value Cache (e.g. Memcached, Redis)
  • Key-Value Store (e.g. Oracle NoSQL Database, Redis)
  • Document Store (e.g. MongoDB, Elasticsearch)
  • Wide Column Store (e.g. Amazon DynamoDB)
  • Graph (e.g. ArangoDB, OrientDB )

學習資料設計與NoSQL資料庫,實作待辦清單應用程式

MySQL or MongoDB?

說了這麼多,回過頭來到自己的專案上,該選擇 MySQL 還是 MongoDB 呢? 阿不對,剛剛都繞了這麼一大圈了,這裡應該是問,

「該選擇 RDBMS  還是 NoSQL 呢? 」

這裡有幾個考量點提供給大家參考:

可以考慮使用 NoSQL (譬如 MongoDB),如果

  1. 想快速啟動小專案測試 idea 
  2. 資料格式不確定 (unstable schema),而未來很有可能調整
  3. 資料之間沒有複雜的關聯、或未來讀取資料時不需要使用 JOIN 的功能
  4. 著重在快速讀取資料與可用性,而非 ACID

可以考慮使用 RDBMS  (譬如 MySQL),如果

  1. 已經有明確的資料格式,未來不會大幅的變動
  2. 資料之間的關聯很重要
  3. 想要更有效率的讀取資料,未來會大量使用到 JOIN 的功能
  4. 更著重在資料操作的準確性與一致性 (ACID)

上述的情境主要是在個人專案上,如果實際在業界開發,還需要考量到

  1. 商業邏輯的設計
  2. 目前使用的系統(如何加入,需不需要做調整或轉移)
  3. 部署方式
  4. 成本計算
  5. 維護與營運考量
  6. 未來的擴充性

有這麼多需要考量的點,這也難怪當問你朋友「應該用 MySQL 還是用 MongoDB 好」的時候時,他只能回答「看情況囉」

結語

學習程式的路上,我們常常會看到許多不同的工具,但很多時候問題的重點不在於「哪個工具最好用」,而是「我們要解決什麼問題」。知道了目標,才知道手邊有哪些工具適合解決問題。而我們對工具瞭解越深,越能夠找到最合適解決問題的方式。

參考資料:

(本文作者是ALPHA Camp助教TD

3分鐘小測驗,找到自己的web開發學習入口

成為企業渴求的程式人才!

在家學會 JavaScript 網路開發

全新「全端 Web App 開發」課程,給你看得見的學習成效!
超過 90% 轉職成功,400 位來自亞洲各國的 ALPHA Camp 校友,畢業後達成轉職、創業、出國工作的夢想!

3 分鐘選課指南

給期待創新改變的你

前端x後端x全端 完整工程師技能樹

90% 學生轉職成功,職涯競爭力更上層樓
最專業的「全端 Web App 開發」課程,上班族邊工作也能同時培養第二專長!

3 分鐘選課指南

學期一|程式設計入門

零基礎也學得會的程式入門課!

開始學帶得走的技能,為自己未來的成長鋪路

學期二|掌握網頁開發

系統化學習 JavaScript

實作打好前後端基礎,成為扎實的網頁開發者

學期三|軟體工程師養成

養成業界接軌的實戰能力

前端/全端工程師專修路徑,完成技能與求職準備,成為業界即戰力