Her kayda merkezi bir sayaç olmadan benzersiz kimlik vermenin yolu UUID'dir. Biçimini, sürümlerini, iki kimliğin çakışma ihtimalinin gerçekte ne kadar küçük olduğunu ve veritabanında birincil anahtar olarak kullanmanın bedelini anlatıyoruz.
UUID (Universally Unique Identifier), merkezi bir sayaca sormadan üretilebilen 128 bitlik bir kimliktir. 3f2b8c1e-7a4d-4e1b-9c6a-2d5f0e8b7a91 gibi, tirelerle 8-4-4-4-12 gruplarına ayrılmış 32 on altılık rakamdan oluşur. UUID nedir sorusunun pratik cevabı şu: farklı sunucuların, cihazların ya da çevrim dışı çalışan uygulamaların birbirinden habersiz ürettiği kimliklerin çakışmamasını sağlayan standart bir biçim. Microsoft dünyasında aynı şeye GUID denir.
Birkaç tane hemen lazımsa UUID oluşturucu tek seferde 1 ile 100 arasında sürüm 4 kimlik üretir. Kimlik değil de gizli bir anahtar ya da parola gerekiyorsa doğru araç şifre oluşturucudur. İnsanların okuyacağı adresler için slug oluşturucu, kimliklerle dolu API yanıtlarını incelemek için de JSON düzenleyici işinize yarar.
Bugün geçerli tanım, Mayıs 2024'te yayımlanan ve uzun yıllar kullanılan RFC 4122'nin yerini alan RFC 9562'dedir. 128 bitin çoğu veriye ayrılır, ama iki küçük alan her kimlikte sabit yerdedir ve onun nasıl üretildiğini söyler:
| Konum | Örnekteki değer | Anlamı |
|---|---|---|
| Üçüncü grubun ilk hanesi | 4 (4e1b) | Sürüm: kimliğin üretim yöntemi |
| Dördüncü grubun ilk hanesi | 9 (9c6a) | Varyant: 8, 9, a ya da b ise standart düzendir |
| Geri kalan haneler | Rastgele ya da zamana dayalı bitler | Sürüme göre değişir |
Yani herhangi bir kimliğe bakıp sürümünü bir saniyede söyleyebilirsiniz: xxxxxxxx-xxxx-4xxx-... rastgele üretilmiştir, xxxxxxxx-xxxx-7xxx-... zamana göre sıralanabilir. İki özel değer de vardır: tamamı sıfır olan Nil UUID (00000000-0000-0000-0000-000000000000) ve RFC 9562 ile eklenen, tamamı f olan Max UUID. Standart, üretirken küçük harf kullanılmasını, okurken ise büyük/küçük harf ayrımı yapılmamasını öngörür.
Pratikte evet. GUID, Microsoft'un aynı 128 bitlik yapıya verdiği addır ve Windows araçları onu çoğunlukla süslü parantez içinde, büyük harfle gösterir: {3F2B8C1E-7A4D-4E1B-9C6A-2D5F0E8B7A91}. Dikkat edilmesi gereken tek fark ikili gösterimdedir. Windows'un GUID yapısı ilk üç alanı küçük uçlu (little-endian) bayt sırasıyla saklar. Ham 16 baytı bir .NET ya da SQL Server sisteminden başka bir sisteme taşırken ilk üç grubun baytları ters dönmüş görünüyorsa sebep budur.
| Sürüm | Neye dayanır | Sıralanabilir mi | Not |
|---|---|---|---|
| v1 | Zaman damgası ve düğüm kimliği (çoğunlukla MAC adresi) | Metin olarak hayır | Üreten makineyi ve zamanı açığa çıkarabilir |
| v3 / v5 | Ad alanı ve ad (MD5 / SHA-1 özeti) | Hayır | Aynı girdi her zaman aynı kimliği verir |
| v4 | 122 bit rastgele değer | Hayır | En yaygın sürüm |
| v6 | v1 alanlarının yeniden sıralanmış hâli | Evet | Eski v1 sistemleriyle uyum için |
| v7 | Milisaniye cinsinden Unix zamanı ve rastgele bitler | Evet | Zamana dayalı ihtiyaçlarda önerilen sürüm |
| v8 | Üreticiye bırakılmış serbest düzen | Tasarıma bağlı | Özel şemalar için |
v2 adında, eski bir dağıtık sistem standardına ait bir sürüm de vardır ama bugünkü yazılımlarda neredeyse hiç karşınıza çıkmaz. RFC 9562 de mümkün olan her durumda v1 ve v6 yerine v7 kullanılmasını tavsiye eder.
İlk sürüm, 15 Ekim 1582'den bu yana geçen 100 nanosaniyelik aralıkları sayan 60 bitlik bir zaman damgasını, bir saat dizisini ve üreten makinenin düğüm kimliğini birleştirir. Düğüm çoğu uygulamada ağ kartının MAC adresidir; bu da bir kimlikten onu hangi bilgisayarın, ne zaman ürettiğinin çıkarılabilmesi demektir. Zaman alanları ters sırada yazıldığı için metin olarak sıralandığında kronolojik bir sıra da oluşmaz.
Bugün karşılaştığınız kimliklerin büyük çoğunluğu v4'tür. 128 bitin 6'sı sürüm ve varyant için ayrılır, kalan 122 bit rastgeledir. Kimlikten hiçbir bilgi sızmaz, ama bir sıralama da yoktur. Sitedeki araç bu sürümü üretir: tarayıcıda varsa crypto.randomUUID(), yoksa aynı güvenli rastgele kaynağı (crypto.getRandomValues) kullanır. Kimlikler cihazınızda oluşur ve sunucuya gönderilmez; sayfa yalnızca anonim bir kullanım sayacını artırır.
v7, ilk 48 bite milisaniye cinsinden Unix zamanını, kalan bitlere rastgele değer koyar. 01a132dc-dfba-7aec-bf67-0d88cbe8fbc2 örneğinde ilk 12 hane (01a132dcdfba), 13 Ekim 2026 saat 01.24.58,426 (UTC) anına karşılık gelir. Bir milisaniye sonra üretilen kimlik hem metin hem sayı olarak bundan büyüktür. Bu özellik, aşağıda anlatılan veritabanı indeksi sorununu büyük ölçüde çözer. Karşılığında kimlik, kaydın oluşturulma anını açığa çıkarır; bunun sakıncalı olduğu yerlerde v4 tercih edilir.
İki kimliğin aynı çıkıp çıkamayacağı sorusunun teknik cevabı evettir; pratik cevabı, doğru üretildikleri sürece bunun için endişelenmenize gerek olmadığıdır. Hesap doğum günü paradoksuna dayanır: 23 kişilik bir sınıfta iki kişinin aynı gün doğmuş olma ihtimali yüzde 50'yi geçer, çünkü olasılık kişi sayısıyla değil, olası çiftlerin sayısıyla büyür. Kimliklerde de durum aynıdır.
Gerçek dünyadaki çakışmalar matematikten değil, kötü rastgelelikten gelir. Görülen tipik nedenler şunlardır: güvenli olmayan bir üreteçle (örneğin JavaScript'te Math.random()) yazılmış ev yapımı fonksiyonlar, aynı anlık görüntüden klonlanıp aynı rastgele durumla açılan sanal makineler ve üreteç durumunu kopyalayarak çatallanan süreçler. Dilin standart kütüphanesindeki, kriptografik kaynağa dayanan fonksiyonu kullanmak bu riskleri ortadan kaldırır.
Bir UUID kimliktir, sır değildir. RFC 9562'nin güvenlik bölümü de bu kimliklerin tahmin edilmesinin zor olduğunun varsayılmamasını ve erişim yetkisi belgesi gibi kullanılmamasını söyler. Bir v4 değeri kriptografik kaynakla üretilmiş olsa bile URL'lerde, log dosyalarında ve tarayıcı geçmişinde dolaşır. Şifre sıfırlama bağlantısı ya da API anahtarı gibi gizli değerler için uzun, rastgele ve süreli bir belirteç üretmek gerekir.
Bunun öbür yüzü de önemlidir: sıralı tam sayıların aksine v4 kimlikler /fatura/1041, /fatura/1042 diye tahmin edilerek gezilemez. Bu, kayıt sayınızı dışarıya belli etmemek ve kaba tahmin denemelerini zorlaştırmak için iyi bir yan etkidir, ama yetki kontrolünün yerini tutmaz. Bir kullanıcı başka birinin kaydının kimliğini bir şekilde öğrenirse onu yalnızca sunucudaki erişim denetimi durdurur.
| Özellik | INT / BIGINT | v4 | v7 |
|---|---|---|---|
| Boyut | 4 / 8 bayt | 16 bayt | 16 bayt |
| Üretim yeri | Veritabanı, merkezi | Her yerde, koordinasyonsuz | Her yerde, koordinasyonsuz |
| Ekleme sırası | Artan | Rastgele | Zamana göre artan |
| Tahmin edilebilirlik | Kolay | Çok zor | Zaman kısmı açık, kalanı rastgele |
| Veri setlerini birleştirme | Çakışma riski yüksek | Sorunsuz | Sorunsuz |
UUID'nin en büyük avantajı, kaydın kimliğini veritabanına yazmadan önce bilmektir. Mobil uygulama çevrim dışıyken kayıt oluşturabilir, iki farklı bölgedeki sunucu aynı tabloya yazabilir, iki şirketin müşteri listesi birleştirilebilir; hiçbirinde kimlik çakışması kaygısı yoktur.
Bedeli boyut ve indeks davranışıdır. Kimliği CHAR(36) sütununda metin olarak saklamak 16 baytlık veriyi 36 karaktere çıkarır ve her indeksi şişirir. Bunun yerine yerel tipler kullanılmalıdır: PostgreSQL'in uuid tipi 16 bayttır; 13 sürümünden beri gen_random_uuid() ile v4, 18 sürümünden itibaren uuidv7() ile v7 üretilebilir. MySQL 8'de BINARY(16) sütunu UUID_TO_BIN() ve BIN_TO_UUID() fonksiyonlarıyla kullanılır; MySQL'in UUID() fonksiyonu v1 ürettiği için UUID_TO_BIN(UUID(), 1) biçimindeki ikinci parametre zaman alanlarının yerini değiştirip değeri indeks dostu yapar.
İkinci sorun rastgeleliktir. InnoDB gibi tabloyu birincil anahtara göre kümelenmiş (clustered) tutan motorlarda v4 değerler her eklemede indeksin rastgele bir yerine yazılır; sayfa bölünmeleri artar, önbellek verimi düşer. v7'nin zamanla artan yapısı yeni kayıtları indeksin sonuna yönlendirerek bu sorunu büyük ölçüde giderir.
URL'lerde uzun duran bir kimliği kısaltmak isterseniz 16 baytı base64url ile kodlayabilirsiniz. 3f2b8c1e-7a4d-4e1b-9c6a-2d5f0e8b7a91 bu şekilde PyuMHnpNThucai1fDot6kQ olur: 36 karakter yerine 22. Bilgi kaybı yoktur, ama bu yazım standart dışı olduğu için iki tarafta da dönüşüm kodu gerekir ve veritabanında yine 16 baytlık ikili değer saklanmalıdır.
RFC 9562 üretirken küçük harf kullanılmasını, okurken ise ikisinin aynı kabul edilmesini ister. Sorun, metin karşılaştırması yapan kodda çıkar: A1B2... ile a1b2... aynı kimliktir ama eşit sayılmaz. Saklamadan önce tek biçime çevirmek bu hatayı önler.
Doğru üretilmiş v4 değerlerinde olasılık pratikte sıfırdır; bir milyar kimlikte bile 10⁻¹⁹ mertebesinin altındadır. Gerçek çakışmalar neredeyse her zaman hatalı bir rastgele üreteçten ya da aynı değerin kodda yanlışlıkla iki kayda verilmesinden kaynaklanır.
Kimlik olarak evet; sıralı numaralardan daha az bilgi verir. Ama erişim izninin yerine geçmez. Bağlantıyı bilen herkesin kaydı görmemesi gerekiyorsa sunucu tarafında yetki kontrolü şarttır.
Sitedeki araç her çalıştırmada 1 ile 100 arasında v4 kimlik üretir; varsayılan 5'tir. Daha fazlası gerekiyorsa aracı yeniden çalıştırabilir ya da kendi kodunuzda dilinizin standart fonksiyonunu kullanabilirsiniz.
Gizli anahtar ve parola üretimini ayrıntılı ele aldığımız güçlü parola ve güvenli kimlik üretimi yazısı bu konunun devamı sayılır. Kısa gösterimde kullanılan kodlamayı merak ediyorsanız Base64 nedir, kimlik taşıyan kayıtları tablo ile JSON arasında aktarıyorsanız CSV ve JSON farkı yazısına bakabilirsiniz.
