Transaction Isolation 102: Isolation Level

1 tháng 1, 2021

18 phút đọc

Transaction Isolation 102: Isolation Level

Ở bài trước, chúng ta đã điểm mặt đặt tên những "kẻ phá hoại" kinh điển trong thế giới transaction: Dirty Write, Dirty Read, Lost Update, Write Skew và Read Skew. Vậy câu hỏi đặt ra là: Làm thế nào để chống lại chúng?

Câu trả lời nằm ở việc lựa chọn đúng mức độ Isolation (cô lập) cho transaction. Mỗi mức isolation cung cấp một lớp bảo vệ khác nhau, đi kèm với cái giá phải trả về hiệu năng và khả năng mở rộng.

Bản đồ các mức Isolation#

Về cơ bản, có 4 mức isolation chuẩn được định nghĩa, mỗi mức giải quyết được một nhóm vấn đề cụ thể:

Isolation Level	Dirty Write	Dirty Read	Read Skew	Lost Update	Write Skew	Phantoms
Read Uncommitted	✓	✘	✘	✘	✘	✘
Read Committed	✓	✓	✘	✘	✘	✘
Repeatable Read	✓	✓	✓	—	—	—
Serializable	✓	✓	✓	✓	✓	✓

Chú thích:

✓ = Không bị lỗi ở mức isolation này
✘ = Vẫn bị lỗi
— = Tùy trường hợp, phụ thuộc vào cách cơ sở dữ liệu cụ thể triển khai mức isolation này.

Tuy nhiên, đây chỉ là tiêu chuẩn lý thuyết. Thực tế, mỗi database lại có cách triển khai và đặt tên riêng, đôi khi gây nhầm lẫn không đáng có. Ví dụ điển hình:

OracleDB gọi Snapshot Isolation của họ là "Serializable", dù theo chuẩn nó mới chỉ đạt mức Repeatable Read.
SQL Server có tới tận 6 mức isolation khác nhau.
PostgreSQL thì dùng Snapshot Isolation cho mức Repeatable Read.

Nếu anh em muốn kiểm chứng chi tiết cách hoạt động của từng database, có thể tham khảo project thực nghiệm nổi tiếng Hermitage.

Giờ hãy cùng đi sâu vào từng mức độ, xem chúng hoạt động thế nào và tại sao lại có những ưu nhược điểm riêng.

Read Uncommitted – Mức Cơ Bản Nhất#

Đây là mức isolation nhẹ ký nhất. Nó đảm bảo được một điều tối thiểu: chống Dirty Write. Cơ chế rất đơn giản: transaction chỉ acquire khóa độc quyền (exclusive lock) khi thực hiện ghi, và giữ lock này cho đến khi commit hoặc rollback. Điều này đảm bảo trong một thời điểm, chỉ có một transaction được phép ghi vào một row dữ liệu.

Read Uncommitted có thật sự "tệ"?#

Câu trả lời là: Không hẳn.

Nếu biết dùng đúng chỗ, Read Uncommitted vẫn có giá trị. Trong các hệ thống lớn, việc ghi đúng thường quan trọng hơn đọc đúng. Một lỗi ghi có thể làm hỏng dữ liệu vĩnh viễn, trong khi đọc sai chỉ cần refresh lại hoặc fix code là xong. Read Uncommitted giúp tăng hiệu năng đọc lên rất nhiều vì không phải acquire lock khi đọc.

Tuy nhiên, cái giá phải trả là nguy cơ Dirty Read – đọc phải dữ liệu "dirty" chưa được commit. Vì vậy, câu hỏi đáng quan tâm hơn là:

"Hiệu năng của Read Uncommitted tốt hơn Read Committed bao nhiêu, và liệu có đáng để đánh đổi?"

https://sqlperformance.com/2015/04/t-sql-queries/the-read-uncommitted-isolation-level

Read Committed – Cân bằng giữa nhất quán và hiệu năng#

Read Committed là mức isolation mặc định của hầu hết các cơ sở dữ liệu (PostgreSQL, Oracle, SQL Server). Nó hứa hẹn hai điều: 1) Không Dirty Write và 2) Không Dirty Read. Có hai cách phổ biến để thực hiện lời hứa này.

2.1. Shared Lock#

