UUID vs ULID vs serial IDs: chọn ID phù hợp cho cơ sở dữ liệu của bạn

Vấn đề thực sự: chọn ID mà bạn không hối tiếc sau này

Việc chọn ID có vẻ nhàm chán trong tuần đầu. Rồi bạn ra mắt, dữ liệu lớn dần, và quyết định "đơn giản" đó xuất hiện ở khắp nơi: index, URL, log, export và tích hợp.

Câu hỏi thực sự không phải là "cái nào tốt nhất?" mà là "bạn muốn tránh nỗi đau nào sau này?" ID khó thay đổi vì chúng bị sao chép sang các bảng khác, được cache bởi client, và được các hệ thống khác phụ thuộc.

Khi ID không phù hợp với cách sản phẩm phát triển, bạn thường thấy nó ở vài chỗ:

• Chèn và truy vấn chậm hơn vì index khóa chính tăng theo một mô hình không thân thiện.
• Phân trang khó xử khi sắp xếp theo ID không khớp thời gian tạo.
• Migration trở nên rủi ro khi các hệ thống khác phụ thuộc định dạng ID của bạn.
• Debug lâu hơn khi ID khó đọc hoặc so sánh.
• Import va chạm khi gộp dữ liệu từ nhiều nguồn.

Luôn có đánh đổi giữa tiện lợi hiện tại và linh hoạt sau này. Serial integer dễ đọc và thường nhanh, nhưng có thể lộ số lượng bản ghi và làm việc ghép dữ liệu phức tạp hơn. UUID ngẫu nhiên tuyệt vời để đảm bảo duy nhất giữa các hệ thống, nhưng gây hại cho index và khó đọc với con người. ULID cố gắng vừa duy nhất toàn cầu vừa có thứ tự gần theo thời gian, nhưng vẫn có chi phí lưu trữ và công cụ.

Một cách suy nghĩ hữu dụng: ID chủ yếu dành cho ai?

Nếu ID chủ yếu cho con người (support, debug, ops), ngắn và dễ quét thường thắng. Nếu dành cho máy (ghi phân tán, client offline, hệ thống đa vùng), tính duy nhất toàn cục và tránh va chạm quan trọng hơn.

Định nghĩa nhanh bằng ngôn ngữ đơn giản

Khi người ta tranh luận "UUID vs ULID vs serial IDs," họ thực sự chọn cách mỗi hàng được gán một nhãn duy nhất. Nhãn đó ảnh hưởng đến việc chèn, sắp xếp, ghép và di chuyển dữ liệu sau này.

Serial IDs (integer/bigint)

Serial ID là một bộ đếm. Cơ sở dữ liệu cấp 1, sau đó 2, rồi 3… (thường lưu là integer hoặc bigint). Dễ đọc, rẻ để lưu và thường nhanh vì hàng mới nằm ở cuối index.

UUIDs

UUID là định danh 128-bit trông ngẫu nhiên, như 3f8a.... Trong nhiều cấu hình, nó có thể sinh mà không cần hỏi cơ sở dữ liệu cho số tiếp theo, nên các hệ thống khác nhau có thể tạo ID độc lập. Đổi lại, các insert trông ngẫu nhiên khiến index phải làm việc nhiều hơn và chiếm nhiều không gian hơn bigint.

ULIDs

ULID cũng là 128-bit, nhưng thiết kế để gần như sắp xếp theo thời gian. ULID mới hơn thường được sắp sau ULID cũ hơn, đồng thời vẫn duy trì tính duy nhất toàn cục. Bạn thường được lợi ích "sinh ở bất cứ đâu" như UUID nhưng có hành vi sắp xếp thân thiện hơn.

Tóm tắt đơn giản:

• Serial: nhỏ nhất và theo thứ tự mặc định.
• UUID: dễ sinh độc lập, ít thân thiện với con người, thường có thứ tự ngẫu nhiên.
• ULID: giống UUID về độc lập, nhưng gần như có thứ tự theo thời gian.

