UUIDv7: Zaman Damgaları Zaman Sıralı Değildir ve Diğer Tuhaflıklar

UUIDv7, düşündüğünüz özelliklere her zaman sahip olmayabilir. Çoğu teknik blog yazısı UUIDv7'yi överken şu üç temel avantajı öne çıkarır:

• Monoton (sürekli artan) kimlikler (ID'ler)
• Nesnenin ne zaman oluşturulduğunu gösteren kullanışlı bir zaman damgası
• Tahmin edilemez kimlikler

Ancak bu özelliklerin hiçbiri kesin olarak garanti edilmez. RFC standartlarına tam uyumlu bazı UUIDv7 uygulamaları bile bu kuralları uç noktalarda ihlal edebilir. UUIDv7'nin kesin olarak sağladığı tek güvenilir özellik benzersizlik (uniqueness) ve buna bağlı çakışma direncidir (collision resistance). Tahmin edilebilirlik sorunu bir yana, bu makalede diğer iki kritik özelliği ve yazılım mimarisine etkilerini inceliyoruz.

Zaman Damgası Gerçekten Kullanışlı mı?#

Yüzeysel bakıldığında, ID'nin içine bir zaman damgası gömmek, veritabanında oluşturulma zamanını (created_at) ayrı bir sütunda tutma ihtiyacını ortadan kaldırıyor gibi görünür. Kayıtları sık sık oluşturulma sırasına göre listeliyorsanız, birincil indeksin (primary index) bu davranışı doğal olarak sağlaması ve ek indeks ihtiyacını azaltması veritabanı işlemleri açısından caziptir.

Ne var ki UUIDv7 içindeki zaman damgası, nesnenin gerçek oluşturulma zamanıyla örtüşmeyebilir. PostgreSQL'in uuid_extract_timestamp dokümantasyonu bu konuda açıkça uyarır: "Çıkarılan zaman damgası, UUID'nin üretildiği zamanla birebir aynı olmak zorunda değildir."

RFC 9562 standardı, UUID monotonluğu ile zaman damgası doğruluğu arasındaki gerilim nedeniyle, uygulamaların sistem saatinden bağımsız değerler kullanmasına ve zaman damgasını değiştirmesine izin verir:

• Uygulamalar gerçek zaman damgasını değiştirebilir (RFC 9562 §6.1).
• Saat değerinin gerçek zamana ne kadar yakın olması gerektiğine dair hiçbir garanti verilmez (RFC 9562 §6.1).
• Uygulamalar zaman damgasını gerçek zamanın ilerisine taşıyabilir (RFC 9562 §6.2).

Zaman damgasını sistem saatinin ilerisine taşımak ilginç bir mühendislik problemidir. Üretici çok yüksek yük altındaysa ve sayaç (counter) alanı sürekli taşıyorsa, zaman damgası geleceğe doğru hızlanabilir. RFC, sayaç boyutunun en az 12 bit olmasını önerir. Normalde sayacın taşması için düğüm başına milisaniyede 4.096'dan fazla ID üretilmesi gerekir ki bu birçok sistemin sınırlarının ötesindedir. Ancak zaman damgası donduğunda veya saat geri alındığında bu taşma kritik hale gelir.

Örnek: Python uuid.uuid7()#

Zaman damgasını ileri taşıyan önemli uygulamalardan biri Python standart kütüphanesindeki uuid.uuid7() fonksiyonudur. Artırım yalnızca sayaç taşması gibi belirli durumlarda gerçekleşir. Ancak sistem saati herhangi bir nedenle (örneğin NTP senkronizasyonu ile) geriye giderse, üretici bir artırım döngüsüne sıkışabilir ve zaman damgası sistem saatinin keyfi miktarda ilerisine fırlayabilir.

import uuid
from datetime import datetime

# Üreticiyi mevcut zamanla başlat
t = uuid.uuid7().time
now = datetime.now()
delta = (datetime.fromtimestamp(t/1000) - now).total_seconds()
print("Initial delta:", delta)

# Kullanıcıdan saati geri almasını iste
input("Set clock back one hour")

while True:
    for _ in range(100000):
        uuid.uuid7()
    t = uuid.uuid7().time
    now = datetime.now()
    delta = (datetime.fromtimestamp(t/1000) - now).total_seconds()
    print("New delta:", delta)

Geliştiriciler İçin Pratik Çıkarımlar#

• Denetim (Audit) İçin Güvenmeyin: Veritabanında kesin oluşturulma zamanı gerekiyorsa created_at sütununu kaldırmayın; UUIDv7 zaman damgasını yalnızca indeks yerelliği (B-Tree performansı) için kullanın.
• Saat Kaymalarına Dikkat Edin: Dağıtık sistemlerde saat geri sıçramalarının (clock rollback) ID üreticisini geleceğe kilitleyebileceğini göz önünde bulundurarak kullandığınız kütüphanenin davranışını test edin.