UUID v8 (Evrensel Benzersiz Tanımlayıcı Sürüm 8), Internet Engineering Task Force (IETF) tarafından RFC 9562 standardında tanımlanan resmi 128 bitlik bir tanımlayıcı biçimidir. Evrensel ve katı matematiksel kurallar dayatan geleneksel UUID sürümlerinin aksine (örneğin 122 bitlik sözde rastgele entropi zorunlu kılan Sürüm 4 veya SHA-1 deterministik karmasını gerektiren Sürüm 5), Sürüm 8 özellikle özel, deneysel ve uygulamaya özgü tanımlayıcı düzenleri için tasarlanmıştır. Yazılım endüstrisindeki uzun süredir var olan bir ihtiyacı standartlaştırır: mühendislik ekiplerine ihtiyaç duydukları ikili bit alanlarını serbestçe tasarlama esnekliği sunarken, mevcut 128 bitlik veritabanı UUID sütunları, ağ protokolleri, JSON ayrıştırıcıları ve yazılım kütüphaneleriyle %100 uyumluluğu korur.

UUID v8’in belirleyici mimari özelliği, kaydı RFC uyumlu bir Sürüm 8 tanımlayıcısı olarak damgalamak için tam olarak 6 özel meta veri bitini korurken, uygulama tarafından tanımlanan tam 122 özel bit sağlamasıdır. Bu tasarım, dağıtık sistemler mühendisliğindeki kritik bir sorunu çözer: eski sistemler genellikle ayrıştırıcı doğrulama hatalarına yol açan özel ikili yükleri UUID v4’e veya geçersiz bit düzenlerine zorla yerleştirirdi. UUID v8 ile geliştiriciler, standart uyumluluğu ihlal etmeden veya normal rastgele UUID’lerle çakışma riski taşımadan özel dönem zaman damgalarını, küme düğüm kimliklerini, kiracı yönlendirme anahtarlarını veya sıra sayaçlarını güvenli bir şekilde paketleyebilirler.

UUID v8 Kaputun Altında Nasıl Çalışır?

RFC 9562’de tanımlanan tüm standart UUID’ler gibi, UUID v8 de tam olarak 128 bitten (16 bayt) oluşur ve geleneksel olarak tirelerle ayrılmış beş onaltılık blok (8-4-4-4-12) olarak biçimlendirilir: xxxxxxxx-xxxx-8xxx-yxxx-xxxxxxxxxxxx. 128 bitin 6 biti, ayrıştırıcılar tarafından evrensel tanınmayı garanti etmek amacıyla standart tarafından katı biçimde ayrılmıştır; kalan 122 bit ise tamamen uygulamanızın mantığı tarafından belirlenir. Sürüm dörtlüsü (13. onaltılık karakter) her zaman ikili 1000 (hex 8) olarak ayarlanmalıdır ve varyant alanı (17. onaltılık karakterin en yüksek anlamlı bitleri) ikili 10 (hex 8, 9, a veya b) olarak ayarlanmalıdır.

RFC 9562 Bölüm 5.8, 128 bitlik kaydı zorunlu sürüm ve varyant meta veri alanlarını çevreleyen üç farklı özel bloğa ayırır:

RFC 9562 Bölüm 5.8 Alan Dağılımı

  • custom_a: custom_a (48 bit / Sekizli 0–5): İlk 6 bayt (12 onaltılık karakter). Bu alan genellikle özel milisaniye veya mikrosaniye Unix dönemi zaman damgaları, dağıtık parça (shard) tanımlayıcıları veya birleşik kiracı önekleri gibi yüksek öncelikli uygulama verileri için kullanılır.
  • ver: ver (4 bit / Sekizli 6, Bit 4–7): 4 bitlik sürüm alanı, kalıcı olarak ikili 1000 (hex 8) değerine kilitlenmiştir. Bu dörtlüye bakan herhangi bir UUID ayrıştırıcısı tanımlayıcıyı anında Sürüm 8 olarak tanır.
  • custom_b: custom_b (12 bit / Sekizli 6 Bit 0–3 & Sekizli 7): Sürüm dörtlüsünden hemen sonraki 12 bitlik blok (3 onaltılık karakter). Sistemler genellikle bu alanı alt milisaniye yüksek çözünürlüklü sıra sayaçları, ortam kodları veya varlık türü numaralandırmaları için kullanır.
  • var: var (2 bit / Sekizli 8, Bit 6–7): 2 bitlik varyant alanı, kalıcı olarak ikili 10 değerine (onaltılık olarak 8, 9, a veya b ile temsil edilir) kilitlenmiştir. Bu, kaydı resmi IETF RFC 9562 biçimi olarak tanımlar.
  • custom_c: custom_c (62 bit / Sekizli 8 Bit 0–5 & Sekizli 9–15): Kalan 62 bit (dördüncü grubun son 2 bitini ve beşinci grubun 12 onaltılık karakterinin tamamını kaplar). Bu geniş blok kriptografik rastgele entropi, çalışan düğüm kimlikleri, monoton sayaçlar veya benzersiz işlem yükleri için idealdir.