Serial phổ biến cho ứng dụng một database và công cụ nội bộ. UUID xuất hiện khi dữ liệu được tạo trên nhiều dịch vụ, thiết bị hoặc vùng. ULID phổ biến khi đội muốn sinh ID phân tán nhưng vẫn quan tâm đến thứ tự sắp xếp, phân trang hoặc truy vấn "mới nhất trước".

Lập chỉ mục và hiệu năng: điều gì thay đổi trong thực tế

Khóa chính thường được hỗ trợ bởi một index (thường là B-tree). Hãy nghĩ về index như một danh bạ điện thoại đã được sắp xếp: mỗi hàng mới cần một mục được đặt vào đúng chỗ để việc tìm kiếm nhanh.

Với ID ngẫu nhiên (UUIDv4 kinh điển), mục mới rơi khắp index. Điều đó nghĩa là cơ sở dữ liệu phải chạm nhiều trang index, chia trang thường xuyên hơn và ghi thêm. Theo thời gian bạn có nhiều churn trên index: nhiều công việc cho mỗi insert, nhiều cache miss và index lớn hơn mong đợi.

Với ID gần như tăng dần (serial/bigint, hoặc ID theo thời gian như nhiều ULID), cơ sở dữ liệu thường có thể append mục mới gần cuối index. Điều này thân thiện với cache vì các trang gần đây vẫn nóng, và insert trơn tru hơn ở tốc độ ghi cao.

Kích thước khóa quan trọng vì mục index không miễn phí:

• serial bigint: 8 bytes
• UUID: 16 bytes
• ULID: 16 bytes nếu lưu dưới dạng binary, lớn hơn nhiều nếu lưu dưới dạng chuỗi 26 ký tự

Khóa lớn hơn nghĩa là ít mục hơn vừa một trang index. Điều này thường dẫn đến index sâu hơn, nhiều trang phải đọc cho một truy vấn và cần nhiều RAM hơn để giữ tốc độ.

Nếu bạn có một bảng "events" với chèn liên tục, khóa chính UUID ngẫu nhiên có thể cảm thấy chậm hơn bigint sớm hơn, ngay cả khi lookup một hàng vẫn mượt. Nếu bạn dự kiến nhiều ghi, chi phí lập chỉ mục thường là khác biệt thực sự đầu tiên bạn nhận ra.

Sắp xếp, phân trang và thứ tự theo thời gian

Nếu bạn đã xây "Load more" hoặc infinite scroll, bạn đã thấy nỗi đau của ID không sắp xếp tốt. Một ID "sắp xếp tốt" khi order theo nó cho bạn thứ tự ổn định, có ý nghĩa (thường là thời gian tạo) để phân trang dự đoán được.

Với ID ngẫu nhiên (như UUIDv4), hàng mới bị phân tán. Sắp xếp theo id không khớp thời gian, và phân trang cursor kiểu "cho tôi các mục sau id này" trở nên không đáng tin. Thường bạn phải quay sang created_at, điều đó ổn nhưng cần cẩn thận.

ULID được thiết kế để gần như sắp xếp theo thời gian. Nếu bạn sắp xếp theo ULID (dưới dạng chuỗi hoặc dạng binary), các mục mới thường đến sau các mục cũ hơn. Điều này làm cho phân trang cursor đơn giản hơn vì cursor có thể là ULID cuối cùng nhìn thấy.

ULID mang lại gì (và không mang lại)

ULID giúp thứ tự dạng thời gian cho feed, cursor đơn giản hơn và giảm chèn ngẫu nhiên so với UUIDv4.

Nhưng ULID không đảm bảo thứ tự thời gian chính xác khi nhiều ID được sinh trong cùng millisecond trên nhiều máy. Nếu bạn cần thứ tự chính xác, vẫn nên dùng một timestamp thực sự.

Khi created_at vẫn tốt hơn

