該用 MySQL 或 MongoDB?

 https://tw.alphacamp.co/blog/mysql-and-mongodb-comparison


在「該用 MySQL,還是 MongoDB 呢?」

MySQL 與 MongoDB 這兩個資料庫管理系統 (Database Management System, DBMS) 背後的資料庫設計方式,也就是大家常聽到的關聯式資料庫 (Relational Database, RDB) 以及非關聯式資料庫 (NoSQL) 吧!

關聯式資料庫的特色

  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

  • Basically Available:保持服務基本可用
  • Soft State: 狀態可以有一段時間的不同步
  • Eventual consistency (最終一致性):雖然有一段時間不同步,但追求最後結果一致
  • 非關聯式資料庫(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 )
     

    MySQL or 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. 未來的擴充性

留言

這個網誌中的熱門文章

AI for everyone coursera

考績被打差了 輕率離職會更傷

(影片) Advanced Playwright - Test Automation University