UUID Generator (v4 & v7)
UUID v4 (rastgele) ve v7 (zaman sıralı) üretici. Tek tek veya toplu.
Bu araç tarayıcınızda çalışır. Veriler dışarı çıkmaz.
Nasıl Çalışır
UUID (Universally Unique Identifier), çakışma olasılığı pratik olarak sıfır olan 128-bit tanımlayıcılardır. Çeşitli sürümleri vardır; pratikte ikisi öne çıkar: v4 ve v7.
UUID v4
Tamamen rastgele. crypto.randomUUID() ile üretilir.
123e4567-e89b-42d3-a456-426614174000
^
version (4)Avantajı: dağıtık bir sistemde koordinasyon olmadan benzersiz ID üretebilirsiniz.
Dezavantajı: zamansal sıra yoktur. Veritabanı primary key olarak kullanıldığında B-tree index’i sürekli farklı sayfalara yazılır — insert performansı bozulur, özellikle yüksek hacimli tablolarda.
UUID v7
RFC 9562 (2024). İlk 48 bit Unix milisaniye timestamp’i, kalanı rastgele. Hâlâ benzersiz, ama zaman sıralı.
01876d10-1b21-7000-8000-000000000000
^^^^^^^^^^^^^ ^
timestamp ms version (7)DB primary key için neden v7 daha iyi:
- Tablodaki yeni satırlar B-tree’nin sonuna yazılır.
- Index split’leri azalır.
- Cache locality artar.
- Tarih bazlı sorgular index’ten yararlanabilir.
Hangi durumda hangisi?
| Durum | Tercih |
|---|---|
| Database primary key | v7 |
| API’de üretilen genel kimlikler | v7 veya v4 |
| Tahmin edilemezliğin kritik olduğu yerler (örn. session token) | v4 |
| Eski bir sistemle uyum | v4 (her yer destekliyor) |
v1, v3, v5 ne durumda?
- v1: MAC adresi + timestamp. Gizlilik açığı (cihazı sızdırıyor). Kullanmayın.
- v3, v5: bir namespace’in hash’i. Belirli bir use case için (örneğin deterministik ID lazımsa); aksi takdirde v4/v7’yi tercih edin.
Çakışma olasılığı
UUID v4 için: yılda 1 milyar UUID üretseniz bile, çakışma görmek için yaklaşık 85 yıl geçmesi gerekir. v7 için zaman parçası iki UUID’nin aynı milisaniyede üretilmiş olmasını gerektirir — rastgele kısımdaki çakışma olasılığı yine ihmal edilebilir.
Gizlilik
UUID’ler tarayıcınızda crypto.getRandomValues ile üretilir.