Optimistic Concurrency

Optimistic concurrency là cách xử lý concurrent write theo kiểu “cứ cho các writer làm song song trước, đến lúc commit mới kiểm tra conflict”.

Trong Apache Iceberg, idea này gần với optimistic lock, nhưng nó không phải lock row như database truyền thống. Iceberg thường xem data file là immutable; transaction chủ yếu là ghi data/metadata mới rồi publish một metadata state mới thông qua catalog.

Mental model

Table hiện tại trỏ tới metadata version v1

Writer A đọc v1
Writer B cũng đọc v1

A tạo metadata mới v2_A
B tạo metadata mới v2_B

A commit trước:
  catalog pointer đổi từ v1 → v2_A
  success

B commit sau:
  B tưởng base vẫn là v1
  nhưng catalog hiện đã là v2_A
  Iceberg check conflict
  nếu conflict → B fail/retry
  nếu không conflict → B có thể commit tiếp

Tư duy ở đây là:

“Cứ làm đi, tới lúc commit mới xem có ai đụng vào phần mình định thay đổi không.”

Pessimistic concurrency khác gì?

Pessimistic concurrency thì ngược lại. Nó giả định conflict dễ xảy ra, nên lock trước:

Writer A muốn update table
→ lấy lock
→ trong lúc A giữ lock, Writer B không được commit update conflict
→ A xong thì thả lock
→ B mới làm tiếp

Tư duy là:

“Có khả năng đụng nhau đấy, khóa lại trước cho chắc.”

Cách này dễ reason hơn, nhưng giảm concurrency. Trong data lake/object storage, một lock toàn cục thường khó, chậm, hoặc phải phụ thuộc vào external system.

Vì sao Iceberg hợp với optimistic concurrency?

Iceberg commit chủ yếu ở metadata layer:

data files mới
manifest files mới
metadata file mới
catalog pointer mới

Nếu commit thành công, table chuyển sang snapshot mới. Nếu commit conflict, writer có thể fail/retry thay vì làm hỏng dữ liệu.

Điểm quan trọng là “lock” nằm ở cấp table metadata / snapshot / catalog pointer, không phải lock từng row hay update bytes trong file cũ.

So với optimistic lock / pessimistic lock

Nó giống optimistic lock ở idea:

đọc version hiện tại
làm việc dựa trên version đó
commit/update nếu version vẫn hợp lệ
nếu version đổi thì fail/retry

Nhưng trong Iceberg, “version” không phải row version. Nó là table metadata/snapshot/catalog pointer.

Pessimistic lock thì lock trước vì giả định conflict dễ xảy ra. Optimistic concurrency thì không lock trước, chỉ check ở commit time.

Ghi nhớ ngắn

Optimistic:
  không khóa trước
  commit rồi check conflict
  conflict thì retry/fail
  concurrency cao hơn

Pessimistic:
  khóa trước
  writer khác phải chờ
  dễ reason hơn
  concurrency thấp hơn

Trong Iceberg, optimistic concurrency là một phần lý do table có thể hỗ trợ nhiều reader/writer trên data lake mà vẫn giữ ACID/correctness guarantees.