此篇為上完 Triton 的 RDBMS 淺談課程的筆記與心得
中小型系統用 RDBMS 已經足夠，原因包括如下
講者舉例，用了 amazon aurora mysql，莫名 CPU 飆升 100%，也找不到原因，因為這產品比較新，所以經驗和錯誤訊息絕對不會有 30 年的 MySQL 多，可能連 amazon 自己的人都找不到原因，最後解法就是搬回去 MySQL
然而 multiple records atomicity 是不能迴避的需求。
Example:
在一開始做系統的時候不必幻想超大流量的情況
先做，實現商業邏輯賺到錢之後在慢慢升上去，大部分商業無法容忍資料流失，你要 NoSQL 的快，會發現掉資料也快。
RDBMS 支援 10 進制的 numeric，計算錢的部分特別有用（多數商業邏輯都會碰到）
MongoDB 沒有像 MySQL 有相當精確的 decimal type 能使用，只能用 double - 8 bytes (64-bit IEEE 754 floating point) 去做儲存。
所以有可能發生 100+755.66 = 855.6599999999 的情況，可以的解法是在 application layer 處理。
原因：二進制無法精確表示小數，轉成十進制時就會變成這樣顯示了。
講者主觀認為，數據規模小於 100 GB，用 RDBMS 能解決大多數商業應用場景，基本上 JOIN + sub query 就足夠應付了。
在商業應用很容易出現報表需求，而 Database 通常都會內建這些工具 AVG、SUM、 COUNT 可以使用。
RDBMS 在寫入資料時，只要回你 OK 一定不流失資料，除非你 hard disk 有損壞。
很多 NoSQL 只是先寫到 memory 就回你 ok 了，如果這時候 power loss ，記憶體中的資料來不及寫進硬體，那就掰掰流失了
MongoDb 中有提供配置參數 write concern 來讓用戶自己衡量性能與安全的分配，所以其實預設的可能是不太可靠的，但要可靠的又會掉效能。
Production mode 連線進 database 請用 read only 來看，避免發生災難，如果要跑指令，請最好找另一個同事幫忙監督，避免無法挽回。
交易是不可分割的單元，就像原子一樣，要就全部執行，要不全部不執行
START TRANSACTION;
Update user_balance set balance = balance – amount where username = 'UserA';
Update user_balance set balance = balance + amount where username = 'UserB';
COMMIT;
不同人對 Consistency 定義不完全相同
資料在交易前後必須保持一致
A 有 300 元
B 有 500 元
A 轉帳 100 元給 B
無論 transaction 前後，兩個戶頭加起來就是 800 元
同一筆資料被改動時，確保不會被兩個 transaction 同時改動
所以在 transaction 未完成前，查詢數據應該是原本的狀態，而不是進行到一半的狀態。
很舊的 MySQL 在寫入時，是無法讀取數據的，會有等待的問題
避免 race condition 問題，lock table 無法避免，但 RDBMS 能自動處理
如果沒有 isolation，你要自己做 lock，可能會有一堆問題
假設你拿 Redis SETNX 來做
用 lock_name 當做 key 設一個 expire 時間，要是當機後重做，但 expire 已經過期怎麼辦。
結果就是以為概念很簡單，自己做沒問題，實際做起來很容易犯錯。
如果用 sleep 去處理，流量大就很容易動彈不得，這裡給一個關鍵字去處理
exponential back off jitter
commit 時如果系統發生錯誤，那麼在系統復原後要持續原本未完成的工作
底層行為是會寫入 redo log
mongoDB 並沒有真正等到寫入 hard disk 才返回 ok
Select XXX from A join B where A.xxx != B.xxx
Database 如何決定這個 query 到底要先拿 A 還是 B，會看 column statistics 去決定這次的 plan 那個更好
搜尋優化器會依照他過往的經驗來評比分數跟權重，決定要用什麼方式去找。
Rails 裡面可以用 explain 去查，如果是 postgres 還可以用 analyze + explain 找出真正的詳細計畫
假定要改動 Row X，這時查詢 Row X 是否存在 Main memory 內
這時候將 Main memory 的資料進行改動，並標記為 dirty 然後插入 redo log，直到放進 disk 後，將 memory 內的資料標記為 undirty 才完成。
所以說，如果 disk 還沒寫入時突然當機，重開後， database 會掃 redo log 並檢查有沒有還是標記為 dirty 的資料，然後重新執行或復原。
如果你的資料很常用於類似 message 從這個時間點倒退回去一百則訊息這種情景，用 MySQL 相當不錯，他可以有 Cluster index 處理。
不然的話 PostgreSQL 在底層的部分比 MySQL 更好更快。
這邊私心認為，PostgreSQL 的 partial index 很實用。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。