Đây là cách tiếp cận cổ điển. Ta bổ sung thêm việc acquire khóa chia sẻ (shared lock) mỗi khi đọc một dòng dữ liệu.

Shared Lock cho phép nhiều transaction cùng đọc một dòng.
Khi có transaction muốn ghi (exclusive lock), nó phải chờ tất cả shared lock được release.
Shared lock sẽ được release ngay sau khi hoàn thành thao tác đọc.

Nhược điểm: Hiệu suất bị ảnh hưởng đáng kể vì mỗi lần đọc đều phải acquire lock. Nếu hệ thống có tỷ lệ đọc/ghi chênh lệch lớn (read-heavy), đây là một sự lãng phí.

2.2. Consistent Read#

Cách tiếp cận hiện đại hơn là sử dụng Multi-Version Concurrency Control (MVCC). Mỗi row dữ liệu không chỉ có một giá trị, mà được lưu nhiều phiên bản (version).

Khi transaction ghi, nó tạo một phiên bản mới của row đó.
Khi transaction đọc, nó chỉ nhìn thấy những phiên bản đã được commit tại thời điểm bắt đầu đọc.
Điều này cho phép các thao tác đọc chạy song song mà không cần khóa, trong khi thao tác ghi vẫn được serialize.

Ưu điểm: Hiệu năng đọc cực cao, không bị block bởi các transaction ghi.

Nhược điểm của Read Committed: Dù đã giải quyết được Dirty Read, nó vẫn bó tay trước các lỗi phức tạp hơn như Read Skew, Lost Update, Write Skew và Phantom Read.

Repeatable Read – Khắc phục "Read Skew"#

Mức này hứa hẹn thêm một điều: giải quyết Read Skew (Non-repeatable Read), đảm bảo trong cùng một transaction, nhiều lần đọc cùng một dữ liệu sẽ cho ra kết quả giống nhau. Cũng có hai trường phái chính.

1. Repeatable Read sử dụng Lock (Cổ điển)#

Phương pháp này nâng cấp từ Shared Lock của Read Committed, với điểm khác biệt chính:

Giữ lock đến hết transaction: Lock (cả shared lẫn exclusive) được giữ cho đến khi transaction kết thúc (commit/rollback), thay vì release ngay sau thao tác.
Lock mọi row đã đi qua: Khi quét dữ liệu (scan), nó sẽ khóa mọi row nó "chạm tới", kể cả những row không nằm trong kết quả cuối cùng. Nếu bảng không có index, nó có thể khóa nguyên cả bảng!
Upgrade lock: Nếu transaction đọc rồi sau đó muốn ghi lên cùng row đó, shared lock sẽ được nâng cấp lên exclusive lock. Quá trình này phải chờ tất cả các shared lock khác trên row đó được release.

"Sân chơi" của phương pháp này là những transaction chỉ thao tác trên một số row xác định trước (get by id, update by id), chứ không phải các truy vấn tìm kiếm phức tạp. Các ví dụ kinh điển của nó:

Read Skew#

Lost Update#

Write Skew#

Hạn chế lớn#

Không giải quyết được Phantom Read: Vì cơ chế lock theo từng row, scan tới đâu lock tới đó. Các row mới được insert vào giữa các row đã scan sẽ không bị khóa.
Hiệu năng: Các long-running transaction có thể block nhiều operation khác, gây chậm hệ thống và dễ dẫn đến deadlock.
Có khả năng bị Deadlock. Ví dụ với ảnh minh họa của bài toán Read Skew: đổi thứ tự giảm account 2 trước thay vì tăng account 1.

2. Snapshot Isolation – "Cứu tinh" cho Read-Only Transaction#

Đây là cách tiếp cận MVCC nâng cao, được dùng trong PostgreSQL (Repeatable Read) và Oracle (Serializable). Thay vì chỉ lưu 2 version (Read Committed), nó lưu toàn bộ lịch sử version của mỗi row.

Cách hoạt động:

Mỗi transaction được gán một Transaction ID (TXID) duy nhất khi bắt đầu, tăng dần theo thời gian.
Khi đọc, transaction chỉ nhìn thấy những phiên bản dữ liệu được commit trước khi nó bắt đầu (tức là version.txid < current_transaction.txid). Nó hoàn toàn bỏ qua các thay đổi xảy ra sau đó.
Khi ghi, nó tạo ra một phiên bản mới của row, đánh dấu bằng txid của nó.

