Web 技術

是否該用 MongoDB？選擇資料庫前你該了解的事

發佈日期: 作者:

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

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

MongoDB

MongoDB 是一個開源 (open source) 的文件資料庫，為了因應大量投遞線上廣告與高速處理廣告數據的需求，在 2007 年由美國公司 10gen 所開發。MongoDB 是現階段使用者最多、生態系也最完整的文件資料庫。

正如其他技術工具，MongoDB 同時有自己的擅長與不便之處。在業界中，不同的公司、針對不同專案，經常會選擇使用不同的資料庫系統，甚至混合使用。

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

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

「我應該用 MySQL，還是用 MongoDB 好呢？」

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

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

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

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

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

關聯式資料庫的特色

  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 的資料庫設計。
‍

非關聯式資料庫（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資料庫，實作待辦清單應用程式

結語

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

—–

參考資料：

（本文作者是ALPHA Camp助教TD）

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

—-