Giải thích ACID trong database
Atomicity
Atomicity là tính chất cơ bản của relational database đảm bảo rằng một transaction nhiều step phải được đối xử như 1 transaction duy nhất mà không thể chia cắt. Thường được mô tả là "hoặc là tất cả hoặc là không".
Nó đảm bảo rằng mọi hành động trong 1 transaction phải thành công và commit vào database. Nếu có bất kì 1 hành động nào đó fail, thì toàn bộ transaction đó phải coi như fail và rollback, database hoàn toàn nguyên vẹn như chưa từng chạm vào.
Ví dụ, bạn đang mua một 1 chiếc iPhone phiên bản giới hạn trên web online. Hệ thống cần thực hiện 2 hành động:
Reduce inventory by one
Confirm your order
Nếu không atomicity, nó có thể trừ trong inventory, nhưng crash trước khi order được confirm. Giờ thì cửa hàng nghĩ rằng đã hết hàng, nhưng mà không ai nhận được hàng.
Consistency
Consistency đề cập đến việc duy trì ràng buộc integrity của data.
Integrity constraints (ràng buộc toàn vẹn) là một tập hợp các rule mà data trong table phải bắt buộc tuân theo. Chúng được dùng để hạn chế các loại data có thể insert vào table. Ví dụ, cơ bản nhất là Not-null constraint, yêu cầu cột delete_flag trong bảng payment_tbl bắt buộc phải có giá trị khác Null. Nếu data được insert vào bảng payment_tbl mà có field delete_flag là null sẽ bị database từ chối insert vào.
Quay lại tính consistency, một transaction consistency sẽ không vi phạm các integrity constraint được đặt ra trong database. Điều đó có nghĩa là, sau hàng loạt các transaction được thực hiện, dữ liệu trong database phải luôn ở trạng thái hợp lệ (legal state). Nếu transaction nào khiến cho dữ liệu trong database rơi vào trạng thái không hợp lệ, thì transaction đó phải bị hủy bỏ và các thay đổi của dữ liệu sẽ được khôi phục về trạng thái hợp lệ trước đó của chúng.
Thêm một ví dụ nữa, nếu như ràng buộc là tất cả các số dư tài khoản (ở cột balance) của tất cả khách hàng trong bảng customer_tbl đều phải là số nguyên dương. Nếu như một transaction nào đó khiến cho số dư tài khoản của khách hàng là số âm, transaction đó phải được roll-back. Điều này đảm bảo rằng nếu thay đổi thành công thì phải đảm bảo các integrity constraint, còn không thì hủy hoàn toàn.
Isolation
Có thể hiểu Isolation là định nghĩa cách và khi nào một thay đổi được tạo bởi 1 transaction này sẽ trở nên visible đối với các transaction đồng thời khác.
Các hệ thống database đạt được Isolation bằng cách sử dụng các rules và mechanisms (locking data, keeping multiple copies) của data trong khi update.
Tuy nhiên, việc isolation nghiêm ngặt sẽ phải đánh đổi:
High isolation: Đảm bảo được data chính xác hoàn toàn, nhưng buộc các transaction phải chờ lẫn nhau, làm giảm performance.
Low isolation: Cho phép database run nhanh hơn bằng cách để cho các transaction đọc data một cách tự do, nhưng có nguy cơ để các dữ liệu không chính xác lọt qua.
Để cần bằng giữa tốc độ và sự chính xác, có 4 loại isolation levels:
Read Uncommited
Các transactions có thể đọc những data mới nhất, không quan tâm đến việc data đó được commit hay chưa.
Performance tốt vì không có lock.
Với PostgreSQL, chúng ta không thể thực hiện Read Uncommited. Nguyên nhân là vì PostgreSQL sử dụng cơ chế Multi-version concurrency control. Mỗi transaction giữ một tuple riêng cho record để giảm thiểu vấn đề locking.
Read commited
Đây là level mặc định của transaction isolation cho hầu hết các database. Transaction sẽ không thể read/update data đang được modify ở transaction khác mà chưa commit.
Nhưng dẫn tới một vấn đề là, mặc dù cùng transaction nhưng mỗi thời điểm khác nhau đọc ra giá trị khác nhau của record. Dữ liệu lúc này không nhất quán. Nó còn được gọi là non-repeatable read.
Như vậy, Read Commited có thể ngăn chặn được dirty read, nhưng không thể ngăn chặn non-repeatable read và phantom read.
Repeatable read
Tức là trong cùng 1 transaction, đảm bảo dữ liệu chắc chắn là thống nhất trong tất cả các lần query, không quan tâm đến việc các transaction đã commit sự thay đổi hay chưa.
Repeatable read chỉ ngăn chặn được non-repeatable read, nhưng không ngăn chặn được phantom read.
Nhưng có một vấn đề khác có thể xảy ra nếu 2 transaction cùng thực hiện modify data. Thì dẫn đến toàn bộ transaction sau bị hủy bỏ và chỉ có thể rollback và retry.
Durability
Durability trong database đảm bảo rằng 1 transaction đã được commit thành công thì các thay đổi của transaction đó sẽ vĩnh viễn được lưu lại, thậm chí khi system bị crash, mất điện ngay sau đó.
Data được commit di chuyển từ RAM sang permanent storage (SSD, HDD) sẽ giữ data an toàn khi mất điện.
Các cơ sở dữ liệu ghi lại các thay đổi trong một file append-only log trên disk trước khi thực sự update vào database files. Nếu crash xảy ra, thì database sẽ replay file log này để restore toàn bộ các data đã được commit.