Ưu điểm vượt trội:

Hiệu năng đọc cực cao: Không cần lock khi đọc, không bị block.
Giải quyết Read Skew và Phantom Read: Vì có một snapshot dữ liệu nhất quán tại một thời điểm.
Tránh deadlock cho các thao tác đọc.

Nhược điểm:

Tốn bộ nhớ: Phải lưu trữ nhiều version. Cần một cơ chế Garbage Collection (GC) để dọn dẹp các version cũ.
Không giải quyết được Lost Update & Write Skew: Đây là điểm yếu chí tử. Vì các transaction làm việc trên các snapshot độc lập, chúng có thể cùng ghi đè lên nhau dựa trên một trạng thái dữ liệu đã lỗi thời.
Phức tạp: Phải triển khai MVCC cho cả index đi kèm, không chỉ riêng dữ liệu.

Serializable – Mức mạnh nhất, Giá đắt nhất#

Đây là "chân ái" của isolation: đảm bảo kết quả thực thi song song nhiều transaction giống hệt như khi chúng chạy tuần tự (serial). Có 3 cách tiếp cận chính để đạt được điều này.

1. Actual Serial Execution (Thực thi tuần tự thật sự)#

Ý tưởng đơn giản nhất: chỉ dùng một luồng (single thread) để xử lý tất cả transaction. Một khi không có song song, thì làm gì có race condition?

Ưu điểm: Logic đơn giản, hiệu suất trên single-core rất cao, không cần lock phức tạp.
Nhược điểm: Không scale được. Mọi thứ bị bottleneck tại một điểm.

Tuy nhiên, với sự phát triển của phần cứng và mô hình lập trình sự kiện (event loop), ý tưởng này được hồi sinh. Redis là ví dụ điển hình nhất. Các database như VoltDB, H-Store cũng theo trường phái này. Chúng cực kỳ nhanh nhờ loại bỏ hoàn toàn chi phí lock và ngữ cảnh chuyển đổi (context switching).

Điều kiện để sử dụng:

Transaction phải nhỏ và nhanh.
Data thường được lưu trên RAM.
Có thể dùng partitioning để chia data ra nhiều core, nhưng transaction xuyên partition vẫn cần cơ chế phối hợp phức tạp.

2. Two-Phase Locking (2PL – Khóa Hai Pha)#

Chắc tới đây thì anh em cũng bắt đầu tò mò về câu hỏi: hơn 30 năm qua, các Database truyền thống đã dùng phương pháp gì? Câu trả lời chính là Two-Phase Locking. Nguyên tắc của 2PL rất nghiêm ngặt:

Phải acquire lock trước khi đọc/ghi bất kỳ hàng nào.
Chỉ được release lock sau khi transaction kết thúc (commit/rollback). Đây là điểm khác biệt then chốt so với Repeatable Read.
Lock có hai chế độ: Shared (cho đọc) và Exclusive (cho ghi).

Luật "vàng" của 2PL:

Nếu transaction A đã đọc một hàng, transaction B muốn ghi vào hàng đó phải đợi A kết thúc.
Nếu transaction A đã ghi vào một hàng, transaction B muốn đọc hàng đó cũng phải đợi A kết thúc.

Đấy là lý thuyết, khái quát thì không khác gì Repeatable Read, nhưng thực tế thì Database còn dùng row lock kết hợp với predicate lock hoặc index-range lock nữa.

Row-level lock#

Lock ở mức độ row giống như Repeated Read, không tránh được lỗi Phantoms. Cái này chỉ sử dụng cho những câu query get by id, hay write by id thôi.

Predicate Lock (Khóa vị từ)#

Khóa theo điều kiện (ví dụ: WHERE age > 10).

Ngay khi bắt gặp 1 câu lệnh mà không phải thuộc dạng get by id hay write by id, transaction sẽ sử dụng thêm Predicate lock (vẫn dùng cả Row lock, scan tới đâu thì acquire tới Row lock tương ứng ở đó).
Predicate lock cũng tồn tại 2 chế độ share mode và exclusive mode, nguyên lý tương tự như Row Lock.
Database sẽ lưu 1 danh sách các Predicate lock đang chưa được release.
Tất cả các Operation khác (dù chỉ get/write by id) đều phải duyệt qua cái danh sách Predicate lock kia trước khi tới bước acquire Row Lock. Mục đích để check xem row mà transaction định read/write nó có thỏa mãn predicate hay không. Nếu có thì phải tìm cách acquire Predicate lock được release đã thì mới được tiếp tục.

