Database Isolation Level – Các mức cô lập transaction

1. Isolation Level là gì?

Isolation Level (mức cô lập giao dịch) là mức độ kiểm soát việc một transaction nhìn thấy những thay đổi của transaction khác khi nhiều transaction chạy đồng thời trên database.

Isolation là chữ I trong ACID. Mục tiêu của nó là hạn chế những kết quả không nhất quán khi nhiều request cùng đọc hoặc ghi dữ liệu.

Ví dụ, tài khoản A có số dư 1.000.000 đồng. Trong lúc request 1 đang chuyển tiền, request 2 cũng đọc và cập nhật số dư của tài khoản đó. Database cần có cơ chế xác định mỗi transaction được nhìn thấy dữ liệu ở trạng thái nào, thay đổi nào đã được xác nhận và cách xử lý khi hai transaction xung đột.

2. Ba vấn đề quan trọng khi nhiều transaction chạy đồng thời

Muốn hiểu Isolation Level, trước hết cần nắm ba hiện tượng phổ biến: Dirty Read, Non-repeatable Read và Phantom Read.

Dirty Read – Đọc dữ liệu chưa commit

Dirty Read xảy ra khi một transaction đọc được thay đổi mà transaction khác chưa commit.

Giả sử số dư ban đầu của tài khoản là 1.000.000 đồng.

Transaction A thực hiện:

BEGIN;

UPDATE accounts
SET balance = 500000
WHERE id = 1;

-- Chưa COMMIT

Trong lúc đó, transaction B đọc:

SELECT balance
FROM accounts
WHERE id = 1;

Nếu B nhìn thấy số dư 500.000 đồng trong khi A chưa commit, B đã đọc dữ liệu chưa được xác nhận. Nếu A sau đó rollback, giá trị mà B đọc được chưa từng trở thành trạng thái đã commit của database.

Đây là Dirty Read.

Phantom Read – Xuất hiện hoặc biến mất bản ghi khi truy vấn lại

Phantom Read xảy ra khi transaction thực hiện lại một truy vấn theo điều kiện và nhận được tập bản ghi khác do transaction khác đã commit thay đổi phù hợp với điều kiện đó.

Ví dụ, transaction A truy vấn:

SELECT *
FROM orders
WHERE status = 'pending';

Kết quả lần đầu có 10 đơn hàng.

Trong lúc đó, transaction B tạo một đơn hàng mới có status = 'pending' rồi commit. Khi A thực hiện lại truy vấn, kết quả có thể có 11 đơn hàng.

Bản ghi mới phù hợp với điều kiện truy vấn chính là một phantom row.

Phantom Read khác Non-repeatable Read ở điểm trọng tâm:

• Non-repeatable Read: giá trị của một bản ghi đã đọc thay đổi.
• Phantom Read: tập hợp bản ghi thỏa mãn điều kiện truy vấn thay đổi.

3. Bốn Isolation Level

READ UNCOMMITTED

READ UNCOMMITTED là mức cô lập thấp nhất trong bốn mức theo SQL standard.

Ở mức này, transaction có thể đọc những thay đổi chưa commit của transaction khác, nên Dirty Read có thể xảy ra. Non-repeatable Read và Phantom Read cũng có thể xảy ra.

Ví dụ:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

BEGIN;

SELECT balance
FROM accounts
WHERE id = 1;

COMMIT;

Câu lệnh trên minh họa cách thiết lập mức cô lập; cú pháp và thời điểm thiết lập cần tuân theo database đang sử dụng.

Ưu điểm: giảm một số yêu cầu về tính cô lập, có thể hữu ích trong những trường hợp đặc biệt mà dữ liệu chỉ mang tính tham khảo và độ chính xác tức thời không quan trọng.

Nhược điểm: application có thể đọc dữ liệu chưa commit và đưa ra quyết định sai.

READ COMMITTED

• READ COMMITTED bảo đảm mỗi câu truy vấn thông thường chỉ nhìn thấy dữ liệu đã commit trước thời điểm câu truy vấn bắt đầu.Ví dụ:

  BEGIN;
  
  SELECT balance
  FROM accounts
  WHERE id = 1;
  
  SELECT balance
  FROM accounts
  WHERE id = 1;
  
  COMMIT;

  Hai câu SELECT có thể trả về hai giá trị khác nhau nếu transaction khác cập nhật và commit dữ liệu giữa hai lần đọc. Hai câu SELECT có thể trả về hai giá trị khác nhau nếu transaction khác cập nhật và commit dữ liệu giữa hai lần đọc. Vì vậy, READ COMMITTED ngăn Dirty Read nhưng vẫn cho phép Non-repeatable Read và Phantom Read theo mô hình SQL standard.

REPEATABLE READ

REPEATABLE READ cung cấp bảo đảm mạnh hơn về việc đọc lại dữ liệu trong cùng transaction. Theo SQL standard, khi một transaction đã đọc một bản ghi, những lần đọc lại không được xuất hiện Non-repeatable Read. SQL standard cho phép Phantom Read ở mức này, nhưng cách triển khai thực tế phụ thuộc database.

Ví dụ:

BEGIN;

SELECT balance
FROM accounts
WHERE id = 1;

-- Transaction khác cập nhật và COMMIT.

SELECT balance
FROM accounts
WHERE id = 1;

COMMIT;

