Công cụ dành cho nhà phát triển · Trình tạo UUID
ULID, Snowflake, KSUID và UUIDv7: So sánh các ID có thể sắp xếp
· Lý lịch
uuid mật mã browser-apis
UUID ngẫu nhiên không sắp xếp theo thời gian tạo, vì vậy một số định dạng đặt dấu thời gian lên hàng đầu. Bài đăng này so sánh ULID, Snowflake, KSUID và UUIDv7 về bố cục, kích thước, tính đơn điệu và khả năng tương thích.
ID ngẫu nhiên và chỉ mục ghét chúng - vấn đề mà mã định danh theo thứ tự thời gian giải quyết
Các UUID v4 ngẫu nhiên phân tán các điểm chèn trên khóa chính của cây B khi các bản ghi mới đến, gây ra sự phân tách và sắp xếp lại trang. Việc chèn vào các vị trí ngẫu nhiên làm giảm hiệu suất ghi và tăng độ phân mảnh đĩa một cách đáng kể. Cơ sở dữ liệu thông lượng cao chấp nhận chi phí này—giá của các mã định danh thực sự độc lập, không phối hợp—nhưng chi phí là có thật. Nếu bạn cần UUID để sắp xếp theo thời gian tạo, bạn có thể cải thiện đáng kể các đặc điểm chỉ mục bằng cách thêm tiền tố dấu thời gian. Một số định dạng đã xuất hiện: ULID, Snowflake, KSUID và RFC 9562 v7. Mỗi loại tạo ra sự cân bằng khác nhau về kích thước (26 ký tự thành 128 bits), độ chính xác của dấu thời gian (giây đến nano giây), khả năng tương thích UUID và liệu việc phối hợp trình tạo ID có cần tập trung hay không. Điểm chuẩn cơ sở dữ liệu cho thấy hiệu suất chèn được cải thiện đáng kể.
ULID — dấu thời gian mili giây 48 bit cộng với 80 bit ngẫu nhiên trong 26 ký tự base32 của Crockford, với tùy chọn đơn điệu
ULID (Mã định danh có thể sắp xếp theo từ điển duy nhất trên toàn cầu) mã hóa dấu thời gian 48-bit mili giây và tải trọng ngẫu nhiên 80-bit trong 26 ký tự của Crockford base32. Việc trình bày văn bản sắp xếp chính xác theo thứ tự từ điển, giúp ULID phù hợp với các hệ thống trong đó thứ tự dấu thời gian và khả năng đọc đóng vai trò quan trọng—xử lý nhật ký, theo dõi phân tán, vi dịch vụ trong đó mã định danh cần phải dễ đọc ở đầu ra mà con người nhìn thấy. ULID cung cấp một biến thể đơn điệu trong đó nhiều số nhận dạng được tạo trong cùng một phần nghìn giây sẽ tăng phần ngẫu nhiên thay vì lặp lại, đảm bảo ngay cả các đợt ID nhanh cũng duy trì thứ tự tạo nghiêm ngặt. Sự đánh đổi là ULID không phải là UUID: nó không vừa với cột cơ sở dữ liệu 128-bit UUID tiêu chuẩn mà không cần chuyển đổi mã hóa. Độ chính xác ULID bao gồm khoảng 8925 năm.
Bông tuyết — ID 64-bit từ dấu thời gian, ID công nhân và trình tự cũng như sự phối hợp mà chúng yêu cầu
Snowflake là mã nhận dạng 64-bit do Twitter thiết kế ban đầu, có cấu trúc dưới dạng dấu thời gian 41-bit mili giây, ID nhân viên 10-bit và số thứ tự 12-bit. Dấu thời gian 41 bit bao gồm khoảng 69 năm và tràn trong 2106, yêu cầu phải có sự phối hợp và lập kế hoạch di chuyển theo kỷ nguyên. ID nhân viên phân biệt các mã nhận dạng được tạo bởi các máy chủ hoặc quy trình khác nhau—mỗi trình tạo Bông tuyết phải biết ID nhân viên duy nhất của riêng mình mà không xung đột với các mã khác. Bông tuyết là 64 bits thay vì 128, làm cho nó có kích thước bằng một nửa UUID, lập chỉ mục nhanh hơn và tiết kiệm bộ nhớ hơn cho mỗi số nhận dạng. Nó sắp xếp theo thời gian và ID nhân viên, hữu ích cho việc định tuyến các yêu cầu hoặc nhật ký theo nguồn. Hạn chế là vận hành: mỗi trình tạo phải được gán một ID công nhân, đồng hồ phải được đồng bộ hóa.
KSUID - dấu thời gian giây với tải trọng ngẫu nhiên lớn, được sắp xếp theo byte
KSUID (Mã định danh duy nhất có thể sắp xếp K) là mã định danh 128-bit bao gồm dấu thời gian thứ hai Unix 32-bit và tải trọng ngẫu nhiên 96-bit, thường được mã hóa dưới dạng 27 ký tự base62. Định dạng này có thể sắp xếp theo thứ tự từ điển và phần ngẫu nhiên phù hợp với kích thước của nó về mặt mật mã. KSUID ít được sử dụng rộng rãi hơn ULID hoặc Snowflake nhưng cung cấp ngữ nghĩa riêng biệt: dấu thời gian dễ dàng được giải mã thành giây mà con người có thể đọc được (hữu ích trong nhật ký và gỡ lỗi) và phần ngẫu nhiên 96-bit đủ lớn để nhiều KSUID được tạo trong cùng một giây có xác suất trùng lặp thực tế bằng 0 nếu không có sự phối hợp trình tự. Không giống như Snowflake, KSUID không yêu cầu phối hợp ID công nhân hoặc phân bổ trung tâm. KSUID hoạt động theo giây thay vì mili giây, do đó, nhiều ID trong một giây sẽ sắp xếp ngẫu nhiên trừ khi bạn triển khai logic bổ sung.
UUIDv7 — câu trả lời theo tiêu chuẩn phù hợp với các cột và công cụ uuid hiện có
RFC 9562 v7 là mã định danh 128 bit bao gồm dấu thời gian Unix mili giây 48-bit, 12 bits có độ chính xác dưới một phần nghìn giây (có thể sử dụng làm bộ đếm chuỗi) và tất cả các bit ngẫu nhiên 62 được kết hợp lại. Nó sắp xếp chính xác cả dưới dạng chuỗi từ điển và dưới dạng byte 128-bit trong cơ sở dữ liệu. Điều quan trọng là nó là UUID hợp lệ—nó đặt phiên bản nibble thành 7 và các bit biến thể thành RFC 9562 tiêu chuẩn, làm cho nó tương thích với mọi công cụ, cột cơ sở dữ liệu và API xử lý UUID. Không cần chuyển đổi mã hóa và cơ sở hạ tầng UUID hiện tại không cần sửa đổi. Nếu nhiều số nhận dạng v7 được tạo trong cùng một mili giây, RFC 9562 khuyên bạn nên sử dụng trường dưới một phần nghìn giây làm bộ đếm đơn điệu thay vì các bit ngẫu nhiên. V7 đại diện cho một lựa chọn thực tế để duy trì khả năng tương thích UUID.
Tính đơn điệu trong vòng một mili giây - cách mỗi định dạng xử lý các cụm và lý do tại sao nó lại quan trọng đối với việc đảm bảo đặt hàng
Tính đơn điệu là đặc tính mà nếu hai sự kiện xảy ra theo thứ tự có thể quan sát được thì ID của chúng sẽ so sánh theo cùng thứ tự đó. Ở mức độ chi tiết ở mức mili giây trên phần cứng hiện đại, nhiều sự kiện thường xuyên xảy ra trong cùng một tích tắc đồng hồ, do đó, mọi sơ đồ ID có thể sắp xếp đều phải xử lý chính xác thứ tự dưới một phần nghìn giây. ULID cung cấp chế độ đơn điệu rõ ràng trong đó phần ngẫu nhiên tăng dần thay vì ngẫu nhiên hóa. Bông tuyết bao gồm số thứ tự 12-bit tăng dần trong tích tắc một phần nghìn giây. KSUID thiếu cơ chế tích hợp nên các sự kiện dưới giây sẽ sắp xếp ngẫu nhiên trừ khi logic bổ sung được thêm vào. RFC 9562 v7 khuyên bạn nên sử dụng trường dưới một phần nghìn giây làm bộ đếm đơn điệu. Nếu hệ thống của bạn tạo ra hàng nghìn UUID mỗi giây thì tính đơn điệu trong một phần nghìn giây sẽ ảnh hưởng đáng kể đến thứ tự truy vấn.
Điều này không bao gồm - điểm chuẩn thông lượng, phụ thuộc vào phần cứng và ngôn ngữ; bài viết vẫn có chất lượng
Điểm chuẩn thông lượng và dữ liệu hiệu suất không được đưa vào vì chúng phụ thuộc nhiều vào kiến trúc phần cứng, triển khai ngôn ngữ, công cụ cơ sở dữ liệu và chiến lược bộ nhớ đệm. Các đặc tính hiệu suất của cơ sở dữ liệu thay đổi đáng kể tùy theo việc bạn đang đo lường các lần chèn ngẫu nhiên, truy vấn phạm vi, chi phí chỉ mục hay tổng thông lượng trong tải sản xuất thực tế. Bài đăng vẫn mang tính định tính, so sánh các định dạng về mặt khái niệm dựa trên thiết kế của chúng thay vì cung cấp các con số cụ thể về môi trường có thể gây hiểu nhầm. Đánh giá hiệu suất trong thế giới thực yêu cầu thử nghiệm trong môi trường của riêng bạn với khối lượng công việc, cơ sở mã và các ràng buộc vận hành của riêng bạn. Việc so sánh các định dạng ID khác nhau là một bài tập có giá trị.
Bài học rút ra: tính tương thích thường quyết định - trình tạo ToolAcre tạo ra các UUID ngẫu nhiên; sử dụng kiểm tra được định dạng đúng để xác nhận rằng UUIDv7 từ thư viện của bạn phân tích cú pháp dưới dạng UUID
Khả năng tương thích thường quyết định nên chọn định dạng nào. Nếu lược đồ cơ sở dữ liệu của bạn đã yêu cầu các cột UUID thì v7 là câu trả lời hiện đại cho khả năng sắp xếp mà không cần rời khỏi hệ sinh thái UUID. Nếu xây dựng một hệ thống mới với các loại ID tùy chỉnh, ULID mang lại khả năng trình bày văn bản nhỏ hơn và lợi thế về độ chính xác đến mili giây. Nếu bạn cần bộ lưu trữ 64-bit và có thể quản lý việc phối hợp ID nhân viên thông qua phân bổ tập trung thì Snowflake là một lựa chọn đã được chứng minh trong các hệ thống có khối lượng lớn. Sự cân bằng cơ bản là giữa khả năng tương thích tiêu chuẩn (chọn v7) và các thuộc tính thay thế như kích thước nhỏ hơn (Snowflake) hoặc khả năng đọc base32 (ULID). Đưa ra lựa chọn dựa trên các ràng buộc của hệ thống và các quyết định của hệ sinh thái.