Sắp xếp theo created_at thường an toàn hơn khi bạn backfill dữ liệu, import bản ghi lịch sử hoặc cần tie-break rõ ràng.

Một mẫu thực tế là order theo (created_at, id), trong đó id chỉ là tie-breaker.

Sharding sau này: tránh va chạm ID

Sharding nghĩa là chia một cơ sở dữ liệu thành nhiều cơ sở nhỏ hơn để mỗi shard chứa một phần dữ liệu. Teams thường làm điều này sau, khi một database đơn khó mở rộng hoặc trở thành điểm lỗi duy nhất.

Lựa chọn ID có thể làm sharding trở nên dễ quản lý hoặc đau đầu.

Với ID tuần tự (auto-increment serial hoặc bigint), mỗi shard sẽ vui vẻ sinh 1, 2, 3.... Cùng một ID có thể tồn tại trên nhiều shard. Lần đầu bạn cần gộp dữ liệu, di chuyển hàng, hoặc xây tính năng cross-shard, bạn sẽ gặp va chạm.

Bạn có thể tránh va chạm bằng phối hợp (dịch vụ ID trung tâm, hoặc range cho mỗi shard), nhưng điều đó thêm thành phần vận hành và có thể thành cổ chai.

UUID và ULID giảm nhu cầu phối hợp vì mỗi shard có thể sinh ID độc lập với rủi ro trùng lặp cực thấp. Nếu bạn nghĩ sẽ tách dữ liệu qua nhiều DB, đây là một trong những lý do mạnh mẽ phản đối chuỗi thuần túy.

Một kế hoạch đơn giản hoạt động (và chi phí của nó)

Một thỏa hiệp phổ biến là thêm tiền tố shard rồi dùng sequence cục bộ trên mỗi shard. Bạn có thể lưu hai cột, hoặc đóng gói vào một giá trị.

Nó hoạt động, nhưng tạo định dạng ID tùy chỉnh. Mọi tích hợp phải hiểu nó, sắp xếp ngừng mang ý nghĩa thời gian toàn cục nếu không có logic thêm, và di chuyển dữ liệu giữa các shard có thể yêu cầu viết lại ID (làm hỏng các tham chiếu nếu ID đó được chia sẻ).

Hỏi một câu sớm: bạn có bao giờ cần kết hợp dữ liệu từ nhiều DB và giữ tham chiếu ổn định? Nếu có, hãy lên kế hoạch cho ID toàn cục từ ngày đầu, hoặc dự trù chi phí cho migration sau này.

Quy trình xuất và nhập dữ liệu

Export/import là nơi lựa chọn ID ngừng là lý thuyết. Ngay khi bạn clone prod sang staging, khôi phục backup hoặc gộp dữ liệu từ hai hệ thống, bạn sẽ biết ID của mình có ổn định và di động hay không.

Với serial (auto-increment), bạn thường không thể replay insert vào DB khác và mong tham chiếu còn nguyên trừ khi giữ nguyên các số. Nếu bạn import chỉ một phần hàng (ví dụ 200 khách hàng và đơn hàng của họ), bạn phải load các bảng theo thứ tự đúng và giữ nguyên primary key. Nếu bất cứ thứ gì bị đánh số lại, foreign key sẽ vỡ.

UUID và ULID được sinh bên ngoài sequence của DB, nên dễ di chuyển giữa môi trường hơn. Bạn có thể copy hàng, giữ ID và quan hệ vẫn khớp. Điều này hữu ích khi khôi phục backup, export một phần, hoặc gộp dataset.

Ví dụ: xuất 50 account từ production để debug trên staging. Với UUID/ULID làm khóa chính, bạn có thể import những account đó cùng các hàng liên quan (project, invoice, log) và mọi thứ vẫn trỏ đúng parent. Với serial ID, bạn thường phải dựng bảng dịch (old_id -> new_id) và viết lại foreign key khi import.

Với import hàng loạt, những điều cơ bản quan trọng hơn loại ID:

