UUIDv7 không có những đặc tính mà bạn vẫn tưởng

Khi đọc tài liệu về UUIDv7, hầu hết chúng ta đều được giới thiệu ba lợi ích lớn: ID tăng đơn điệu (monotonic), chứa timestamp giúp biết thời điểm tạo đối tượng, và không thể đoán được. Thế nhưng, một bài phân tích gần đây trên Hacker News chỉ ra rằng không có đặc tính nào trong số này được đảm bảo chặt chẽ. Điều duy nhất UUIDv7 thực sự mang lại là tính duy nhất và khả năng chống trùng lặp (collision resistance).

Timestamp: hữu ích nhưng không đáng tin

Thoạt nhìn, việc nhúng timestamp vào ID có vẻ giúp loại bỏ cột thời gian tạo riêng trong cơ sở dữ liệu, từ đó tối ưu hiệu năng. Nếu bạn thường xuyên cần liệt kê dữ liệu theo thứ tự thời gian tạo, việc chỉ mục chính tự sắp xếp theo thời gian là một lợi thế rõ ràng.

Tuy nhiên, timestamp nhúng trong UUIDv7 không nhất thiết phản ánh thời điểm đối tượng được tạo. Tài liệu PostgreSQL cho hàm uuid_extract_timestamp đã cảnh báo rằng "timestamp trích xuất được không nhất thiết trùng khớp chính xác với thời điểm UUID được sinh ra".

RFC 9562 cho phép các triển khai tự ý điều chỉnh trường timestamp, sử dụng những giá trị không lấy trực tiếp từ đồng hồ hệ thống. Trong một số tình huống, khoảng cách giữa timestamp trong ID và thời gian thực có thể lớn tùy ý.

Các triển khai CÓ THỂ thay đổi timestamp thực tế. — RFC 9562 §6.1

Đặc tả này không đưa ra yêu cầu hay bảo đảm nào về việc giá trị đồng hồ phải gần với thời gian thực tế. — RFC 9562 §6.1

… các triển khai CÓ THỂ tăng timestamp vượt trước thời gian thực … — RFC 9562 §6.2

Ví dụ với thư viện chuẩn Python

Thư viện chuẩn Python là một triển khai nổi bật có hành vi tăng timestamp. Việc tăng chỉ xảy ra trong một số trường hợp nhất định, chẳng hạn khi bộ đếm bị tràn. Nhưng nếu đồng hồ hệ thống bị tua ngược, bộ sinh ID có thể rơi vào vòng lặp tăng timestamp mãi mãi, khiến timestamp chạy vượt xa thời gian thực mà không có giới hạn.

Kịch bản đơn giản: khởi tạo generator với thời gian hiện tại, sau đó tua đồng hồ hệ thống lùi lại một giờ và liên tục sinh ID. Kết quả thu được cho thấy độ lệch tăng dần theo thời gian thay vì giảm như mong đợi. Khi tốc độ sinh ID vượt quá một ID mỗi mili giây, sai lệch sẽ tăng vô hạn.

Các nhà phát triển Python lập luận rằng hành vi này phù hợp với RFC, tương thích với những triển khai khác và "không có nhiều điều có thể làm" với một hệ thống vốn đã "có khiếm khuyết". Trên thực tế, hiện tượng đồng hồ tua ngược xuất hiện khá phổ biến trong thực tế, thậm chí có trường hợp lệch tới hàng thập kỷ trong các môi trường nhạy cảm với thời gian.

Rò rỉ timestamp có nguy hiểm không?

Vì timestamp nằm ngay trong ID, bạn không thể chia sẻ ID mà không kèm theo mốc thời gian. Ví dụ, trang hồ sơ người dùng không công khai ngày tạo tài khoản nhưng UUIDv7 trên URL lại để lộ timestamp độ chính xác cao. Đây thường không phải là mối lo bảo mật nghiêm trọng, nhưng trong một số bối cảnh cụ thể, việc rò rỉ metadata kiểu này cần được lưu tâm.

UUIDv7 có thực sự tăng đơn điệu?

Đây là điểm cần lưu ý nhất. RFC mô tả phương pháp tạo ID trên nhiều node theo thứ tự tăng đơn điệu — điều mà giới khoa học đã chứng minh là bất khả thi từ thập niên 1970, dẫn đến sự ra đời của vector clock và các công nghệ tương tự. Vấn đề cốt lõi là các đồng hồ hệ thống không thể đồng bộ hóa tới độ chính xác cần thiết.

Timestamp chỉ sắp xếp được theo thời gian khi bạn biết chính xác thời gian hiện tại — và bạn thì không biết.

Ngay cả trên một node duy nhất, với một triển khai duy nhất, UUIDv7 vẫn không tăng đơn điệu tuyệt đối. Cách dễ nhất để có ID lệch thứ tự là dùng triển khai chỉ có timestamp mili giây mà không có bộ đếm — một vòng lặp for nhỏ là đủ sinh ra ID sai thứ tự.

Điểm tích cực là ID được sắp xếp gần đúng vẫn rất hữu ích, nên bạn không cần loại bỏ UUIDv7 khỏi hệ thống ngay. Chỉ cần cẩn trọng với những giả định của mình.

Khởi động lại bộ sinh UUIDv7

RFC dành khá nhiều dung lượng để bàn về việc xử lý đồng hồ tua ngược. Một cách giảm thiểu là lưu timestamp cuối cùng đã dùng vào bộ nhớ bền vững để đọc lại sau khi khởi động lại tiến trình. Tuy nhiên, bài phân tích cho thấy không có triển khai UUIDv7 nào thực hiện việc này — nghĩa là sau khi khởi động lại, nếu đồng hồ từng tua ngược, ID sinh ra sẽ lệch thứ tự.

Ngược lại, nếu đồng hồ bị đặt về một ngày trong tương lai, cơ chế bảo vệ timestamp cuối cùng lại ép bộ sinh tiếp tục dùng mốc sai đó cho đến khi đồng hồ thực đuổi kịp, kéo theo nguy cơ tràn bộ đếm.

Vậy UUIDv7 thực chất là gì?

Có thể hình dung UUIDv7 như một mớ ý tưởng hỗn hợp mà mỗi triển khai được tự do chọn lựa cách hiện thực. Mức độ đảm bảo các đặc tính dao động rất lớn giữa các thư viện. Điều duy nhất bạn có thể kỳ vọng một cách chắc chắn là tránh trùng lặp và tính duy nhất của ID.

Khi chọn một triển khai UUIDv7, nên đặt các câu hỏi sau:

• Triển khai này có tuân thủ RFC không?
• Nó bảo đảm thêm những đặc tính nào?
• Các bảo đảm đó còn đúng trong giới hạn nào?
• Những đặc tính này phụ thuộc vào giả định gì (ví dụ đồng hồ hệ thống chính xác)?
• Trong điều kiện nào triển khai sẽ thay đổi timestamp?
• ID sinh ra dễ đoán đến mức nào?

Đối với độc giả Việt Nam đang xây dựng hệ thống phân tán hoặc thiết kế khóa chính, bài học ở đây khá thực tế: đừng xem UUIDv7 là viên đạn bạc thay thế hoàn toàn cho cột timestamp hay cơ chế sắp xếp riêng. Hãy kiểm chứng hành vi thực tế của thư viện bạn dùng — đặc biệt khi hệ thống chạy trên nhiều node, nhiều ngôn ngữ và đồng hồ không đồng bộ.