Khi nào bạn thực sự buộc phải sử dụng UUID như một phần của thiết kế?

Tôi không thực sự thấy điểm của UUID . Tôi biết xác suất va chạm thực sự là con số không , nhưng thực sự là con số không thậm chí không gần đến mức không thể.

Ai đó có thể đưa ra một ví dụ mà bạn không có lựa chọn nào khác ngoài việc sử dụng UUID không? Từ tất cả các cách sử dụng tôi đã thấy, tôi có thể thấy một thiết kế thay thế mà không có UUID. Chắc chắn thiết kế có thể phức tạp hơn một chút, nhưng ít nhất nó không có xác suất thất bại là không.

Đối với tôi, UUID giống như các biến toàn cục. Có nhiều cách biến toàn cục giúp thiết kế đơn giản hơn, nhưng thiết kế lười biếng của nó.

Tôi đã viết trình tạo / phân tích cú pháp UUID cho Ruby, vì vậy tôi tự cho mình là người hiểu rõ về chủ đề này. Có bốn phiên bản UUID chính:

Các UUID phiên bản 4 về cơ bản chỉ là 16 byte ngẫu nhiên được lấy từ một trình tạo số ngẫu nhiên an toàn bằng mật mã, với một số thao tác chỉnh sửa bit để xác định phiên bản và biến thể của UUID. Những điều này cực kỳ khó xảy ra va chạm, nhưng nó có thể xảy ra nếu một PRNG được sử dụng hoặc nếu bạn chỉ thực sự, thực sự, thực sự, thực sự rất xui xẻo.

UUID phiên bản 5 và phiên bản 3 sử dụng hàm băm SHA1 và MD5 tương ứng để kết hợp không gian tên với một phần dữ liệu đã có duy nhất để tạo UUID. Ví dụ, điều này sẽ cho phép bạn tạo UUID từ một URL. Xung đột ở đây chỉ có thể xảy ra nếu hàm băm bên dưới cũng có xung đột.

UUID phiên bản 1 là phổ biến nhất. Chúng sử dụng địa chỉ MAC của card mạng (địa chỉ này trừ khi bị giả mạo, phải là địa chỉ duy nhất), cộng với dấu thời gian, cộng với việc xoay bit thông thường để tạo UUID. Trong trường hợp máy không có địa chỉ MAC, 6 byte nút được tạo bằng trình tạo số ngẫu nhiên an toàn bằng mật mã. Nếu hai UUID được tạo theo trình tự đủ nhanh để dấu thời gian khớp với UUID trước đó, thì dấu thời gian sẽ tăng lên 1. Sẽ không xảy ra xung đột trừ khi một trong những điều sau xảy ra: Địa chỉ MAC bị giả mạo; Một máy chạy hai ứng dụng tạo UUID khác nhau tạo ra các UUID tại cùng một thời điểm; Hai máy không có card mạng hoặc không có quyền truy cập cấp người dùng vào địa chỉ MAC được cung cấp cùng một chuỗi nút ngẫu nhiên và tạo ra các UUID tại cùng một thời điểm;

Thực tế, không có sự kiện nào trong số này xảy ra một cách tình cờ trong không gian ID của một ứng dụng. Trừ khi bạn đang chấp nhận ID trên quy mô toàn Internet hoặc với một môi trường không đáng tin cậy, nơi các cá nhân độc hại có thể làm điều gì đó xấu trong trường hợp xung đột ID, đó không phải là điều bạn nên lo lắng. Điều quan trọng là phải hiểu rằng nếu bạn tình cờ tạo UUID phiên bản 4 giống như tôi, trong hầu hết các trường hợp, điều đó không thành vấn đề. Tôi đã tạo ID trong không gian ID hoàn toàn khác với ID của bạn. Ứng dụng của tôi sẽ không bao giờ biết về vụ va chạm nên va chạm không thành vấn đề. Thành thật mà nói, trong một không gian ứng dụng duy nhất mà không có tác nhân độc hại, sự tuyệt chủng của tất cả sự sống trên trái đất sẽ xảy ra rất lâu trước khi bạn có va chạm, ngay cả trên UUID phiên bản 4, ngay cả khi bạn '

