Hiểu về ACID trong Database

ACID là một tập hợp các tính chất quan trọng trong cơ sở dữ liệu, đảm bảo tính toàn vẹn và độ tin cậy của dữ liệu trong các giao dịch (transactions). Thuật ngữ ACID là viết tắt của bốn tính chất cơ bản:

• Atomicity (Tính nguyên tử)
• Consistency (Tính nhất quán)
• Isolation (Tính cô lập)
• Durability (Tính bền vững)

1. Atomicity (Tính nguyên tử)

Tính nguyên tử đảm bảo rằng một giao dịch được xử lý như một đơn vị không thể tách rời. Nếu một phần của giao dịch thất bại, toàn bộ giao dịch sẽ bị hủy bỏ (rollback) và cơ sở dữ liệu trở về trạng thái trước khi giao dịch bắt đầu.

• Định nghĩa: Một giao dịch là một đơn vị không thể chia nhỏ. Nó hoặc được thực hiện hoàn toàn, hoặc không thực hiện gì cả.
• Ý nghĩa: Nếu trong quá trình thực hiện giao dịch có lỗi xảy ra, tất cả các thay đổi được thực hiện trước đó sẽ bị hoàn tác (rollback).
• Ví dụ: Chuyển tiền từ tài khoản A sang B:
  • Trừ tiền tài khoản A
  • Cộng tiền tài khoản B → Nếu một trong hai bước thất bại, toàn bộ giao dịch sẽ bị hủy.

Ví dụ về Atomicity:

BEGIN TRANSACTION;
    UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
    UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;
COMMIT;

Trong ví dụ này, nếu một trong hai lệnh UPDATE thất bại, toàn bộ giao dịch sẽ bị hủy bỏ, đảm bảo số dư tài khoản không bị mất hoặc không được cập nhật một phần.

Ví dụ chi tiết về giao dịch thất bại:

-- Giả sử chúng ta có bảng accounts với dữ liệu ban đầu:
-- account_id | balance
-- 1         | 1000
-- 2         | 500

BEGIN TRANSACTION;
    -- Bước 1: Trừ tiền từ tài khoản 1
    UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
    -- Sau bước này, tài khoản 1 còn 900

    -- Bước 2: Cộng tiền vào tài khoản 2
    -- Giả sử có lỗi xảy ra ở đây (ví dụ: tài khoản 2 không tồn tại)
    UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;
    -- Lệnh này thất bại vì tài khoản 2 không tồn tại

    -- Do có lỗi, giao dịch sẽ tự động rollback
    -- Tài khoản 1 sẽ trở về số dư ban đầu là 1000
ROLLBACK; -- Lệnh này được thực hiện tự động khi có lỗi

-- Kiểm tra số dư sau khi rollback
SELECT * FROM accounts;
-- Kết quả:
-- account_id | balance
-- 1         | 1000    -- Đã trở về số dư ban đầu

Trong ví dụ trên:

1. Giao dịch bắt đầu với việc trừ 100 từ tài khoản 1
2. Khi cố gắng cộng 100 vào tài khoản 2, lệnh thất bại
3. Hệ thống tự động rollback toàn bộ giao dịch
4. Số dư tài khoản 1 trở về 1000 như ban đầu
5. Không có thay đổi nào được lưu vào cơ sở dữ liệu

Điều này đảm bảo tính nguyên tử của giao dịch - hoặc là tất cả các thao tác đều thành công, hoặc là không có thao tác nào được thực hiện.

2. Consistency (Tính nhất quán)

Tính nhất quán đảm bảo rằng cơ sở dữ liệu luôn ở trạng thái hợp lệ trước và sau mỗi giao dịch. Các ràng buộc (constraints), khóa ngoại (foreign keys), và các quy tắc nghiệp vụ phải được tuân thủ.