Octet Range Field Identifier Bit Length RFC 9562 Invariant / Purpose
00 – 05 custom_a 48 bits Custom timestamp, shard prefix, or high-order enterprise identifier.
06 (high 4) ver 4 bits Permanently 0b1000 (hex 8) — identifying Version 8.
06 (low 4) + 07 custom_b 12 bits Sub-millisecond sequence counter, environment flags, or entity code.
08 (high 2) var 2 bits Permanently 0b10 — standard RFC 9562 / IETF Variant 1.
08 (low 6) + 09–15 custom_c 62 bits Cryptographic CSPRNG entropy, monotonic incrementor, or worker node ID.

UUID v8’i Diğer UUID Sürümlerinden Farklı Kılan Nedir?

UUID v8 ile önceki sürümler (v1 ila v7) arasındaki temel ayrım, anlamsal esneklik ile algoritmik katılık arasındaki farktır. Sürüm 1, 3, 4, 5, 6 ve 7’nin her biri, dünya çapındaki her uyumlu oluşturucunun uyması gereken değişmez bir evrensel algoritma uygular. Örneğin bir UUID v4 oluşturucusu 122 biti sözde rastgele sayılarla doldurmak ZORUNDADIR; bir UUID v5 oluşturucusu bir isim alanının SHA-1 karmasını hesaplamak ZORUNDADIR; ve bir UUID v7 oluşturucusu rastgele sıra bitleriyle takip edilen 48 bitlik milisaniye Unix zaman damgasını kodlamak ZORUNDADIR. Bu yapılardan tek bir biti bile değiştirirseniz elde edilen değer artık geçerli bir UUID olmaz.

Buna karşılık RFC 9562, UUID v8 için kasıtlı olarak evrensel bir veri biçimi tanımlamaz. Bunun yerine geliştiricilere özel bir sanal alan sunar. İki tamamen farklı yazılım sistemi geçerli UUID v8 kayıtları üretebilir; ancak bir sistem küme düğüm kimliklerine sahip 64 bitlik nanosaniye zaman damgalarını kodlarken, diğeri bir idempotency sayacı ile bir hesap defteri karmasını kodlayabilir. Her ikisi de sürüm 8 ve varyant 1 bitlerini korudukları için RFC 9562’ye %100 uygundur. UUID v8, 128 bitlik veritabanı sütunları ve dizin motorlarıyla birlikte çalışabilirlikten ödün vermeden geliştiricilere bit düzeni üzerinde mimari egemenlik sağlar.

UUID v8 ve UUID v4 Karşılaştırması: Özel Düzen ve Saf Rastgele Entropi

UUID v4, modern yazılım mühendisliğinde en yaygın kullanılan tanımlayıcıdır. 122 biti kriptografik olarak güvenli sözde rastgele entropi (CSPRNG) ile doldurarak 5,3 × 10³⁶ olası benzersiz değer üretir. Bir v4 tanımlayıcısı tamamen rastgele olduğu için hiçbir uygulama anlambilimine sahip değildir: bir zaman damgası çıkaramazsınız, hangi mikroservisin oluşturduğunu bilemezsiniz veya kronolojik olarak sıralayamazsınız. Bu tam öngörülemezlik güvenlik belirteçleri ve dağıtık sırlar için mükemmel olsa da, kümelenmiş B-Tree veritabanı indekslerinde (PostgreSQL veya MySQL InnoDB gibi) depolandığında şiddetli indeks parçalanmasına ve yazma amplifikasyonuna yol açar.

