Giao dịch và những cái nhãn nói dốiLàm trọn gói, hoặc không làm gìTransactions and the labels that lie

Kleppmann mở chương bằng việc tháo tung từ viết tắt nổi tiếng nhất ngành. ACID được Theo Härder và Andreas Reuter đặt ra năm 1983 để có một thuật ngữ chính xác cho khả năng chịu lỗi của hệ cơ sở dữ liệu7. Nhưng mức độ hiện thực của nó khác nhau rất xa giữa các sản phẩm, đến mức ông kết luận rằng ngày nay ACID phần lớn đã thành một từ khóa tiếp thị: nghe "hệ này có ACID" gần như không cho bạn biết điều gì cụ thể1. Chính vì thế ông tự viết một bộ kiểm thử — Hermitage — để đo xem mỗi hệ thật sự làm gì56.

Bạn sẽ hay nghe người ta khoe "cơ sở dữ liệu của tôi có ACID". Bốn chữ đó nghe rất oách. Nhưng mỗi hãng lại làm một kiểu, nên nghe xong bạn vẫn chưa biết nó thật sự bảo vệ bạn khỏi cái gì. Nhớ nhé: nghe cái nhãn xong thì phải hỏi tiếp một câu — "cụ thể là chặn được lỗi nào?".

Kleppmann opens by taking apart the industry's most famous acronym. ACID was coined by Theo Härder and Andreas Reuter in 1983 to give a precise term for a database system's fault tolerance7. But how far it is actually implemented varies so widely between products that he concludes ACID has largely become a marketing term: hearing "this system is ACID" tells you almost nothing concrete1. Which is why he wrote a test suite of his own — Hermitage — to measure what each system really does56.

Cô lập tuần tự là bảo đảm sạch nhất, nhưng đắt — nên hầu hết cơ sở dữ liệu mặc định ở một mức yếu hơn, chặn một số race condition và để lọt số còn lại1. Rắc rối là ở tên gọi. Chuẩn ANSI SQL định nghĩa các mức cô lập qua ba "hiện tượng" — dirty read, non-repeatable read, phantom9 — và Berenson cùng cộng sự đã chỉ ra ngay từ 1995 rằng những định nghĩa đó không đủ để đặc tả nhiều mức cô lập phổ biến, kể cả cách hiện thực bằng khóa của chính chúng8. Kết quả là mỗi sản phẩm dùng cùng một cái tên cho những bảo đảm khác nhau.

Muốn thật an toàn thì phải xếp hàng từng người một — nhưng như thế chậm. Nên cơ sở dữ liệu cho bạn chọn mấy nấc "nhanh hơn nhưng hở hơn". Rắc rối là mỗi hãng gọi các nấc ấy bằng những cái tên na ná nhau mà nghĩa lại khác. Nhớ nhé: cùng một cái tên chưa chắc là cùng một lời hứa.

Serializable isolation is the cleanest guarantee, but it is expensive — so most databases default to something weaker that blocks some race conditions and lets the rest through1. The trouble is the naming. The ANSI SQL standard defines isolation levels through three "phenomena" — dirty read, non-repeatable read, phantom9 — and Berenson et al. showed back in 1995 that those definitions fail to characterise several popular isolation levels, including their own standard locking implementations8. The result: each product uses the same name for a different guarantee.

Đây là phần tinh vi nhất của chương, và cũng là chỗ dễ đọc ẩu nhất. Write skew không phải dirty write, cũng không phải lost update: trong cả hai loại kia, hai giao dịch cùng ghi vào một đối tượng. Ở write skew, hai giao dịch đọc cùng một tập đối tượng chồng lấn rồi mỗi bên cập nhật một đối tượng khác nhau — nên không có gì để khóa, và kết quả kết hợp phá vỡ một bất biến mà từng giao dịch riêng lẻ vẫn giữ được1.

Hai bạn cùng nhìn vào một tình huống, ai cũng thấy "còn đủ người, mình rút lui được", rồi mỗi bạn tự rút. Từng quyết định đều hợp lý, nhưng cộng lại thì chẳng còn ai. Điều đáng sợ là hai bạn không sửa cùng một chỗ nên máy không thấy gì bất thường. Nhớ nhé: lỗi này không nằm ở chỗ ghi, mà nằm ở chỗ đọc.

This is the subtlest part of the chapter, and the easiest to read carelessly. Write skew is not a dirty write, nor a lost update: in both of those, two transactions write to the same object. In write skew, two transactions read the same overlapping set of objects and then each updates a different object — so there is nothing to lock, and the combined result breaks an invariant that each transaction alone would have preserved1.

Serializable isolation là bảo đảm mạnh nhất: kết quả của một tập giao dịch chạy đồng thời phải giống hệt như thể chúng đã chạy nối đuôi nhau theo một thứ tự nào đó. Có nó thì mọi bất thường ở ba phần trên — dirty read, read skew, lost update, write skew, phantom — biến mất cùng một lúc, và lập trình viên không còn phải nghĩ về race condition trong từng ca một1. Câu hỏi duy nhất còn lại là: hiện thực nó kiểu gì, và trả giá ở đâu. Kleppmann trình bày đúng ba con đường.

Cách an toàn nhất là bắt mọi việc xếp hàng thật sự: xong việc này mới tới việc kia. Làm được thế thì tất cả các lỗi ở trên biến mất hết. Chỉ có điều xếp hàng thì chậm — nên người ta nghĩ ra ba cách khác nhau để vừa xếp hàng vừa đỡ chậm. Nhớ nhé: an toàn nhất là xếp hàng, và mỗi cách xếp hàng có một cái giá riêng.

Serializable isolation is the strongest guarantee: the outcome of a set of concurrent transactions must be identical to them having run one after another in some order. With it, every anomaly from the three sections above — dirty reads, read skew, lost updates, write skew, phantoms — disappears at once, and the programmer no longer reasons about race conditions case by case1. The only remaining question is how to implement it, and where the price is paid. Kleppmann lays out exactly three routes.