ACID A to Z

Xin chào các bạn, hôm nay chúng ta sẽ bàn về một trong những khái niệm cơ bản và quan trọng làm nền móng cho sự phát triển của các hệ thống quản lý cơ sở dữ liệu hiện nay là ACID.

Vì ACID là thuộc tính của transaction nên chúng ta cần hiểu khái niệm transaction là gì trước.

## Transaction

• Một transaction đề cập đến một đơn vị logic của công việc bao gồm một hoặc nhiều hoạt động của database.

*⇒ Như vậy, chúng ta có thể coi một transaction là một tập hợp các câu query trong database.*

💡 Chúng ta có ví dụ của một transaction trong lĩnh vực tài chính:

• Chuyển $100 từ Account 1 tới Account 2.
• Transaction này bao gồm các hoạt động của database như sau:

1. Tạo một record để chuyển 100 từ tài khoản A tới tài khoản B. Đây thường được coi là **BEGIN** của transaction.
2. Đọc số dư của tài khoản 1.
3. Nếu số dư của tài khoản 1 ≥ 100, trừ tài khoản 1 đi 100.
4. Đọc số dư của tài khoản 2.
5. Cộng 100 vào số dư của tài khoản 2.
6. Nếu mọi thứ thành công, transaction sẽ được **COMMIT** để đánh dấu sự thay đổi trong database là vĩnh viễn. Nếu có lỗi xảy ra thì transaction sẽ được **ROLLBACK**, tức mọi thay đổi sẽ trở về trạng thái ban đầu.

## ACID là gì?

