UUID v4 vs v7: który unikalny identyfikator wybrać?

UUID to 128-bitowy unikalny identyfikator bez centralnej koordynacji. Wersja 4, całkowicie losowa, dominuje od lat. Wersja 7, nowsza (RFC 9562, 2024), zawiera znacznik czasu na początku, aby produkować identyfikatory uporządkowane w czasie. Ta różnica, pozornie nieszkodliwa, radykalnie zmienia wydajność w bazie danych. Oto którą wybrać.

Czym jest UUID?

UUID (Universally Unique Identifier) to liczba 128-bitowa reprezentowana przez 32 znaki szesnastkowe pogrupowane w pięć bloków, na przykład 550e8400-e29b-41d4-a716-446655440000. Jego racja bytu: generowanie unikalnego identyfikatora bez odpytywania centralnego urzędu, co czyni go idealnym dla systemów rozproszonych. Możesz je generować naszym generatorem UUID.

Istnieje wiele wersji; najbardziej istotne dziś dla kluczy rekordów to v4 (losowa) i v7 (uporządkowana w czasie).

UUID v4 (losowy)

UUID v4 składa się ze 122 losowych bitów (reszta koduje wersję i wariant). Prawdopodobieństwo kolizji jest tak niskie, że w praktyce jest pomijalne. To wersja domyślna w większości języków i bibliotek.

• Nieprzewidywalny: idealny dla tokenów lub publicznych identyfikatorów, których nie chcemy odgadywalnych
• Brak wycieku informacji: nie ujawnia ani daty, ani kolejności utworzenia
• Wada: całkowicie nieuporządkowany, co szkodzi indeksom bazy danych

UUID v7 (uporządkowany w czasie)

UUID v7 umieszcza znacznik czasu Unix w milisekundach na pierwszych 48 bitach, po którym następują bity losowe. Dwa UUID v7 wygenerowane w różnych momentach sortują się więc w kolejności ich utworzenia, pozostając unikalne i praktycznie niemożliwe do odgadnięcia.

• Sortowalny: porządek leksykograficzny odpowiada porządkowi chronologicznemu
• Przyjazny indeksom: wstawienia odbywają się na końcu indeksu, jak auto-increment
• Druga strona medalu: ujawnia moment utworzenia, co może być niepożądane dla identyfikatora publicznego

Tabela porównawcza

Wpływ na bazy danych

To sedno sprawy. Bazy relacyjne przechowują swoje indeksy w drzewach B (B-tree). Wstawianie losowych kluczy (v4) rozprasza zapisy po całym indeksie, powodując fragmentację, podziały stron i mniej wydajną pamięć podręczną. Przy dużych wolumenach wydajność wstawiania wyraźnie się pogarsza.

Uporządkowane klucze (v7) wstawiają się zawsze na końcu indeksu, jak identyfikator auto-increment. Otrzymujesz szybkie wstawienia, lepszą lokalność i bardziej kompaktowy indeks. Jest to szczególnie widoczne przy kluczu głównym w InnoDB (MySQL), gdzie klucz główny określa fizyczną kolejność wierszy.

Kiedy wybrać jedną lub drugą

Wybierz UUID v4, gdy

• Identyfikator jest wystawiony publicznie i nie może niczego ujawniać
• Generujesz tokeny, linki udostępniania, sekrety
• Kolejność i data utworzenia nie mogą być odgadywalne
• Chcesz maksymalnej kompatybilności z istniejącym

Wybierz UUID v7, gdy

• UUID służy jako klucz główny w bazie danych
• Wolumen wstawień jest wysoki, a wydajność indeksu się liczy
• Chcesz sortować według kolejności utworzenia bez dedykowanej kolumny
• Ujawnienie momentu utworzenia nie stanowi problemu

Zalecenie

Dla klucza głównego bazy danych preferuj odtąd UUID v7: zachowujesz rozproszoną unikalność UUID, unikając jednocześnie kary indeksowej v4. Zachowaj UUID v4 dla publicznych identyfikatorów, tokenów i sekretów, gdzie liczy się całkowita nieprzewidywalność i brak wycieku czasowego.

Sprawdź jednak wsparcie v7 w swoim języku i ORM: RFC jest nowe, ale adopcja postępuje szybko.

Najczęściej zadawane pytania