• Đảm bảo importer không sinh ID mới theo mặc định.
• Import parents trước children và xác thực foreign key sau khi load.
• Nếu dùng serial, reset sequence hoặc insert tiếp theo có thể va chạm.
• Với ULID, lưu và export nhất quán (string vs binary).

Cách chọn trong 10 phút

Bạn có thể quyết định vững vàng nhanh nếu tập trung vào điều gì sẽ gây đau sau này.

1. Ghi ra rủi ro tương lai hàng đầu. Những sự kiện cụ thể giúp: tách thành nhiều DB, gộp dữ liệu từ hệ thống khác, ghi offline, sao chép dữ liệu giữa môi trường.

2. Quyết xem ID có phải cần khớp thứ tự thời gian không. Nếu muốn "mới nhất trước" mà không cần cột khác, ULID (hoặc ID sắp xếp theo thời gian khác) là phù hợp. Nếu bạn chấp nhận sắp xếp theo created_at, UUID và serial đều ổn.

3. Ước lượng lượng ghi và độ nhạy index. Nếu mong nhiều insert và chỉ mục khóa chính bị băm, serial BIGINT thường nhẹ nhàng với B-tree. UUID ngẫu nhiên gây nhiều churn hơn.

4. Chọn một mặc định, rồi ghi lại ngoại lệ. Giữ đơn giản: một mặc định cho hầu hết bảng, và quy tắc rõ ràng khi bạn thoát (thường: ID công khai vs ID nội bộ).

5. Để chỗ thay đổi. Tránh mã hóa ý nghĩa vào ID, quyết nơi sinh ID (DB hay app), và giữ constraint rõ ràng.

Sai lầm phổ biến và bẫy

Cái bẫy lớn nhất là chọn ID vì nó phổ biến, rồi phát hiện nó mâu thuẫn với cách bạn truy vấn, scale hoặc chia sẻ dữ liệu. Hầu hết vấn đề xuất hiện sau vài tháng.

Các thất bại thường gặp:

• Dùng UUID khắp nơi mà không kiểm tra chi phí. UUIDv4 có thể phình to index và giảm độ thân thiện cache. App vẫn chạy, nhưng bạn trả giá bằng ghi chậm hơn và backup lớn hơn.
• Dựa vào serial rồi cần gộp dữ liệu từ nhiều hệ thống, vùng hoặc shard. Va chạm lộ ra khi import hoặc sync, và các fix nhanh như offset/prefix dễ bị rò rỉ vào mọi tích hợp.
• Giả định ULID làm mọi thứ nhanh hơn. Nó giúp thứ tự chèn và phân trang theo thời gian, nhưng không giải quyết join chậm, thiếu index hay row rộng. Một vài generator cũng không tuyệt đối đơn điệu dưới tải cao.
• Tiết lộ ID tuần tự công khai. Nếu URL hoặc API của bạn dùng 123, 124, 125, người ta có thể đoán các bản ghi gần kề và quét hệ thống.
• Thay đổi loại ID giữa dự án mà không có kế hoạch migration. Foreign key, cache, log và payload ngoài có thể vẫn tham chiếu ID cũ lâu sau khi bạn nghĩ mình đã chuyển.

Dấu hiệu cảnh báo bạn nên xử lý sớm:

• Bạn dự kiến import từ đối tác hoặc thường xuyên gộp dữ liệu giữa môi trường.
• Bạn cần phân trang theo thời gian mà không muốn phụ thuộc cột timestamp.
• Bạn dự định chia sẻ ID ra ngoài hệ thống (URL, webhook, app di động).
• Bạn không thể chịu downtime cho migration lớn.
• Bạn mong bảng rất lớn nơi kích thước index và tốc độ ghi quan trọng.

Checklist nhanh trước khi chốt

Thực tế database và truy vấn

