Nên dùng ID tài nguyên dạng GUID hay dạng tuần tự?
(twitter.com/dylayed)Khi cần tạo một ID để định danh duy nhất cho một tài nguyên cụ thể, tôi biết rằng thường có hai cách lớn hay được dùng. Một là dùng nguyên giá trị số nguyên tuần tự sinh ra bằng cách đặt Auto Increment cho Primary Key của bảng DB, và hai là tạo rồi sử dụng GUID (còn gọi là UUID) là một giá trị 128-bit ngẫu nhiên mỗi khi cần.
Dữ liệu của vô số dịch vụ trên web phần lớn do RDBMS đảm nhiệm, và Auto Increment của các DBMS như vậy không chỉ được tối ưu hóa ở bên trong mà còn rất dễ hiểu, dễ dự đoán từ góc nhìn của lập trình viên, đồng thời cũng đơn giản để sắp xếp theo thứ tự dữ liệu được đưa vào. Vì về cơ bản nó chỉ tăng thêm 1 vào con số mà thôi. Tuy nhiên, cách này có nhược điểm là trong một số trường hợp có thể làm lộ ra bên ngoài những thông tin không nên bị lộ vì lý do bảo mật (ví dụ đối thủ có thể dễ dàng đoán ra các chỉ số quan trọng như số lượng người dùng của dịch vụ), hoặc có thể trở thành vấn đề trong kiến trúc phân tán.
Cách dùng GUID có đặc điểm gần như trái ngược hoàn toàn với trên. Vì GUID là giá trị 128-bit gần như duy nhất, được tạo ra tại chỗ với xác suất va chạm gần như bằng 0 mà không cần phụ thuộc nào khác, nên nó không gặp vấn đề gì trong kiến trúc phân tán, đồng thời cũng không có nguy cơ vô tình làm rò rỉ ra bên ngoài những thông tin mang ý nghĩa khác. Tuy nhiên, việc ghi các giá trị tạo ngẫu nhiên vào RDBMS có thể làm giảm hiệu năng, và bản thân nó cũng không thể sắp xếp theo đúng thứ tự dữ liệu được đưa vào. Để bù đắp điểm yếu này, đôi khi người ta dùng những thứ như Timeflake, tức không hoàn toàn ngẫu nhiên mà có thêm thông tin thời gian để mang tính tuần tự không hoàn toàn. Tôi chưa trực tiếp dùng thử, nhưng nghe nói các framework như Laravel cũng sử dụng cách này.
Cá nhân tôi, khi làm ở công ty hiện tại và phát triển sản phẩm tích hợp với những thứ tích cực sử dụng GUID như Microsoft Office 365 hay Graph API, đã bắt đầu nghĩ rằng cách sử dụng GUID một cách chủ động cũng khá ổn. Nhưng rốt cuộc, chuyện như thế này sẽ thay đổi tùy vào nơi dùng và mục đích, nên tốt nhất là nắm rõ ưu và nhược điểm của từng cách. Vì vậy tôi xin giới thiệu một chuỗi tweet ghi lại nhật ký của một nhà phát triển dịch vụ giả tưởng liên quan đến chủ đề này. (tiếng Hàn)
15 bình luận
Gần đây đã xảy ra một vụ sử dụng gian lận tại Shinhan Card, và liên quan đến việc này, đã xác nhận rủi ro công ty thẻ này có thể bị lộ trước hành vi sử dụng gian lận từ nước ngoài do phát hành số thẻ tín dụng theo thứ tự tuần tự.
Chỉ thay đổi nhẹ số thẻ mà vẫn “thanh toán” được… thẻ tín dụng bị phơi bày trước nguy cơ bị đánh cắp
Cơ quan Giám sát Tài chính Hàn Quốc chuẩn bị biện pháp đối phó với các vụ sử dụng gian lận gần đây của Shinhan Card
Nhờ nhiều bạn để lại bình luận nên mình đã biết thêm khá nhiều điều trước đây chưa rõ.
Cũng nhờ vậy mà mình lần đầu biết đến những thứ như Hashids, Nano ID, hay cách Instagram sử dụng.
Có lẽ động cơ tương tự như
ulid, nhưng vì có một Internet Draft đang được đề xuất nên tôi đã dùng đặc tả này trong dự án trước đây.https://github.com/uuid6/uuid6-ietf-draft
Kiểu hệ thống ID được tạo ra theo cách này xuất hiện khá thường xuyên, và có lẽ giờ đã đến lúc ít nhất cũng nên thống nhất các dạng giống UUID về một chuẩn chung.
Nhưng mà người ta vẫn hay nói rằng, nỗ lực tạo ra một tiêu chuẩn mới để thống nhất vô số tiêu chuẩn đang hỗn loạn thành một sẽ thường chỉ tạo thêm một đối thủ cạnh tranh mới trên thị trường thôi. hahaha
https://xkcd.com/927/
Đúng vậy haha, nên có lẽ mọi người đều đang đưa ra các đề xuất
idmới.Hình như cách đây không lâu anh Gyuwon đã chia sẻ rồi, nhưng thật ra đây chẳng phải là một vấn đề đơn giản sao?
https://byterot.blogspot.com/2013/02/…
Tôi cũng muốn nghe giải thích bổ sung về ý "một vấn đề đơn giản".
Theo nghĩa nào mà bạn nói đây là một vấn đề đơn giản vậy?
Bài viết này có nói rằng, "With storage nowadays very cheap, this normally is not a problem from the storage point of view.", nhưng có vẻ vẫn có những tình huống phải từ chối UUID tùy theo bối cảnh, chẳng hạn khi
idnày phải lưu chuyển trên mạng, hoặc phải đóng vai trò key trong bộ nhớ, hay là key được dùng ở nhiều nơi với lượng dữ liệu lớn, nơi mà việc giảm đi dù chỉ vài byte cũng rất quan trọng.Vấn đề được nói trong bài này là suy giảm hiệu năng phát sinh khi dùng giá trị được tạo ngẫu nhiên làm primary key
(nếu còn có vấn đề nào khác được nhắc đến mà tôi chưa nhận ra thì hãy cho tôi biết)
Thì vấn đề đó thực ra đã có câu trả lời rồi. Nó là cùng một vấn đề như khi làm cursor based pagination theo thứ tự thời gian, nên có lẽ mọi người đều đã từng giải quyết rồi.
Tôi cũng tò mò không biết vì sao đây lại là một vấn đề phức tạp ở khía cạnh nào đó.
Vì anh/chị nói đây là tình huống cần phải từ chối nên có vẻ như là một vấn đề đơn giản mà...
Chẳng phải vấn đề phức tạp là khi không thể đưa ra quyết định theo cách nào cũng được sao?
Tôi hỏi vậy vì cụm từ "một vấn đề đơn giản" có khá nhiều cách hiểu, nên tôi tò mò không biết bạn dùng nó theo nghĩa nào. Ví dụ, có phải ý là bản thân vấn đề không khó, hay là vì bài viết đưa ra một câu trả lời rõ ràng(?) nên không còn nhiều chỗ để cân nhắc, v.v.
Về ý đầu tiên, như tôi đã nói ở trên, tùy tình huống mà có những trường hợp
idcần được dùng cả bên ngoài cơ sở dữ liệu, nên có nhiều yếu tố phải cân nhắc hơn và tôi nghĩ đây không phải là một vấn đề đơn giản.python/django cũng có thứ này https://pypi.org/project/django-hashid-field/1.0.0/
Ồ, hóa ra cũng có một cách là Hashids.
Nếu Salt bị lộ thì có thể phát sinh vấn đề làm lộ thông tin ra bên ngoài như đã nhắc tới trong bài viết ở trên, nhưng dù vậy tôi vẫn nghĩ đây là một cách hay.
Cũng có
ulid. 128 bit, có thể sắp xếp theo thứ tự thời gian.https://github.com/ulid/spec
Nhìn vào việc có quá nhiều thứ trông na ná nhau, có lẽ suy nghĩ của con người phần lớn cũng chỉ quanh quẩn bấy nhiêu đó thôi…?