UUID v8, yapılandırılmış meta veriler ile UUID uyumluluğu arasındaki boşluğu doldurur. UUID v4 körü körüne rastgeleliği zorunlu kılarken, UUID v8 çakışma koruması için custom_c bloğunda rastgele entropiyi korurken, tanımlayıcının içine doğrudan özel zaman dönemleri, organizasyon kimlikleri veya bölge kodları gibi hedeflenen iş verilerini yerleştirmenize olanak tanır. Uygulamanız dahili yapısı olmayan öngörülemez opak kimliklere ihtiyaç duyuyorsa UUID v4’ü seçin. Sisteminiz özel bit paketleme veya dahili şemalara ihtiyaç duyuyor ancak yine de geçerli bir 128 bit UUID kalmak istiyorsa UUID v8’i seçin.

UUID v8 ve UUID v7 Karşılaştırması: Özel İhtiyaçlar ve Standart Zaman Sıralaması

Hem UUID v7 hem de UUID v8, dağıtık bilgi işlem için modern çözümler olarak RFC 9562’de eşzamanlı olarak tanıtıldı, ancak çok farklı mühendislik hedeflerine hizmet ederler. UUID v7, evrensel standart bir biçim aracılığıyla B-Tree veritabanı indeks parçalanmasını çözmek için oluşturuldu: en yüksek anlamlı bitlerde milisaniye çözünürlüğünde 48 bitlik Unix Dönemi zaman damgası ve ardından 74 bitlik sıra ve rastgele entropi zorunlu kılar. v7 biçimi küresel olarak standartlaştırıldığından, herhangi bir veritabanı, ORM veya dil kütüphanesi özel ayrıştırıcılar olmadan oluşturma zamanını çıkarabilir ve kayıtları kronolojik olarak sıralayabilir.

UUID v8, UUID v7’nin 48 bitlik milisaniye Unix zaman damgası kısıtlamaları yetersiz kaldığında veya mimarinizle uyumsuz olduğunda gereklidir. Örneğin yüksek frekanslı finansal ticaret sistemleri genellikle v7’nin 48 bitlik sınırını aşan mikrosaniye veya nanosaniye hassasiyeti gerektirir; bilimsel hesaplama platformları özel bir astronomik takvime veya Gregoryen dönemine ihtiyaç duyabilir; ve çok kiracılı platformlar veritabanı bölümleme için tanımlayıcının en başında kiracı yönlendirme bitlerine ihtiyaç duyabilir. UUID v7 ilişkisel birincil anahtarlar için önerilen varsayılan seçim olsa da, UUID v8 zamansal veya yapısal gereksinimleriniz standart v7 spesifikasyonundan saptığında başvurulacak resmi standarttır.

UUID v8 Ne Zaman Kullanılmalıdır?

UUID v8, geleneksel UUID biçimlerinin teknik gereksinimlerinizi karşılayamadığı özel mimariler için tasarlanmıştır. Yaygın üretim kullanım durumları şunları içerir:

  • Custom Epochs & High-Precision Timestamps: Özel Dönemler ve Yüksek Hassasiyetli Zaman Damgaları: Uygulamanız 64 bit nanosaniye hassasiyeti, özel kurumsal dönemler (Twitter Snowflake veya Discord Epoch gibi) veya UUID v7’nin milisaniye çözünürlüğünün ötesinde monoton sıralama gerektirdiğinde.
  • Database Partitioning & Multi-Tenant Sharding: Veritabanı Bölümleme ve Çok Kiracılı Sharding: Müşteri kiracı kimliklerini, bölge kodlarını veya parça tanımlayıcılarını yüksek seviyeli custom_a bitlerine yerleştirerek veritabanı proxy yönlendiricilerinin ikincil dizin tablolarını sorgulamadan istekleri anında yönlendirmesini sağlama.
  • Legacy GUID Migration & Enterprise Systems: Eski GUID Geçişleri ve Kurumsal Sistemler: Eski 128 bit tescilli tanımlayıcıları, COM GUID’lerini veya donanım telemetri belirteçlerini depolama ikili şemasını yeniden tasarlamadan RFC uyumlu UUID sütunlarına taşıma.
  • Cryptographic Nonces with Embedded Telemetry: Gömülü Telemetriye Sahip Kriptografik Nonce’lar: İstemci cihaz parmak izini, protokol sürüm etiketini ve bir kriptografik nonce yükünü anında API doğrulaması için tek bir 128 bit standart başlık değerinde birleştirme.

