UUID v4 vs v7: losowe ID czy ID uporządkowane w czasie
Poradnik UUID v4 vs v7
UUID v4 vs v7 (oraz GUID vs UUID): którego użyć | We.Inc
Czym UUID v7 różni się od v4 według RFC 9562, dlaczego ID uporządkowane w czasie pasują do kluczy w bazie danych, czym jest GUID, oraz narzędzie w przeglądarce do tworzenia ID v4 i v7 i dekodowania znacznika czasu v7.
Oba to 128-bitowe identyfikatory zapisywane jako 36 znaków. UUID v4 to 122 losowe bity, więc nowe wartości trafiają w dowolne miejsce posortowanego indeksu. UUID v7 zaczyna się od 48-bitowego znacznika czasu Unix w milisekundach, po którym następują losowe bity, więc wartości sortują się mniej więcej według czasu utworzenia. RFC 9562 zaleca v7 zamiast starszych, opartych na czasie v1 i v6.
Porównanie v4 i v7
UUID v4
UUID v7
Zbudowany z
122 losowych bitów
48-bitowego znacznika czasu w milisekundach plus 74 losowych bitów
Kolejność sortowania
Losowa
Mniej więcej według czasu utworzenia
Ujawnia czas utworzenia
Nie
Tak, z dokładnością do milisekundy
Wbudowany w przeglądarki
crypto.randomUUID()
Nie, użyj kilku linii kodu lub biblioteki
Dobry do
Tokenów, publicznych ID, wszystkiego, co nie może zdradzać czasu
Kluczy głównych w bazie, logów, ID zdarzeń
Wybór wersji UUID to głównie kwestia bazy danych. Losowe klucze v4 rozpraszają wstawienia po całym indeksie, a klucze v7 przychodzą po kolei, tak jak liczba z autoinkrementacji, bez potrzeby centralnego licznika. Wygeneruj poniżej oba rodzaje, a potem wklej dowolny UUID, aby zobaczyć jego wersję, a dla v7 moment utworzenia.
Naciśnij przycisk generowania, aby utworzyć w przeglądarce nowy UUID v4 lub v7.
Skopiuj go albo wklej dowolny UUID w pole dekodera.
Dekoder odczytuje cyfrę wersji i bity wariantu, a dla v7 zamienia pierwsze 48 bitów na datę i godzinę.
Wygeneruj kilka wartości v7 z rzędu i zauważ, że ich pierwsze znaki prawie się nie zmieniają.
Przechowuj UUID w natywnej kolumnie uuid, jeśli Twoja baza danych ją ma. Szesnaście bajtów wygrywa z 36-znakowym stringiem pod względem rozmiaru i porównań.
Nie używaj v7 tam, gdzie czas utworzenia jest wrażliwy, na przykład w tokenach resetu hasła. Każdy, kto ma ID, może odczytać, kiedy powstało.
crypto.randomUUID() działa tylko na bezpiecznych stronach (HTTPS lub localhost). Przez zwykłe HTTP nie jest dostępne.
Dwa ID v7 utworzone w tej samej milisekundzie są uporządkowane według losowych bitów, a nie według tego, które powstało pierwsze, chyba że Twoja biblioteka używa opcjonalnych metod z licznikiem opisanych w RFC.
Najczęściej zadawane pytania
Jaka jest różnica między GUID a UUID?
W praktyce żadna istotna. RFC 9562 definiuje UUID i zaznacza, że są też znane jako GUID, Globally Unique Identifiers, czyli nazwa używana w narzędziach Microsoftu. GUID wygenerowany przez .NET lub SQL Server to UUID w tym samym 36-znakowym formacie.
Czy UUID v7 to oficjalny standard?
Tak. RFC 9562, opublikowany w 2024, definiuje wersje 6, 7 i 8 obok starszych i zastępuje RFC 4122, dokument, który wcześniej opisywał UUID.
Czy UUID v7 jest wystarczająco unikalny?
Na każdą milisekundę przypada 74 losowych bitów, co wystarcza dla niemal każdego systemu. Kolizja wymagałaby ogromnej liczby ID utworzonych w dokładnie tej samej milisekundzie.
Czy mogę odzyskać czas utworzenia z UUID v7?
Tak. Pierwsze 12 cyfr szesnastkowych to czas Unix w milisekundach. Wklej UUID do dekodera powyżej, aby zobaczyć go jako datę, albo sam sparsuj te cyfry jako liczbę szesnastkową.
Czy przestawić istniejące klucze v4 na v7?
Zwykle nie. Oba są poprawnymi UUID i mogą żyć w tej samej kolumnie, więc nowe wiersze mogą używać v7, a stare zachować wartości v4. Przepisanie kluczy głównych oznacza przepisanie każdego klucza obcego, który na nie wskazuje.
Dlaczego kolejność ma znaczenie dla baz danych
Większość baz danych trzyma klucze główne w B-drzewie. Gdy każdy nowy klucz jest większy od poprzedniego, wstawienia trafiają na koniec drzewa, a ostatnio zapisane strony zostają w pamięci. Losowe klucze wymuszają zapisy do stron w całym drzewie, co przy rosnącej tabeli oznacza więcej podziałów stron i więcej odczytów z dysku.
RFC 9562 wymienia ten problem lokalności jako jeden z powodów dodania wersji uporządkowanych w czasie, a v7 to ta, którą wskazuje nowym systemom.
Jak czytać układ
W postaci tekstowej 13. cyfra szesnastkowa (pierwsza w trzeciej grupie) to wersja, więc UUID v7 zawsze ma tam 7, a v4 ma 4. Pierwsza cyfra czwartej grupy to 8, 9, a lub b dla standardowego wariantu.
W v7 12 cyfr przed wersją to znacznik czasu. Wszystko po cyfrze wersji, poza dwoma bitami wariantu, jest losowe.
Wszystkie osiem wersji UUID
Wersje UUID w RFC 9562
Wersja
Zbudowana z
Uwagi
Czas gregoriański plus ID węzła, często adres MAC
Przestarzała, wybierz v7
Wersja DCE Security, nieokreślona w RFC 9562
Rzadka
Oparta na nazwie, hash MD5 przestrzeni nazw i nazwy
To samo wejście, ten sam UUID
Losowe lub pseudolosowe bity
Typowy wybór domyślny
Oparta na nazwie, hash SHA-1 przestrzeni nazw i nazwy
Lepsza niż v3
Znacznik czasu z v1 przestawiony tak, by wartości sortowały się według czasu
W nowych systemach wybierz v7
Czas Unix Epoch w milisekundach plus losowe bity
Klucze dające się sortować
Własny układ wybrany przez implementację
Formaty eksperymentalne lub producentów
Kod do skopiowania
UUID v4 w przeglądarce lub Node
Wbudowany w aktualne przeglądarki na bezpiecznych stronach oraz w Node 19 i nowsze przez globalny obiekt crypto. Zwraca 36-znakowy string.
UUID v7 bez biblioteki
Zapisuje bieżący czas w pierwszych sześciu bajtach, a potem ustawia bity wersji i wariantu. Reszta pozostaje losowa.
Odczyt czasu z UUID v7
Pierwsze 12 cyfr szesnastkowych to milisekundy od 1970, więc ich sparsowanie daje obiekt Date.
Generuj i dekoduj
Generuj v4
Generuj v7
Wygenerowano
Naciśnij przycisk, aby utworzyć UUID. Powstaje w Twojej przeglądarce i nigdzie nie jest wysyłany.
Wklej UUID do zdekodowania
Wersja: {v}
RFC 9562 (standardowy)
Nie jest to wariant RFC 9562
Utworzono: {v} (UTC)
Ta wersja nie zawiera znacznika czasu Unix.
To nie jest UUID. Oczekiwane są 32 cyfry szesnastkowe w grupach 8-4-4-4-12.