Chọn một kiểu khóa chính và giữ nó cho hầu hết bảng. Trộn kiểu (bigint ở chỗ này, UUID ở chỗ kia) làm cho join, API và migration khó hơn.

Ước tính kích thước index ở quy mô dự kiến. Khóa rộng hơn nghĩa là primary index lớn hơn và tốn IO/RAM.

Quyết cách phân trang. Nếu phân trang theo ID, đảm bảo ID có thứ tự dự đoán (hoặc chấp nhận rằng nó không có). Nếu phân trang theo timestamp, index created_at và dùng nhất quán.

Kiểm tra tương lai

Thử kế hoạch import trên dữ liệu giống production. Xác minh bạn có thể tái tạo bản ghi mà không phá foreign key và re-import không âm thầm sinh ID mới.

Ghi ra chiến lược tránh va chạm. Ai sinh ID (DB hay app), và chuyện gì xảy ra nếu hai hệ thống tạo bản ghi offline rồi sync sau?

Đảm bảo URL công khai và log không lộ các mẫu bạn quan tâm (số lượng bản ghi, tốc độ tạo, dấu hiệu shard nội bộ). Nếu dùng serial, giả sử người ta có thể đoán ID gần kề.

Ví dụ thực tế: từ MVP đến dữ liệu đa hệ thống

Một founder đơn lẻ ra mắt CRM đơn giản: contacts, deals, notes. Một Postgres, một web app, mục tiêu chính là ra mắt.

Ban đầu, khóa chính serial bigint có vẻ hoàn hảo. Insert nhanh, index gọn, dễ đọc trong log.

Một năm sau, khách hàng yêu cầu export quý để kiểm toán, và founder bắt đầu import lead từ tool marketing. ID từng chỉ nội bộ giờ xuất hiện trong CSV, email và ticket. Nếu hai hệ thống đều dùng 1, 2, 3..., việc gộp trở nên lộn xộn. Bạn phải thêm cột nguồn, bảng mapping hoặc viết lại ID khi import.

Đến năm hai, có app di động cần tạo bản ghi offline rồi sync. Bạn cần ID có thể sinh trên client mà không hỏi DB và rủi ro va chạm thấp khi dữ liệu về nhiều môi trường.

Một thỏa hiệp thường bền:

• Giữ khóa chính bigint cho join nội bộ và hiệu năng lưu trữ.
• Thêm một ID công khai bất biến (ULID, hoặc UUIDv7 nếu có) cho việc chia sẻ, sync và import.
• Dùng ID công khai trong file export và làm khóa ghép giữa các hệ thống.

Bước thực tế tiếp theo cho dự án của bạn

Nếu phân vân giữa UUID, ULID và serial, quyết dựa trên cách dữ liệu di chuyển và tăng trưởng.

Một câu cho từng trường hợp phổ biến:

• Công cụ nội bộ với một DB và ít rủi ro tích hợp: dùng bigint serial làm khóa chính.
• Ứng dụng công khai có URL chia sẻ hoặc tạo trên client: dùng UUID (khó đoán, an toàn trên nhiều hệ thống).
• SaaS có thể tách theo tenant hoặc vùng sau này: dùng ULID (hoặc UUIDv7) để hàng mới thường nằm gần nhau trong index.
• Nhiều import từ đối tác và thiết bị offline: tránh serial thuần cho thực thể có thể xuất ra ngoài.

Thường là trộn lẫn tốt nhất. Dùng serial bigint cho bảng nội bộ không rời DB (join table, job nền), và dùng UUID/ULID cho thực thể công khai như users, orgs, invoices và bất cứ thứ gì có thể export, sync hoặc tham chiếu từ dịch vụ khác.

Nếu bạn xây trên Koder.ai (koder.ai), đáng để quyết mẫu ID trước khi tạo nhiều bảng và API. Chế độ lập kế hoạch và snapshot/rollback của nền tảng giúp áp dụng và kiểm tra thay đổi schema sớm, khi hệ thống còn nhỏ và dễ chỉnh sửa.