# Lesson 2: 資料儲存的抉擇：RDBMS vs NoSQL

### **關於RDBMS(關聯式資料庫)**

網路上有超多文章說明關聯式資料庫，簡單來說 關聯式資料庫就像是我們在Excel上面拉的表單，比如：會員資料表，我們在Excel上把對應的欄位標題(有點像前端的table-head , <th>)定義好，就是完成最基本的關聯式資料庫設計。每一筆資料就是一個row(就像是前端的table-data, <td>)，這就是資料表(table)。

最常見的RDBMS：MySQL 以及 PostgreSQL。

### **MySQL vs PostgreSQL**

在我身邊越來越多開發者，棄用MySQL轉投向PostgreSQL的懷抱，除了MySQL有許多莫名的坑以外(例如：5.7以上的版本，在subquery中的排序失效、Concat來連接字串的時候，如果其中一個值是 Null ，則最後的整個結果都會是 Null)，還是有真正大家跳槽的更大推力。

![](https://c10.patreonusercontent.com/4/patreon-media/p/post/144504569/1448180d19704f1dae440113ee202404/eyJhIjoxLCJ3Ijo4MjB9/1.png?token-hash=4Jzx8GZXk0qRCkoL1mnTEUUvRIV6piGA_HcMUlo65ww%3D&token-time=1766707200 align="left")

1. PostgreSQL 的一致性與 ACID 實作更強
    
2. 查詢規劃器能力差異太大
    
3. 資料型態與擴充能力遠勝 MySQL（尤其 JSONB 與地理資料）
    
4. DDL、鎖、複寫等在高併發場景下可信度更高
    

MySQL 能滿足 80% 傳統 CRUD 場景，但 PostgreSQL 能承載更複雜、更龐大的資料與查詢需求。

### **關於NoSQL(非關聯式資料庫)**

NoSQL 跟我們前面提到的關聯式資料庫（RDBMS）其實是兩種完全不同的思維。RDBMS 一定要先設好 Schema（欄位長怎樣、格式是什麼），然後所有資料都得乖乖照著這個規則走；但 NoSQL 就自由很多，最常見的資料存法就是用「鍵-值（Key-Value）」或 Document store 的方式來存。

NoSQL 最厲害的地方就在這裡：  
 它可以有 Schema，但它**不會強迫你所有資料都長一樣**。不像 RDBMS，一旦 Table 多了一個欄位，你資料庫裡所有的 row 都必須補上那個欄位（就算那筆資料根本不需要）。NoSQL 完全沒有這種強制規則，你要寫什麼就寫什麼，資料隨時想加欄位都沒問題，也不會影響舊的資料。

在Document store的資料結構的對照上，RDBMS 的 Table，就像 NoSQL 裡的 Collection；而 RDBMS 裡的一筆 Row，就對應到 NoSQL 裡的一個 Document。差別在於：  
 **同一個 Collection 裡的 Document 不需要長得一模一樣。**  
 有的文件可能多一個 address，有的可能少一個欄位，有的甚至多一個 metadata 都很正常，系統也不會抱怨。

這也是為什麼 NoSQL 很適合那些「需求一直變」、「資料格式不固定」、「開發節奏很快」的系統。像是 API 回傳資料、使用者設定、事件紀錄、各種 JSON payload 等等，用 NoSQL 都會比 RDBMS 來得自然。

簡單說，NoSQL 不是完全沒有 schema，而是採用 **「寫入不限制，讀取再解釋」** 的模式。這種彈性讓它在現代高變動的應用場景裡特別吃香。

**Key-Value Store：**

* **Redis**
    
* **Amazon DynamoDB**
    

Redis 通常用在快取服務，因為它的核心特性是「記憶體寫入」，速度極快。但這也代表如果系統重啟或 Redis 當掉，資料會全部消失，因此不適合作為主要的持久化資料庫。  
 為了解決這個問題，Redis 也提供兩種持久化方式：

1. **RDB**：在指定的時間點對記憶體中的資料進行快照（snapshot），並將這些資料以二進位格式的檔案（例如 dump.rdb）寫入硬碟。
    
2. **AOF**：記錄伺服器執行的所有寫入指令，在伺服器重啟時，會重新執行這些指令來還原資料。
    

這兩種方式可以單獨使用，也可以一起開啟，視需求取得速度與持久化的平衡。

**Document Store：**

* **MongoDB**（以 BSON 格式儲存文件資料，結構自由、彈性高）