Với một transaction sử dụng REPEATABLE READ, hai lần đọc thông thường sẽ thấy cùng một giá trị trong những điều kiện được bảo đảm bởi database, thay vì lần đọc sau tự động nhìn thấy mọi thay đổi mới đã commit.

SERIALIZABLE

SERIALIZABLE là mức cô lập nghiêm ngặt nhất trong bốn mức thông dụng.

Mục tiêu là bảo đảm kết quả của những transaction đã commit tương đương với một thứ tự thực thi tuần tự hợp lệ, như thể các transaction được chạy lần lượt thay vì đồng thời.

Ví dụ, một hệ thống có quy tắc rằng tổng số nhân viên trực ca không được thấp hơn hai người. Hai request đồng thời kiểm tra số người đang trực rồi quyết định cho hai nhân viên nghỉ. Mỗi request riêng lẻ có thể thấy đủ người, nhưng nếu cả hai cùng thành công, quy tắc tổng thể có thể bị vi phạm.

Đây là dạng vấn đề mà chỉ đọc từng bản ghi ổn định chưa chắc đã giải quyết được. SERIALIZABLE có thể phát hiện và ngăn những lịch thực thi dẫn đến kết quả không thể tương đương với một thứ tự tuần tự hợp lệ.

Ưu điểm:

• Cung cấp bảo đảm mạnh nhất về tính đúng đắn của kết quả khi chạy đồng thời.
• Phù hợp với nghiệp vụ có quy tắc toàn cục phức tạp mà các mức thấp hơn khó bảo vệ bằng những thao tác đơn giản.

Nhược điểm:

• Có thể phát sinh nhiều lỗi serialization cần retry.
• Có thêm chi phí kiểm soát xung đột.
• Application phải được thiết kế để xử lý transactIsolation Level quyết định mức độ cô lập giữa các transaction chạy đồng thời. Bốn mức thông dụng là READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ và SERIALIZABLE.

  Ba hiện tượng cơ bản cần hiểu là Dirty Read, Non-repeatable Read và Phantom Read. Ngoài ra, cần biết serialization anomaly để hiểu vì sao một transaction vẫn có thể gặp vấn đề concurrency ngay cả khi dữ liệu đọc được ổn định.

  ion thất bại an toàn.

4. Tổng kết

Isolation Level quyết định mức độ cô lập giữa các transaction chạy đồng thời. Bốn mức thông dụng là READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ và SERIALIZABLE.

Ba hiện tượng cơ bản cần hiểu là Dirty Read, Non-repeatable Read và Phantom Read. Ngoài ra, cần biết serialization anomaly để hiểu vì sao một transaction vẫn có thể gặp vấn đề concurrency ngay cả khi dữ liệu đọc được ổn định.

Thuận Đức

Xem tất cả bài viết của tác giả

Bài viết khác

Isolation Level

Isolation Level là gì? Các mức độ cô lập trong Database Trong một ứng dụng Backend, nhiều request có thể truy cập và thay đổi dữ liệu trong database cùng một thời điểm. Khi nhiều transaction chạy đồng thời, kết quả của một transaction có thể bị ảnh hưởng bởi những thao tác của transaction […]

Đọc thêm

Boundary Value Analysis(Phân tích giá trị biên)

1.Boundary Value Analysis là gì? Trong quá trình xây dựng và phát triển phần mềm, mặc dù đội ngũ lập trình viên luôn cố gắng viết mã nguồn thật chuẩn xác, nhưng thực tế kiểm thử từ nhiều thập kỷ qua đã đúc kết một quy luật kinh điển: Phần lớn các lỗi logic (logic […]

Đọc thêm

Saga Pattern – Quản lý Distributed Transactions

1. Saga Pattern là gì? Saga Pattern là một mẫu thiết kế dùng để quản lý một nghiệp vụ lớn trải qua nhiều service hoặc database độc lập. các nghiệp vụ được chia thành nhiều local transaction. mỗi transaction cập nhật nghiệp vụ của một service của nó. nếu một bước thất bại, hệ thống […]

Đọc thêm

Two-Phase Locking (2PL) – Cơ chế khóa hai pha trong Database

1. Two-Phase Locking là gì? Two-Phase Locking (2PL – khóa hai pha) là một giao thức kiểm soát đồng thời (concurrency control protocol) trong database. Giao thức này quy định cách một transaction lấy và giải phóng lock nhằm đảm bảo các transaction chạy đồng thời tạo ra kết quả tương đương với một thứ […]

Đọc thêm

Series 4 – React Rendering :Component Lifecycle, Rendering và Re-rendering Virtual DOM, Reconciliation và DOM

Series 4 – React Hooks – State   Bài 1 :Component Lifecycle, Rendering và Re-rendering – React cập nhật giao diện như thế nào? 1. Mở đầu Khi xây dựng ứng dụng React, một câu hỏi quan trọng là: điều gì xảy ra khi state thay đổi? Vì sao một component được hiển thị lần […]

Đọc thêm

locking & dead lock (Transaction)

1. Locking là gì? Locking (cơ chế khóa) là cơ chế database sử dụng để kiểm soát việc nhiều transaction cùng truy cập hoặc thay đổi dữ liệu, nhằm tránh những xung đột có thể làm sai lệch kết quả. Trong một ứng dụng có nhiều user, nhiều request có thể đồng thời thao tác […]

Đọc thêm