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)，還是有真正大家跳槽的更大推力。
PostgreSQL 的一致性與 ACID 實作更強
查詢規劃器能力差異太大
資料型態與擴充能力遠勝 MySQL（尤其 JSONB 與地理資料）
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 也提供兩種持久化方式：
RDB：在指定的時間點對記憶體中的資料進行快照（snapshot），並將這些資料以二進位格式的檔案（例如 dump.rdb）寫入硬碟。
AOF：記錄伺服器執行的所有寫入指令，在伺服器重啟時，會重新執行這些指令來還原資料。
這兩種方式可以單獨使用，也可以一起開啟，視需求取得速度與持久化的平衡。
Document Store：
- MongoDB（以 BSON 格式儲存文件資料，結構自由、彈性高）