Ngoài ra, 2 ^ 64 * 16 là 256 exabyte. Như trong, bạn sẽ cần lưu trữ 256 exabyte ID trị giá trước khi bạn có 50% khả năng xảy ra xung đột ID trong một không gian ứng dụng.

Điều mà các UUID mua cho bạn mà rất khó làm khác là có được một số nhận dạng duy nhất mà không cần phải hỏi ý kiến ​​hoặc phối hợp với cơ quan trung ương . Vấn đề chung của việc có thể có được một thứ như vậy mà không có một số loại cơ sở hạ tầng được quản lý là vấn đề mà các UUID giải quyết.

Tôi đã đọc rằng theo nghịch lý sinh nhật, khả năng xảy ra va chạm UUID là 50% khi 2 ^ 64 UUID đã được tạo. Bây giờ 2 ^ 64 là một con số khá lớn, nhưng 50% khả năng va chạm dường như quá rủi ro (ví dụ: cần có bao nhiêu UUID để tồn tại trước khi có 5% cơ hội va chạm - thậm chí đó có vẻ như là quá lớn so với xác suất) .

Vấn đề với phân tích đó là gấp đôi:

1. UUID không hoàn toàn ngẫu nhiên - có các thành phần chính của UUID dựa trên thời gian và / hoặc vị trí. Vì vậy, để có bất kỳ cơ hội thực sự nào xảy ra va chạm, các UUID va chạm cần phải được tạo chính xác cùng lúc từ các trình tạo UUID khác nhau. Tôi muốn nói rằng mặc dù có khả năng hợp lý là một số UUID có thể được tạo cùng một lúc, nhưng vẫn có đủ thứ khác (bao gồm thông tin vị trí hoặc các bit ngẫu nhiên) để làm cho tương tự như một vụ va chạm giữa một tập hợp rất nhỏ các UUID này gần như không thể xảy ra .

2. nói đúng ra, UUID chỉ cần là duy nhất trong số các UUID khác mà chúng có thể được so sánh với nhau. Nếu bạn đang tạo một UUID để sử dụng làm khóa cơ sở dữ liệu, sẽ không thành vấn đề nếu ở một nơi nào khác trong vũ trụ thay thế độc ác có cùng một UUID đang được sử dụng để xác định giao diện COM. Giống như nó sẽ không gây nhầm lẫn nếu có ai đó (hoặc cái gì đó) khác tên là "Michael Burr" trên Alpha-Centauri.

Mọi thứ đều có cơ hội thất bại không phải bằng không. Tôi sẽ tập trung vào nhiều khả năng xảy ra sự cố (tức là hầu hết mọi thứ bạn có thể nghĩ đến) hơn là sự va chạm của các UUID

Nhấn mạnh vào "hợp lý" hoặc, như bạn nói, "hiệu quả": đủ tốt là cách thế giới thực hoạt động. Số lượng công việc tính toán liên quan đến việc che phủ khoảng cách giữa "thực tế duy nhất" và "thực sự duy nhất" là rất lớn. Tính duy nhất là một đường cong với lợi nhuận giảm dần. Tại một thời điểm nào đó trên đường cong đó, có một ranh giới giữa nơi "đủ duy nhất" vẫn có giá cả phải chăng, và khi đó chúng ta đường cong RẤT dốc. Chi phí để tăng thêm tính độc đáo trở nên khá lớn. Tính duy nhất vô hạn có chi phí vô hạn.

Nói một cách tương đối, UUID / GUID là một cách nhanh chóng và dễ dàng về mặt tính toán để tạo một ID có thể được giả định một cách hợp lý là duy nhất trên toàn cầu. Điều này rất quan trọng trong nhiều hệ thống cần tích hợp dữ liệu từ các hệ thống chưa được kết nối trước đó. Ví dụ: nếu bạn có Hệ thống quản lý nội dung chạy trên hai nền tảng khác nhau, nhưng tại một số điểm cần nhập nội dung từ hệ thống này vào hệ thống kia. Bạn không muốn ID thay đổi, do đó, các tham chiếu của bạn giữa dữ liệu từ hệ thống A vẫn còn nguyên vẹn, nhưng bạn không muốn có bất kỳ va chạm nào với dữ liệu được tạo trong hệ thống B. A UUID giải quyết điều này.