UUID v8 Ne Zaman Tercih Edilmemelidir?

Muazzam esneklik sunmasına rağmen, UUID v8 tüm tanımlayıcı ihtiyaçları için evrensel bir çözüm değildir. Aşağıdaki senaryolarda UUID v8’den kaçınmalısınız:

  • Public APIs & Third-Party Integrations: Genel API’ler ve Üçüncü Taraf Entegrasyonları: Harici ortaklar, SDK’lar ve üçüncü taraf uygulamalar standart UUID v4 veya v7 tanımlayıcıları bekler. Özel bit yapıları dış tarafları özel ayrıştırıcılar yazmaya zorlar.
  • Standard Web Application Primary Keys: Standart Web Uygulaması Birincil Anahtarları: Yalnızca sıralı ve yüksek performanslı veritabanı anahtarlarına ihtiyacınız varsa, UUID v7 zaten geniş ölçüde desteklenmekte, son derece optimize edilmiş ve tüm büyük SQL motorlarında standartlaştırılmıştır.
  • Security-Critical Opaque Identifiers: Güvenlik Açısından Kritik Opak Kimlikler: Sıralı sayaçları, kullanıcı kimliklerini veya iş meta verilerini açık bitlerde ifşa etmek, sistemin dahili durumunu veya işlem hacmini dış dünyaya sızdırabilir.
  • Interoperability Without a Shared Schema: Ortak Şema Olmayan Birlikte Çalışabilirlik: UUID v8 anlambilimi uygulamaya özgü olduğundan, bit belgelerinize erişimi olmayan harici sistemler bu alanları okuyamaz ve bu durum veri siloları yaratır.

Somut UUID v8 Mimari Düzen Örnekleri

UUID v8 tek bir veri biçimi dayatmadığından, geliştiriciler operasyonel ihtiyaçlara göre uyarlanmış çeşitli bit düzenleri oluşturabilirler:

  • Örnek 1: 48-bit Mikrosaniye Zaman Damgası + 12-bit Makine Kimliği + 62-bit Rastgele Entropi (xxxxxxxx-xxxx-8xxx-yxxx-xxxxxxxxxxxx). İlk 12 onaltılık basamak özel bir dönemden bu yana mikrosaniyeleri kodlar; sonraki 3 basamak sunucu kümesini kodlar; ve son 62 bit çakışma direnci için rastgele CSPRNG baytları içerir.
  • Örnek 2: 32-bit Kiracı Anahtarı + 16-bit Varlık Türü + 12-bit Shard + 62-bit Sıra (xxxxxxxx-xxxx-8xxx-yxxx-xxxxxxxxxxxx). Büyük ölçekli çok kiracılı SaaS mimarileri için tasarlanmıştır ve veritabanı yönlendiricilerinin sorguları doğrudan yalıtılmış müşteri bölümlerine yönlendirmesine olanak tanır.
  • Örnek 3: 122-bit Kriptografik Olarak Güvenli Rastgele Blok. FastUUIDGenerator Güvenli Rastgele modunda kullanıldığında, yapılandırılabilir 122 bitin tamamı Web Cryptography API aracılığıyla sözde rastgele entropi ile doldurulur ve öngörülemeyen bir v8 tanımlayıcısı üretir.

UUID v8 Hakkında Sıkça Sorulan Sorular

UUID v8 nedir?

UUID v8, özel, deneysel ve uygulamaya özgü düzenler için IETF RFC 9562 standardında tanımlanmış resmi 128 bitlik Evrensel Benzersiz Tanımlayıcı biçimidir. 4 sürüm bitini (8 olarak ayarlanmış) ve 2 varyant bitini (RFC 9562 Varyant 1 olarak ayarlanmış) ayırır ve özel uygulama verileriniz için tam 122 serbest bit sağlar.

UUID v8 rastgele midir?

