RDBMS 課程心得與筆記

此篇為上完 Triton 的 RDBMS 淺談課程的筆記與心得

選擇 RDBMS 而非 NoSQL 的理由

中小型系統用 RDBMS 已經足夠，原因包括如下

歷史悠久，有 30 年的歷史，並有龐大的社群
error message 丟 stackoverflow 幾乎都有人遇過，有解法
有許多用在 production 的經驗，適合商業應用

講者舉例，用了 amazon aurora mysql，莫名 CPU 飆升 100%，也找不到原因，因為這產品比較新，所以經驗和錯誤訊息絕對不會有 30 年的 MySQL 多，可能連 amazon 自己的人都找不到原因，最後解法就是搬回去 MySQL

然而 multiple records atomicity 是不能迴避的需求。

Example:

把錢從用戶 A 轉到用戶 B
購買虛擬道具

Don’t overthinking

在一開始做系統的時候不必幻想超大流量的情況

Facebook 也是從 PHP + MySQL 起家
instagram 也是用 postgreSQL 起家

先做，實現商業邏輯賺到錢之後在慢慢升上去，大部分商業無法容忍資料流失，你要 NoSQL 的快，會發現掉資料也快。

Numeric 非常好用

RDBMS 支援 10 進制的 numeric，計算錢的部分特別有用（多數商業邏輯都會碰到）

MongoDB 沒有像 MySQL 有相當精確的 decimal type 能使用，只能用 double - 8 bytes (64-bit IEEE 754 floating point) 去做儲存。

所以有可能發生 100+755.66 = 855.6599999999 的情況，可以的解法是在 application layer 處理。

原因：二進制無法精確表示小數，轉成十進制時就會變成這樣顯示了。

參考：请问有人解决过mongo里的浮点型的精度问题么？

100 GB 分水嶺

講者主觀認為，數據規模小於 100 GB，用 RDBMS 能解決大多數商業應用場景，基本上 JOIN + sub query 就足夠應付了。

報表的優勢

在商業應用很容易出現報表需求，而 Database 通常都會內建這些工具 AVG、SUM、 COUNT 可以使用。

回應 OK 更可靠

RDBMS 在寫入資料時，只要回你 OK 一定不流失資料，除非你 hard disk 有損壞。

很多 NoSQL 只是先寫到 memory 就回你 ok 了，如果這時候 power loss ，記憶體中的資料來不及寫進硬體，那就掰掰流失了

MongoDb 中有提供配置參數 write concern 來讓用戶自己衡量性能與安全的分配，所以其實預設的可能是不太可靠的，但要可靠的又會掉效能。

連線操作 Database 需注意

Production mode 連線進 database 請用 read only 來看，避免發生災難，如果要跑指令，請最好找另一個同事幫忙監督，避免無法挽回。

ACID

Atomicity(原子性)

交易是不可分割的單元，就像原子一樣，要就全部執行，要不全部不執行

RDBMS 操作以 Transaction 為單位
Transaction 內可以包很多 SQL 指令
一包 Transaction 要馬失敗要馬成功，沒有改到一半 commit 的　（Atomicity requires that each transaction be “all or nothing”）
當機時，還沒被 commit 的 transaction 會被 rollback
有 transaction 機制做轉帳很容易
一般寫入時底層會像是偷偷幫你做一個很短的 transaction 來避免你掉資料

START TRANSACTION;
Update user_balance set balance = balance – amount where username = 'UserA';
Update user_balance set balance = balance + amount where username = 'UserB';
COMMIT;

NoSQL 沒有 transaction ，所以是拆步驟做，但如果中途當機，你很難修復。

Consistency(一致性)

不同人對 Consistency 定義不完全相同

資料在交易前後必須保持一致

A 有 300 元
B 有 500 元

A 轉帳 100 元給 B

A 戶頭 -100, 剩下 200
B 戶頭 +100, 變成 600

無論 transaction 前後，兩個戶頭加起來就是 800 元

Isolation (隔離性）

同一筆資料被改動時，確保不會被兩個 transaction 同時改動

所以在 transaction 未完成前，查詢數據應該是原本的狀態，而不是進行到一半的狀態。

很舊的 MySQL 在寫入時，是無法讀取數據的，會有等待的問題

避免 race condition 問題，lock table 無法避免，但 RDBMS 能自動處理

如果沒有 isolation，你要自己做 lock，可能會有一堆問題

假設你拿 Redis SETNX 來做

用 lock_name 當做　key 設一個 expire 時間，要是當機後重做，但 expire 已經過期怎麼辦。

結果就是以為概念很簡單，自己做沒問題，實際做起來很容易犯錯。

如果用 sleep 去處理，流量大就很容易動彈不得，這裡給一個關鍵字去處理

exponential back off jitter

Durability(持續性)

commit 時如果系統發生錯誤，那麼在系統復原後要持續原本未完成的工作

底層行為是會寫入 redo log

mongoDB 並沒有真正等到寫入 hard disk 才返回 ok

拿 table 如何決定順序

Select XXX from A join B where A.xxx != B.xxx

Database 如何決定這個 query 到底要先拿 A 還是 B，會看 column statistics 去決定這次的 plan 那個更好

搜尋優化器會依照他過往的經驗來評比分數跟權重，決定要用什麼方式去找。

Rails 裡面可以用 explain 去查，如果是 postgres 還可以用 analyze + explain 找出真正的詳細計畫

redo log 實際做了些什麼

假定要改動 Row X，這時查詢 Row X 是否存在 Main memory 內

如果有，直接使用
如果沒有，從 disk 拿出

這時候將 Main memory 的資料進行改動，並標記為 dirty 然後插入 redo log，直到放進 disk 後，將 memory 內的資料標記為 undirty 才完成。

所以說，如果 disk 還沒寫入時突然當機，重開後， database 會掃 redo log 並檢查有沒有還是標記為 dirty 的資料，然後重新執行或復原。

主流 Database 如何選擇

如果你的資料很常用於類似 message 從這個時間點倒退回去一百則訊息這種情景，用 MySQL 相當不錯，他可以有 Cluster index 處理。

不然的話 PostgreSQL 在底層的部分比 MySQL 更好更快。

這邊私心認為，PostgreSQL 的 partial index 很實用。

推荐订阅源

Nic Lin's Blog