Việc tạo UUID không bao giờ thực sự cần thiết. Tuy nhiên, thật tiện lợi khi có một tiêu chuẩn trong đó mỗi người dùng ngoại tuyến có thể tạo khóa cho một thứ gì đó với xác suất va chạm rất thấp.

Điều này có thể hỗ trợ giải quyết sao chép cơ sở dữ liệu, v.v.

Người dùng trực tuyến sẽ dễ dàng tạo các khóa duy nhất cho một thứ gì đó mà không có chi phí cao hoặc khả năng xảy ra va chạm, nhưng đó không phải là những gì UUID dành cho.

Dù sao, một từ về xác suất va chạm, lấy từ Wikipedia:

Để xem xét những con số này, rủi ro hàng năm của một người bị thiên thạch va vào ước tính là một trong 17 tỷ cơ hội, tương đương với khả năng tạo ra vài chục nghìn tỷ UUID trong một năm và có một bản sao. Nói cách khác, chỉ sau khi tạo ra 1 tỷ UUID mỗi giây trong 100 năm tới, xác suất chỉ tạo ra một bản sao sẽ là khoảng 50%.

Một ví dụ cổ điển là khi bạn đang sao chép giữa hai cơ sở dữ liệu.

DB (A) chèn một bản ghi với int ID 10 và đồng thời DB (B) tạo một bản ghi aa với trong ID 10. Đây là một xung đột.

Với UUID, điều này sẽ không xảy ra vì chúng sẽ không khớp. (gần như chắc chắn)

Cũng có một xác suất khác không là mọi hạt trong cơ thể bạn sẽ đồng thời xuyên qua chiếc ghế bạn đang ngồi và bạn sẽ đột nhiên thấy mình đang ngồi trên sàn.

Bạn có lo lắng về điều đó?

Tôi có một kế hoạch để tránh UUID. Thiết lập một máy chủ ở đâu đó và có nó để mỗi khi một phần mềm nào đó muốn một số nhận dạng duy nhất trên toàn cầu, chúng sẽ liên hệ với máy chủ đó và nó sẽ phân phát một. Đơn giản!

Ngoại trừ việc có một số vấn đề thực tế thực sự với điều này, ngay cả khi chúng tôi hoàn toàn bỏ qua ác ý. Đặc biệt, máy chủ đó có thể bị lỗi hoặc không thể truy cập được từ một phần của Internet. Đối phó với lỗi máy chủ đòi hỏi phải nhân rộng và điều đó rất khó để làm đúng (xem tài liệu về thuật toán Paxos để biết lý do tại sao xây dựng sự đồng thuận là khó xử) và cũng khá chậm. Hơn nữa, nếu tất cả các máy chủ không thể truy cập được từ một phần cụ thể của 'net, thì không máy khách nào được kết nối với mạng con đó sẽ có thể làm bất cứ điều gì bởi vì tất cả họ sẽ chờ ID mới.

Vì vậy, ... hãy sử dụng một thuật toán xác suất đơn giản để tạo ra chúng mà không có khả năng bị lỗi trong thời gian tồn tại của Trái đất, hoặc (quỹ và) xây dựng một cơ sở hạ tầng chính sẽ trở thành PITA triển khai và thường xuyên gặp lỗi. Tôi biết tôi sẽ chọn cái nào.

tôi không nhận được tất cả các cuộc nói chuyện về khả năng va chạm. Tôi không quan tâm đến va chạm. Tôi quan tâm đến hiệu suất mặc dù.

https://dba.stackexchange.com/a/119129/33649

UUID là một thảm họa về hiệu suất cho các bảng rất lớn. (200K hàng không phải là "rất lớn".)

Số 3 của bạn thực sự tệ khi BỘ SẠC là utf8 - CHAR (36) chiếm 108 byte!

