續 Day 3

Snapshot Isolation 和 Repeatable read

先來看個 read committed 等級的隔離下會發生的靈異現象吧！如下圖的 Alice 在銀行各存了 500 元在兩個帳戶中，總額 1000 元，爾後有個 transaction 執行 100 元的轉帳作業，如果 Alice 在轉帳前查了 Account 1，而在轉帳結束後才去查了 Account 2， 會發現兩個帳戶的總金額為 900 元，100 元消失在空氣中了，比被通膨吃掉還慘。

這種異常情形稱 nonrepatable read 或 read skew，儘管 Alice 在查一次就正常了，但有些情況則不允許這種不一致發生：

• 備份 (Backup)

  備份作業通常需要整個資料庫的複製，如果在備份期間發生 read skew，若不幸要用該備份復原資料的話，Alice 的 100 元就真的消失了。

• 分析需求和資料檢查

  有時分析需求需要查大量的資料，或者資料需要定期做檢查（監測腐壞資料），這 2 種情形都會造成無意義且會浪費人力資料的結果。

快照隔離 (Snapshot Isolation) 一般是解決 read skew 問題的方式，其概念就是每一個 transaction 開始時，都是從一致 (consitent) 的快照中讀取資料，期間即使其他 transaction 已經修改資料了（已 commit），該 transaction 還是一樣會讀舊的資料，可以想像成資料就被凍結在 transaction 開始的時間點，它尤其適合用在長時間的 transaction 上。

實現快照隔離 (Snapshot Isolation)

就像實現 read committed 那般，避免 dirty write 的方式也是使用物件鎖，避免 dirty read 則不能使用任何鎖，我們首先要確保 寫入跟讀取不會互相影響，所以為了實現快照隔離，資料庫需要一個機制去保存不同版本的物件資料，因為多個 transaction 可能會在同個時間點看到多個快照的物件資料，該機制稱為 MVCC 多版本並發控制 (multi-version concurrent control)。

如果資料庫支援快照隔離，則前一小節講的 read committed 隔離就能一起使用 MVCC 實作了，差別只是 read committed 是在同個 transaction 下的每一次查詢都拿不同的快照，而快照隔離都是拿同一個快照而已。

下圖說明了以 MVCC 為基礎的快照隔離機制如何運作，當一個 transaction 開始時，資料庫會給定唯一的 txid (transaction ID)，每筆資料會多 2 個欄位，created_by 和 deleted_by，當資料寫入時，created_by 會記錄寫入的 txid ，而 deleted_by 初始是空值，當資料被刪除時，資料不會真的被刪掉，而是在 deleted_by 標記是哪個 txid 刪除，往後垃圾收集器會定期去清除無 transaction 在用且 deleted_by 有值的快照資料。

下圖的 txid 13 在更新 Account 1 的金額為 600 時，就會看到 500 那筆被標記被 tx id 13 刪除，然後同時建立一筆 created_by = 13 的資料，然後 txid 13 在更新 Account 2 的資料時亦同；txid 12 查詢時，因為 txid 13 是比較晚開始的 transaction，所以任何 txid 13 的寫入都會被忽略，所以 txid 12 只會查到符合一致性原則的快照資料。

一致性快照的可視化規則

簡單來說，一個物件要可視必須符合以下 2 個條件：

1. 當讀取者的 transaction 開始時，物件已被建立且已被其他 transaction commit。
2. 該物件未被標記成已刪除（圖 7-7 的例子為 deleted_by 有值），或者當讀取者的 transaction 開始時，物件已被標記刪但還沒 commit。

所以啦，若有個超長時間的 transaction 在執行，只要多付出一點點的 overhead，該 transaction 不用擔心 read skew 的問題。

作者的抱怨：快照隔離在 Oracle 稱為 Serializable ，而在 PostgreSQL 和 MySQL 稱為 repeatable read ，他認為 SQL 標準裡的隔離等級有瑕疵、曖昧不清且不精準的，所以一個名詞可以有很多不同的意思。

read skew 解決了，明天就要來談談 write skew 啦！