UUID v8 uygulamanıza bağlı olarak rastgele, belirleyici veya yapılandırılmış olabilir. UUID v4 %100 rastgele entropi gerektirirken, UUID v8 122 biti güvenli rastgele baytlarla doldurmanıza (aracımızın yaptığı gibi) veya zaman damgaları ve sayaçlar gibi yapılandırılmış etki alanı verileriyle doldurmanıza olanak tanır.

UUID v8 IETF tarafından standartlaştırılmış mıdır?

Evet. UUID v8, RFC 9562 Bölüm 5.8’de resmi olarak standartlaştırılmıştır. Standart, bit alanı sınırlarını, sürüm dörtlüsü konumunu (sekizli 6, bit 4–7) ve varyant bitlerini (sekizli 8, bit 6–7) kesin olarak belirler ve herhangi bir uyumlu ayrıştırıcının bunu geçerli bir 128 bit UUID olarak tanımasını sağlar.

UUID v8’de kaç bit özelleştirilebilir?

UUID v8 tam olarak 122 özelleştirilebilir bit sağlar. RFC 9562’de bu bitler üç alana ayrılmıştır: custom_a (48 bit), custom_b (12 bit) ve custom_c (62 bit). Kalan 6 bit sürüm (4 bit = 0b1000) ve varyant (2 bit = 0b10) için kesin olarak ayrılmıştır.

UUID v8 kriptografik olarak güvenli midir?

UUID v8’in güvenlik seviyesi tamamen özel bitlerine yerleştirilen verilere bağlıdır. Kriptografik olarak güvenli rastgele entropinin 122 biti (crypto.getRandomValues() aracılığıyla CSPRNG) kullanılarak üretilirse, 5,3 × 10³⁶ benzersiz ve tahmin edilemez kombinasyon sağlar. Ancak sistem kolayca tahmin edilebilen sıralı sayaçlar yerleştirirse bu kısımlar güvenli değildir.

UUID v8 ile UUID v4 arasındaki fark nedir?

UUID v4 kesinlikle 122 bitlik sözde rastgele sayılar gerektirir ve hiçbir dahili yapıya veya zaman damgasına sahip değildir. UUID v8, geliştiricilerin 128 bit UUID biçimine tam olarak uyarken özel dahili yapılar (özel zaman dönemleri veya kiracı anahtarları gibi) tasarlamalarına olanak tanır.

UUID v8 ile UUID v7 arasındaki fark nedir?

UUID v7, B-Tree dizin optimizasyonu için evrensel olarak standartlaştırılmış 48 bitlik milisaniye hassasiyetli Unix Dönemi zaman damgası ve ardından rastgele sıra bitleri uygular. UUID v8’in yerleşik bir veri biçimi yoktur: sistem v7 standardından farklı Unix dışı dönemlere, nanosaniye zaman damgalarına veya bileşik anahtarlara ihtiyaç duyduğunda kullanılır.

UUID v8 uygulamama özel verileri barındırabilir mi?

Evet. UUID v8’in yaratılmasının temel amacı budur. RFC 9562, mühendislerin bir tanımlayıcıya etki alanı verilerini veya telemetriyi yerleştirmesi gerektiğinde UUID v4’ü kötüye kullanmasını veya standart dışı ikili biçimler icat etmesini önlemek için Sürüm 8’i özel olarak sunmuştur.

UUID v8 küresel benzersizliği garanti eder mi?

UUID v8’in benzersizliği tamamen uygulamaya bağlıdır ve evrensel olarak garanti edilemez. CSPRNG rastgele entropisinin 122 biti ile oluşturursanız, çakışma olasılığı neredeyse imkansızdır (UUID v4 ile eşdeğerdir). Ancak manuel zaman damgaları veya sayaçlar yerleştirirseniz, sistem mimariniz düğüm kimliklerinin ve sayaçların çakışmamasını sağlamalıdır.

UUID v8 veritabanlarında birincil anahtar olarak kullanılabilir mi?

Evet. UUID v8, standart 128 bit UUID veritabanı sütun türleriyle (PostgreSQL UUID, MySQL BINARY(16) ve SQL Server UNIQUEIDENTIFIER gibi) tamamen uyumludur. Özel düzeniniz custom_a alanına sürekli artan bir zaman damgası veya sayaç yerleştiriyorsa, UUID v8 aynı zamanda son derece verimli B-Tree indeks kümeleme performansı sağlar.