• Định nghĩa: Sau khi một giao dịch hoàn tất, dữ liệu phải được chuyển từ một trạng thái nhất quán này sang trạng thái nhất quán khác.
• Ý nghĩa: Giao dịch phải tuân thủ tất cả các ràng buộc, quy tắc và quy luật của cơ sở dữ liệu (như khóa chính, khóa ngoại, unique...).
• Ví dụ:
  • Không thể thêm một bản ghi đơn hàng mà không có khách hàng tương ứng trong bảng khách hàng (do ràng buộc khóa ngoại)
  • Total_amount phải là số dương
  • Các trường bắt buộc không được NULL

Ví dụ về Consistency:

Tình huống: Bạn có một bảng orders với ràng buộc khóa ngoại customer_id tham chiếu đến bảng customers.

CREATE TABLE customers (
  id INT PRIMARY KEY,
  name VARCHAR(100)
);

CREATE TABLE orders (
  id INT PRIMARY KEY,
  customer_id INT,
  total_amount DECIMAL(10,2),
  FOREIGN KEY (customer_id) REFERENCES customers(id)
);

Giao dịch không hợp lệ (vi phạm tính nhất quán):

START TRANSACTION;
INSERT INTO orders (id, customer_id, total_amount) VALUES (1, 999, -999); -- không tồn tại customer_id = 999
COMMIT;

❌ MySQL sẽ từ chối giao dịch này vì vi phạm ràng buộc khóa ngoại → Consistency được bảo vệ.

Khi thêm một đơn hàng mới, hệ thống sẽ kiểm tra:

• Customer_id phải tồn tại trong bảng customers
• Total_amount phải là số dương
• Các trường bắt buộc không được NULL

3. Isolation (Tính cô lập)

Tính cô lập đảm bảo rằng các giao dịch đồng thời không ảnh hưởng lẫn nhau. Mỗi giao dịch được thực hiện như thể nó là giao dịch duy nhất đang chạy trong hệ thống.

• Định nghĩa: Các giao dịch phải thực thi độc lập, không bị ảnh hưởng bởi các giao dịch khác đang thực hiện cùng lúc.
• Ý nghĩa: Giúp ngăn tình trạng "dirty read", "non-repeatable read", "phantom read".
• Ví dụ: Nếu 2 người đang đặt vé cùng lúc, hệ thống phải xử lý sao cho mỗi người đều thấy đúng số lượng vé còn lại, tránh tình trạng bị trùng hoặc sai lệch.

Các cấp độ cô lập trong MySQL:

1. READ UNCOMMITTED: Cho phép đọc dữ liệu chưa được commit (dirty read)
2. READ COMMITTED: Chỉ cho phép đọc dữ liệu đã được commit
3. REPEATABLE READ: Đảm bảo đọc lặp lại cho cùng một dữ liệu (mặc định trong MySQL)
4. SERIALIZABLE: Cô lập hoàn toàn, các giao dịch được thực hiện tuần tự

Ví dụ về Isolation:

Tình huống: Có 2 người dùng thực hiện giao dịch cùng lúc trên cùng dữ liệu. Dùng 2 phiên (Sessions) để minh họa.

-- Transaction 1
BEGIN;
SELECT balance FROM accounts WHERE account_id = 1; -- Đọc 1000
-- Hiện số dư là 1000
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;

-- Transaction 2
BEGIN;
SELECT balance FROM accounts WHERE account_id = 1; -- Vẫn đọc 1000 (REPEATABLE READ)

✅ Isolation đảm bảo mỗi giao dịch không thấy thay đổi từ giao dịch khác cho đến khi nó commit.

👉 Có thể kiểm soát mức độ cô lập bằng:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

4. Durability (Tính bền vững)

Tính bền vững đảm bảo rằng một khi giao dịch đã được commit, các thay đổi sẽ được lưu trữ vĩnh viễn, ngay cả khi hệ thống gặp sự cố.

