7.16 Consistency: núm vặn và giá của chúng

Mặc định của Qdrant, nói thẳng ra:

Qdrant ưu tiên tính sẵn sàng và throughput, không ưu tiên consistency. Hai cập nhật đồng thời lên cùng một point có thể để các replica ở trạng thái khác nhau cho tới khi chúng đồng bộ lại. Đọc ngay sau khi ghi có thể trúng một replica chưa bắt kịp.

Đây không phải lỗi. Đó là điểm mà Qdrant chọn đứng trên đường đánh đổi, và nó hợp lý cho phần lớn hệ RAG. Nhưng bạn phải biết mình đang đứng ở đâu, vì triệu chứng của nó — “dữ liệu lúc có lúc không” — rất dễ bị chẩn đoán nhầm thành mất dữ liệu.

Ba núm vặn, độc lập nhau. Học chúng theo đúng ba câu hỏi mà chúng trả lời.

Núm 1 — `write_consistency_factor`: bao nhiêu replica phải xác nhận?


Đặt ở	cấu hình collection
Mặc định	1
Miền giá trị	1 → số replica của mỗi shard

Nghĩa: bao nhiêu replica phải báo đã ghi xong thì mới trả lời client là thành công.

Đánh đổi, và nó có hai chiều rõ ràng:

write_consistency_factor = 1                write_consistency_factor = 2 (với 2 replica)
──────────────────────────────              ─────────────────────────────────────────
+ ghi nhanh                                 + chịu được network partition
+ vẫn ghi được khi replica khác chết        − MỘT replica chết là KHÔNG GHI ĐƯỢC nữa
− replica còn lại có thể chưa có dữ liệu

Câu cần đọc kỹ: tăng giá trị này làm giảm tính sẵn sàng của thao tác ghi. Nếu số replica đang hoạt động tụt xuống dưới ngưỡng, thao tác ghi thất bại. Đây là lựa chọn có ý thức giữa “ghi được nhưng có thể chưa đồng đều” và “hoặc ghi đúng ở nhiều nơi, hoặc không ghi”.

Núm 2 — `consistency`: đọc hỏi bao nhiêu replica?


Đặt ở	từng request đọc
Mặc định	1

Giá trị	Nghĩa
số nguyên `N`	hỏi `N` replica ngẫu nhiên, trả về điểm có mặt ở tất cả chúng
`quorum`	hỏi đa số replica, trả về điểm có mặt ở tất cả những replica được hỏi
`majority`	hỏi tất cả, trả về điểm có mặt ở đa số
`all`	hỏi tất cả, trả về điểm có mặt ở tất cả

Chú ý sự khác nhau tinh vi giữa quorum và majority: quorum hỏi ít hơn (rẻ hơn) nhưng đòi hỏi khắt khe trên tập nhỏ hơn; majority hỏi nhiều hơn nhưng dễ dãi hơn khi quyết định. Với đa số hệ, quorum là điểm cân bằng hợp lý khi bạn thật sự cần hơn mặc định.

Cái giá rất trực tiếp: mỗi mức cao hơn là thêm tải và thêm latency. Đọc có consistency cao không miễn phí — bạn đang bắt nhiều máy cùng làm một việc rồi so kết quả.

Vì đây là tham số theo từng request, cách dùng đúng là chọn theo đường:

Truy vấn phục vụ người dùng   →  mặc định (1). Nhanh. Lệch một chút không ai chết.
Kiểm tra sau khi ghi          →  quorum hoặc all.
Job đối soát / xuất dữ liệu   →  all.

Núm 3 — `ordering`: thao tác ghi được sắp thứ tự thế nào?


Đặt ở	từng request ghi
Mặc định	`weak`

Giá trị	Nghĩa	Cái giá
`weak`	Không đảm bảo gì thêm; các thao tác có thể bị đảo thứ tự	Nhanh nhất
`medium`	Sắp thứ tự qua một leader được bầu động	Có thể lệch nhẹ lúc đổi leader
`strong`	Sắp thứ tự qua một leader cố định	Leader chết là không ghi được

Khi nào bạn thật sự cần medium/strong: khi hai thao tác lên cùng một point phải xảy ra đúng thứ tự. Ví dụ điển hình: cập nhật payload rồi ngay sau đó cập nhật vector, và bạn không muốn thứ tự bị đảo.

Nếu bạn chỉ nạp dữ liệu độc lập theo lô, weak là đúng và đừng đụng vào.

Cách khác, thường tốt hơn: conditional update

Từ v1.16, Qdrant có cập nhật có điều kiện — kiểu khoá lạc quan (optimistic concurrency): bạn giữ một trường version trong payload, và yêu cầu thao tác chỉ áp dụng nếu giá trị hiện tại đúng bằng cái bạn đã đọc. Đặt update_mode: "update_only" để tránh vô tình chèn mới khi điều kiện không khớp.

Với nhiều tiến trình cùng ghi, conditional update thường là câu trả lời đúng hơn ordering: strong — nó không hy sinh tính sẵn sàng của cả hệ để giải quyết một vấn đề cục bộ ở vài point.

Read affinity — chữa hiện tượng “kết quả nhấp nháy”

Từ v1.19. Triệu chứng: cùng một truy vấn gọi hai lần cho ra hai kết quả hơi khác nhau, vì hai lần đó rơi vào hai replica có mức đồng bộ khác nhau. Người dùng bấm F5 và thấy kết quả đổi.

Cách chữa: gửi header X-Qdrant-Route-Affinity với một định danh ổn định (ID phiên, ID người dùng). Cùng một định danh sẽ được ghim vào cùng một replica.

Đây là cách rẻ nhất để loại bỏ hiện tượng nhấp nháy: bạn không mua consistency toàn cục, bạn chỉ mua consistency theo phiên — và trong sản phẩm, đó thường đúng là thứ người dùng cảm nhận được. Định tuyến là nỗ lực tốt nhất, không phải đảm bảo cứng.

Bảng chọn

Bạn cần	Đặt gì	Trả giá gì
Nạp dữ liệu nhanh	mặc định hết, `wait=false`	Đọc ngay có thể chưa thấy
Người dùng không thấy kết quả nhấp nháy	read affinity	Gần như không
Ghi xong đọc lại phải thấy	`wait=true` + `consistency: quorum`	Latency
Chịu được mất một node mà không mất ghi	`replication_factor ≥ 2`, giữ `write_consistency_factor: 1`	Gấp đôi dung lượng
Chịu được network partition	`write_consistency_factor ≥ 2`	Mất khả năng ghi khi thiếu replica
Nhiều tiến trình ghi cùng một point	conditional update (v1.16)	Phải xử lý trường hợp xung đột
Thứ tự tuyệt đối trên cùng một point	`ordering: strong`	Leader chết là đứng

Phần 7 — Qdrant