UUID (GUID) rất "ngẫu nhiên". Sử dụng chúng như một khóa DUY NHẤT hoặc CHÍNH XÁC trên các bảng lớn là rất kém hiệu quả. Điều này là do bạn phải nhảy xung quanh bảng / chỉ mục mỗi khi bạn CHÈN UUID mới hoặc CHỌN theo UUID. Khi bảng / chỉ mục quá lớn để vừa với bộ nhớ cache (xem innodb_buffer_pool_size, phải nhỏ hơn RAM, thường là 70%), UUID 'tiếp theo' có thể không được lưu vào bộ nhớ cache, do đó đĩa bị chậm. Khi bảng / chỉ mục lớn gấp 20 lần bộ nhớ cache, chỉ 1/20 (5%) lần truy cập được lưu vào bộ nhớ đệm - bạn bị ràng buộc I / O.

Vì vậy, không sử dụng UUID trừ khi

bạn có các bảng "nhỏ" hoặc bạn thực sự cần chúng vì tạo id duy nhất từ ​​những nơi khác nhau (và chưa tìm ra cách khác để thực hiện). Thông tin thêm về UUID: http://mysql.rjweb.org/doc.php/uuid (Nó bao gồm các chức năng để chuyển đổi giữa UUID 36-char tiêu chuẩn và BINARY (16).)

Có cả AUTO_INCREMENT DUY NHẤT và UUID DUY NHẤT trong cùng một bảng là một sự lãng phí.

Khi một INSERT xảy ra, tất cả các khóa chính / duy nhất phải được kiểm tra xem có trùng lặp không. Một trong hai khóa duy nhất là đủ cho yêu cầu của InnoDB về việc có một KHÓA CHÍNH. BINARY (16) (16 byte) hơi cồng kềnh (một lập luận chống lại việc biến nó thành PK), nhưng không đến nỗi tệ. Sự cồng kềnh quan trọng khi bạn có khóa phụ. InnoDB âm thầm gắn PK vào cuối mỗi khóa phụ. Bài học chính ở đây là giảm thiểu số lượng khóa phụ, đặc biệt là đối với các bảng rất lớn. Để so sánh: INT UNSIGNED là 4 byte với phạm vi 0..4 tỷ. BIGINT là 8 byte.

Nếu bạn chỉ xem xét các lựa chọn thay thế, ví dụ như đối với một ứng dụng cơ sở dữ liệu đơn giản, phải truy vấn cơ sở dữ liệu mỗi lần trước khi bạn tạo một đối tượng mới, bạn sẽ sớm thấy rằng việc sử dụng UUID có thể làm giảm độ phức tạp của hệ thống một cách hiệu quả. Được cấp - nếu bạn sử dụng các khóa int là 32bit, sẽ lưu trữ trong một phần tư UUID 128bit. Granted - Các thuật toán tạo UUID chiếm nhiều sức mạnh tính toán hơn là chỉ tăng một số. Nhưng, ai quan tâm? Chi phí quản lý một "thẩm quyền" để chỉ định các số duy nhất khác dễ dàng vượt quá số đó theo thứ tự độ lớn, tùy thuộc vào không gian ID duy nhất dự định của bạn.

Trên UUID == thiết kế lười biếng

Tôi không đồng ý về việc chọn chiến đấu của bạn. Nếu một UUID trùng lặp là không thể về mặt thống kê và các phép toán đã được chứng minh thì tại sao phải lo lắng? Dành thời gian thiết kế xung quanh hệ thống tạo N UUID nhỏ của bạn là không thực tế, luôn có hàng tá cách khác để bạn có thể cải thiện hệ thống của mình.

Trong công việc cuối cùng của tôi, chúng tôi đã nhận được các đối tượng từ bên thứ ba được xác định duy nhất bằng UUID. Tôi đặt UUID-> bảng tra cứu số nguyên dài và sử dụng số nguyên dài làm khóa chính của mình vì cách đó nhanh hơn.

Sử dụng thuật toán phiên bản 1, có vẻ như không thể xảy ra xung đột dưới ràng buộc rằng ít hơn 10 UUID mỗi mili giây được tạo từ cùng một địa chỉ MAC