• Định nghĩa: Khi một giao dịch đã được commit (hoàn tất), thì tất cả thay đổi của nó phải được ghi lại vĩnh viễn, kể cả khi hệ thống bị tắt đột ngột.
• Ý nghĩa: Dữ liệu đã commit sẽ không bao giờ bị mất, dù có sự cố phần cứng hoặc mất điện.
• Ví dụ: Sau khi chuyển tiền xong và hiện thông báo thành công, nếu máy chủ bị mất điện thì số tiền đã chuyển vẫn sẽ được lưu lại đúng.

Ví dụ về Durability:

Tình huống: Bạn ghi một đơn hàng mới và hệ thống bị mất điện ngay sau khi hiển thị thông báo thành công.

START TRANSACTION;
INSERT INTO orders (id, customer_id) VALUES (10, 1);
COMMIT;

✅ Sau khi COMMIT hoàn tất, dù hệ thống bị tắt đột ngột, dữ liệu vẫn không bị mất.

Vì:

• MySQL (với InnoDB) ghi dữ liệu vào log (redo log) và lưu trữ an toàn trước khi hoàn tất COMMIT.
• Sau khi hệ thống khởi động lại, dữ liệu vẫn tồn tại → Durability được đảm bảo.

Các cơ chế đảm bảo Durability:

1. Write-Ahead Logging (WAL): Ghi log trước khi thực hiện thay đổi
2. Double-Write Buffer: Trong InnoDB, dữ liệu được ghi hai lần để tránh corruption
3. Redo Log: Lưu trữ các thay đổi để phục hồi sau sự cố

ACID trong MySQL

MySQL sử dụng InnoDB làm storage engine mặc định từ phiên bản 5.5 trở lên, và InnoDB là storage engine duy nhất trong MySQL hỗ trợ đầy đủ ACID.

Cấu hình ACID trong MySQL:

-- Kiểm tra storage engine
SHOW VARIABLES LIKE 'default_storage_engine';

-- Kiểm tra cấu hình ACID
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';

Lợi ích của ACID

1. Đảm bảo tính toàn vẹn dữ liệu: Dữ liệu luôn ở trạng thái hợp lệ
2. Xử lý lỗi tốt hơn: Tự động rollback khi có lỗi
3. Hỗ trợ giao dịch phức tạp: Có thể thực hiện nhiều thao tác trong một giao dịch
4. Phục hồi sau sự cố: Dữ liệu được bảo vệ khỏi các sự cố hệ thống

Nhược điểm của ACID

1. Hiệu suất: Các tính chất ACID có thể ảnh hưởng đến hiệu suất
2. Khả năng mở rộng: Khó scale trong một số trường hợp
3. Độ phức tạp: Yêu cầu quản lý phức tạp hơn

Khi nào nên sử dụng ACID?

ACID phù hợp cho các ứng dụng:

• Yêu cầu tính toàn vẹn dữ liệu cao
• Có nhiều giao dịch đồng thời
• Cần đảm bảo tính nhất quán dữ liệu
• Xử lý dữ liệu tài chính, ngân hàng

✅ Tóm tắt ACID:

✅ Bảng ví dụ về ACID

Kết luận

ACID là nền tảng quan trọng trong thiết kế cơ sở dữ liệu, đặc biệt là trong các hệ thống yêu cầu tính toàn vẹn dữ liệu cao. Hiểu và áp dụng đúng các nguyên tắc ACID sẽ giúp xây dựng các ứng dụng đáng tin cậy và bảo mật.

Tuy nhiên, không phải mọi ứng dụng đều cần tuân thủ đầy đủ ACID. Trong một số trường hợp, bạn có thể cần cân nhắc giữa tính toàn vẹn dữ liệu và hiệu suất hệ thống.

Tài liệu tham khảo

1. MySQL Documentation - ACID Compliance
2. InnoDB Transaction Model
3. Database System Concepts
4. High Performance MySQL