Cách này đã tránh được tình trạng Phantom Read, 100% serializable. Tuy nhiên, ta có thể thấy rằng việc phải check xem row có thỏa mãn predicate hay không rất là tốn thời gian.

Index-Range Lock (Khóa khoảng Index)#

Là tối ưu hóa của Predicate Lock.

Thay vì khóa logic, nó khóa một khoảng trên index (ví dụ: khóa tất cả truy cập tới index room_id có giá trị 123).

 SELECT * FROM bookings 
 WHERE room_id = 123 AND  end_time > '2018-01-01 12:00' AND  start_time < '2018-01-01 13:00';

Minh họa cho câu query trên, ta sẽ có 3 sự lựa chọn:

lock theo index room_id = 123
lock theo index end_time > '2018-01-01 12:00'
lock theo index start_time < '2018-01-01 13:00'

Ta chỉ cần sử dụng 1 trong 3 thôi, không cần phải lock cả 3 index lại. Như vậy vẫn đảm bảo lock được toàn bộ những row thỏa mãn predicate của câu query (mặc dù lock thừa nhiều bản ghi không cần thiết). Chọn lựa index nào để tối ưu lock thì đó lại là 1 câu chuyện khác, cái đó sẽ do optimizer của Database xử lý.

Cách này nhanh hơn nhưng có thể khóa "thừa" nhiều row không liên quan. Nếu cột trong điều kiện không có index, database sẽ phải khóa nguyên cả bảng.

Nhược điểm của 2PL#

Hiệu suất thấp, tỷ lệ deadlock cao, khả năng mở rộng kém. Nó thuộc nhóm Pessimistic Concurrency Control – luôn giả định xung đột sẽ xảy ra nên khóa từ đầu.

3. Serializable Snapshot Isolation (SSI) – Tương Lai Của Serializable#

Điểm qua lại những thứ ta đã tìm hiểu:

Snapshot Isolation: cho performance rất tốt, tuy nhiên lại bị gặp phải vấn đề với Lost Update, Write Skew, Phantoms,…
Actual serial execution: scale kém
Two-Phase Locking: performance kém

Hầu hết đều được cái này thì mất cái kia, tuy nhiên gần đây đã có nghiên cứu mới về 1 phương pháp có thể dung hòa được tất cả yếu tố bên trên. Thuật toán có tên là Serializable Snapshot Isolation (SSI), được đánh giá rất triển vọng để dung hòa giữa hiệu năng của Snapshot Isolation và tính nhất quán của Serializable, được ra mắt vào năm 2008 trong luận án tốt nghiệp tiến sĩ của Michael Cahill. SSI hiện đang được sử dụng trong PostgreSQL bắt đầu từ phiên bản 9.1.

SSI thuộc nhóm Optimistic Concurrency Control. Thay vì ngăn chặn xung đột ngay từ đầu bằng lock (pessimistic), nó cho phép mọi transaction chạy tự do, nhưng sẽ theo dõi và phát hiện (detect) các hành vi có thể vi phạm tính serializable. Nếu phát hiện vi phạm, nó sẽ hủy bỏ (abort) transaction đó và yêu cầu thử lại.

 SELECT COUNT(*) FROM staff 
 WHERE join_time < '2018-01-01 13:00';

 UPDATE staff SET revenue = revenue+500 
 WHERE join_time < '2018-01-01 13:00';

2 câu lệnh bên trên cùng tác động tới những row giống nhau nhưng kết quả thì không ảnh hưởng tới nhau. Nhóm Optimistic sẽ cứ để mọi thứ xảy ra, miễn là nó không ảnh hưởng tới transaction khác; transaction cứ việc thực thi, còn nó có được commit thành công hay không thì đấy lại là một chuyện khác!

Ưu điểm:

Hiệu năng đọc rất cao (kế thừa từ Snapshot Isolation).
Tránh được hầu hết deadlock.
Đảm bảo tính serializable thực sự.