Về mặt khái niệm, sơ đồ tạo (phiên bản 1) ban đầu cho UUID là để ghép phiên bản UUID với địa chỉ MAC của máy tính đang tạo UUID và với số khoảng cách 100 nano giây kể từ khi áp dụng lịch Gregory ở phương Tây . Trong thực tế, thuật toán thực tế phức tạp hơn. Đề án này đã bị chỉ trích ở chỗ nó không đủ 'mờ đục'; nó tiết lộ cả danh tính của máy tính đã tạo UUID và thời gian nó làm như vậy.

Ai đó sửa cho tôi nếu tôi hiểu sai cách nó hoạt động

Đối với những người nói rằng UUID có thiết kế tồi vì chúng có thể (với một xác suất nhỏ đến mức nực cười), trong khi các khóa do DB tạo của bạn sẽ không ... -cần mười bảy là FAR FAR FAR cao hơn khả năng va chạm của UUID4. Chúng tôi biết rằng nếu db được tạo lại, nó sẽ bắt đầu lại id ở mức 1, và bao nhiêu người trong chúng tôi đã phải tạo lại một bảng khi chúng tôi chắc chắn rằng chúng tôi sẽ không bao giờ cần đến? Tôi đã đặt tiền của mình vào sự an toàn UUID khi mọi thứ bắt đầu trục trặc với những ẩn số không xác định bất kỳ ngày nào.

Ngoài những trường hợp bạn phải sử dụng API của người khác yêu cầu UUID, tất nhiên luôn có một giải pháp khác. Nhưng liệu những lựa chọn thay thế đó có giải quyết được tất cả các vấn đề mà UUID gây ra không? Bạn sẽ kết thúc thêm nhiều lớp hack, mỗi lớp để giải quyết một vấn đề khác nhau, khi bạn có thể giải quyết tất cả chúng cùng một lúc?

Có, về mặt lý thuyết, các UUID có thể xảy ra va chạm. Như những người khác đã lưu ý, nó không có khả năng xảy ra một cách nực cười đến mức nó không đáng xem xét. Nó chưa bao giờ xảy ra cho đến nay và rất có thể sẽ không bao giờ. Quên nó đi.

Cách "rõ ràng" nhất để tránh va chạm là để một máy chủ duy nhất tạo ID duy nhất trên mỗi lần chèn, điều này rõ ràng tạo ra các vấn đề hiệu suất nghiêm trọng và không giải quyết được vấn đề tạo ngoại tuyến. Giáo sư.

Giải pháp "hiển nhiên" khác là một cơ quan trung ương phân phát trước các khối số duy nhất, về cơ bản đây là những gì UUID V1 thực hiện bằng cách sử dụng địa chỉ MAC của máy tạo (thông qua IEEE OUI). Nhưng các địa chỉ MAC trùng lặp vẫn xảy ra bởi vì mọi cơ quan trung ương cuối cùng đều đóng chặt, vì vậy trong thực tế, điều này có khả năng xảy ra cao hơn nhiều so với xung đột UUID V4. Giáo sư.

Lập luận tốt nhất để chống lại việc sử dụng UUID là chúng "quá lớn", nhưng một lược đồ nhỏ hơn (đáng kể) chắc chắn sẽ không giải quyết được các vấn đề thú vị nhất; Kích thước của UUID là một tác dụng phụ cố hữu của tính hữu ích của chúng trong việc giải quyết những vấn đề đó.

Có thể vấn đề của bạn không đủ lớn để cần những gì UUID cung cấp và trong trường hợp đó, hãy sử dụng thứ khác. Nhưng nếu vấn đề của bạn phát triển một cách bất ngờ (và hầu hết đều xảy ra), bạn sẽ phải chuyển đổi sau đó - và khiến bản thân không sử dụng chúng ngay từ đầu. Tại sao phải thiết kế để thất bại trong khi thiết kế thành công cũng dễ dàng như vậy?

UUID là hiện thân của tất cả các phương pháp mã hóa tồi liên quan đến các biến toàn cục, chỉ tệ hơn, vì chúng là các biến siêu toàn cầu có thể được phân phối trên các phần khác nhau của bộ công cụ.

Gần đây đã gặp phải một vấn đề như vậy với việc thay thế một máy in bằng mô hình thay thế chính xác và nhận thấy rằng không có phần mềm máy khách nào hoạt động.