• Năm 1983, hai giáo sư Khoa học máy tính là [Theo Härder](https://ieeexplore.ieee.org/author/37378537600) (Theo Har-der) và [Andreas Reuter](https://www.researchgate.net/profile/Andreas-Reuter-7) (An-drei-as Rao-tờ) đã xuất bản một bài báo chuyên đề có tiêu đề [Principles of transaction-oriented database recovery (Nguyên tắc phục hồi cơ sở dữ liệu hướng giao dịch)](https://dl.acm.org/doi/10.1145/289.291) trên tạp chí Khảo sát điện toán [ACM](https://dl.acm.org/). Bài báo này phác thảo các nguyên tắc cơ bản đảm bảo xử lý giao dịch đáng tin cậy trong các hệ thống cơ sở dữ liệu, sau này được gọi là các thuộc tính ACID.
• ACID là một bộ các thuộc tính của transaction trong hệ quản trị cơ sở dữ liệu nhằm đảm bảo tính hợp lệ của dữ liệu trong trường hợp có lỗi, mất điện và các rủi ro khác.

## Tính chất của ACID (ACID properties)

• ACID bao gồm bộ 4 thuộc tính, viết tắt tương ứng với các chữ cái
  — A (Atomicity — Tính nguyên tử),
  — C (Consistency — Tính nhất quán),
  — I (Isolation — Tính cô lập),
  — D (Durability — Tính bền vững).

### Atomicity (A)

• **Atomicity** (Tính nguyên tử) có tính không thể phân chia và không thể rút gọn, sao cho tất cả các bước đều xảy ra hoặc là không gì xảy ra.
  
  > **Atomicity** is an indivisible and irreducible series of database operations such that *either all occurs, or nothing occurs*. — [Wikipedia](https://en.wikipedia.org/wiki/Atomicity_(database_systems))
• Nếu có một transaction bị lỗi thì transaction đó sẽ được rollback, dữ liệu sẽ không thay đổi, còn nếu ko xảy ra lỗi thì transaction sẽ được commit, dữ liệu trong database sẽ được cập nhật thành công.

💡 Chúng ta có ví dụ sau: Chuyển $100 từ Account 1 sang Account 2

• Trường hợp tuân thủ Atomicity (Tính nguyên tử)

Ví dụ tuân thủ Tính nguyên tử (Atomicity)

• Trường hợp không tuân thủ Atomicity (Tính nguyên tử): Số balance của Account 1 thay đổi nhưng số balance của Account 2 vẫn giữ nguyên.

Ví dụ không tuân thủ tính chất nguyên tử (Atomicity)

### Consistency

• **Consistency** (Tính nhất quán) yêu cầu rằng [giao dịch cơ sở dữ liệu](https://vi.wikipedia.org/wiki/Giao_d%E1%BB%8nch_c%C6%A1_s%E1%BB%9F_d%E1%BB%AF_li%E1%BB%87u) đã cho bất kỳ chỉ có thể thay đổi dữ liệu theo những cách được cho phép.
  
  > **Consistency** (or **correctness**) refers to the requirement that any given [database transaction](https://en.wikipedia.org/wiki/Database_transaction) must change affected data only in allowed ways. Any data written to the database must be valid according to all defined rules, including [constraints](https://en.wikipedia.org/wiki/Integrity_constraints), [cascades](https://en.wikipedia.org/wiki/Cascading_rollback), [triggers](https://en.wikipedia.org/wiki/Database_trigger), and any combination thereof. — [Wikipedia](https://en.wikipedia.org/wiki/Consistency_(database_systems))
• Sau khi ghi, sửa hoặc xóa bản ghi thành công, yêu cầu đọc bất kỳ sẽ ngay lập tức nhận được giá trị mới nhất của bản ghi đấy.

💡 Ví dụ
— Bạn có 2 bảng `customers` và `accounts`. Bảng `customers` có khoá ngoài `acount_id` trỏ tới `id` của bảng `accounts` như hình.
— `accounts` không có record với `id` = 3 nhưng bảng customers lại có 1 record có `account_id` = 3. ⇒ Điều này vi phạm tính nhất quán.


### Isolation (I)

• **Isolation** (Tính cô lập) đảm bảo các transaction được thực thi một cách độc lập, không phụ thuộc lẫn nhau.
  
  > **Isolation**: Events within a transaction must be hidden from other transactions running concurrently. — Trích [Principles of transaction-oriented database recovery (Nguyên tắc phục hồi cơ sở dữ liệu hướng giao dịch)](https://dl.acm.org/doi/10.1145/289.291)
• Trong tính chất Isolation, chúng ta có hai khái niệm quan trọng là
  — **Read phenomena** (Hiện tượng đọc)
  — **Isolation levels** (Cấp độ cô lập)

#### Read phenomena

• **Read phenomena** (Hiện tượng đọc) là tất cả những lỗi có thể xuất hiện khi nhiều người đọc và ghi vào cùng một dòng.
• Chúng ta có 3 loại lỗi khi đọc phổ biến
  — **Dirty reads**: lỗi khi đọc những thay đổi chưa được commit.

Ví dụ về Dirty reads

— **Non — repeatable reads**: lỗi khi đọc thay đổi đã được commit

Ví dụ về Non — repeatable reads

— **Phantom reads**: lỗi khi có dòng mới thêm vào bảng

Ví dụ về Phantom reads

#### Isolation levels

• **Isolation levels** (Cấp độ cô lập) chỉ các cấp độ cô lập trong một transaction nhằm khắc phục hiện tượng đọc gây lỗi (Read phenomena).
• Chúng ta có 4 cấp độ cô lập xếp theo thứ tự mức cô lập cao nhất tới thấp nhất. Mức cô lập càng cao thì hiệu năng lại càng giảm.
  — **Serializable**: Các transaction thực hiện theo thứ tự. Đây là cấp độ cô lập cao nhất.
  — **Repeatable read**: Mỗi query trong 1 transaction chỉ nhìn thấy các thay đổi đã commit khi bắt đầu transaction.
  — **Read committed**: Mỗi query trong 1 transaction chỉ nhìn thấy các thay đổi đã commit.
  — **Read uncommitted**: Không có cô lập. Đây là cấp độ cô lập thấp nhất.

Isolation levels

• Mỗi tương quan giữa Hiện tượng đọc (Read phenomenas) ở các cấp độ cô lập (Isolation levels)
  — Mức cô lập càng cao thì các lỗi đọc (Read phenomena) càng ít xảy ra hơn.
  — Ở mức độ cô lập cao nhất — Serializable, chúng ta không thấy xuất hiện một lỗi đọc nào. Ngược lại, ở mức độ cô lập thấp nhất — Read uncommitted, ta thấy xuất hiện tất cả các lỗi đọc.

Bảng mối tương quan giữa những lỗi đọc có thể xảy ra ở các cấp độ cô lập.

• Mức cô lập mặc định ở các DBMS (Database Management System — Hệ thống quản lý cơ sở dữ liệu)
  — Ở [Postgres 15 là Read committed](https://www.postgresql.org/docs/current/transaction-iso.html).
  — Ở [MySQL 8 là Repeatable read](https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html).
  
  *⇒ Như vậy, ta có thể kết luận Postgres 15 chạy nhanh hơn MySQL 8 vì có mức độ cô lập thấp hơn.*

### Durability (D)

- **Durability** (Tính bền vững) đảm bảo rằng những transaction đã commit sẽ tồn tại mãi mãi.

> **Durability:** Once a transaction has been completed and has committed its results to the database, the system must guarantee that these results survive any subsequent malfunctions. — Trích [Principles of transaction-oriented database recovery (Nguyên tắc phục hồi cơ sở dữ liệu hướng giao dịch)](https://dl.acm.org/doi/10.1145/289.291)

💡 Ví dụ: nếu hệ thống đặt vé máy bay báo rằng đã đặt chỗ thành công thì chỗ ngồi đấy sẽ giữ nguyên trạng thái được đặt, ngay cả khi hệ thống bị crash.

- Tính bền vững có thể đạt được bằng cách chuyển bản ghi của giao dịch vào [bộ nhớ điện tĩnh](https://vi.wikipedia.org/wiki/B%E1%BB%99_nh%E1%BB%9B_%C4%91i%E1%BB%87n_t%C4%A9nh) trước khi database ghi nhận commit.

## Tóm tắt

- Transaction là một tập hợp các câu query.

- ACID là thuộc tính của transaction, bao gồm tính nguyên tử (**Atomicity**), tính nhất quán (**Consistency**), tính cô lập (**Isolation**) và tính bền vững (**Durability**).

- Có 3 hiện tượng đọc (Read phenomenon) gây lỗi phổ biến trong database là **Dirty reads** (đọc thay đổi chưa commit), **Repeatable reads** (đọc thay đổi đã commit) và **Phantom reads** (đọc thay đổi khi có dòng mới thêm vào database).

- Để khắc phục hiện tượng đọc (Read phenomenon) gây lỗi, chúng ta có 4 mức độ cô lập khác nhau theo thứ tự từ cao tới thấp. Mức cô lập càng cao thì hiệu suất của đatabase càng giảm.
— **Serializable**: Các transaction thực hiện theo thứ tự. Đây là cấp độ cô lập cao nhất.
— **Repeatable read**: Mỗi query trong 1 transaction chỉ nhìn thấy các thay đổi đã commit trước đó cho tới thời điểm BEGIN (bắt đầu) của transaction.
— **Read committed**: Mỗi query trong 1 transaction chỉ nhìn thấy các thay đổi đã commit.
— **Read uncommitted**: Không có cô lập. Đây là cấp độ cô lập thấp nhất.

## References

1. [Principles of transaction-oriented database recovery | ACM Computing Surveys](https://dl.acm.org/doi/10.1145/289.291)
2. [A Critique of ANSI SQL Isolation Levels](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf)
3. [Understanding isolation levels — JDBC Driver for SQL Server | Microsoft Learn](https://learn.microsoft.com/en-us/sql/connect/jdbc/understanding-isolation-levels?view=sql-server-ver16)
4. [Isolation levels](https://www.ibm.com/docs/en/db2/11.5?topic=issues-isolation-levels)
5. [Oracle Live SQL — Tutorial: Read Phenomena & Isolation Levels: Databases for Developers](https://livesql.oracle.com/apex/livesql/file/tutorial_GXA9ZDN9ODAIUOHO5LRWCPPQT.html)