UUID vs ULID vs Serial ID'ler: Veritabanınız için doğru ID'yi seçmek

Gerçek problem: sonradan pişman olmayacağınız bir ID seçmek

ID seçimi ilk hafta sıkıcı görünebilir. Sonra yayına alırsınız, veri büyür ve o "basit" karar her yerde görünür: indeksler, URL'ler, loglar, ihracatlar ve entegrasyonlar.

Asıl soru "hangisi en iyi?" değil. Asıl soru "ileride hangi acıdan kaçınmak istiyorum?" olmalı. ID'ler değiştirmesi zor şeylerdir çünkü başka tablolara kopyalanır, istemciler tarafından önbelleğe alınır ve diğer sistemler onlara bağımlı hale gelir.

ID ürünün evrimine uymadığında genelde şu noktalarda fark edersiniz:

• Birincil anahtar indeksi dostça olmayan bir desende büyüdüğünden eklemeler ve sorgular yavaşlar.
• ID'ye göre sıralama oluşturma zamanıyla eşleşmediğinde sayfalama garipleşir.
• Diğer sistemler ID formatınıza bağımlı hale gelince göçler riskli olur.
• ID'ler okunması veya karşılaştırılması zor olduğunda hata ayıklama uzar.
• Birden fazla kaynaktan veri birleştirirken ithalat çakışmaları yaşanır.

Her zaman anlık kolaylık ile ilerideki esneklik arasında bir takas vardır. Sıralı tamsayılar okunması kolay ve genelde hızlıdır, ama kayıt sayılarını sızdırabilir ve veri setlerini birleştirmeyi zorlaştırabilir. Rastgele UUID'ler sistemler arası benzersizlik için iyidir, ama indekslere daha fazla yük getirir ve insanlar için loglarda zor okunur. ULID'ler küresel benzersizlik ile zaman-münaşebben sıralama sunmayı amaçlar, ama depolama ve araç zinciri açısından yine de takasları vardır.

Bunu düşünmenin faydalı bir yolu: ID kimin için daha çok?

ID çoğunlukla insanlar (destek, hata ayıklama, operasyon) içinse, daha kısa ve taranması kolay olanlar kazanır. Eğer ID makineler içinse (dağıtık yazmalar, çevrimdışı istemciler, çok bölge sistemleri), küresel benzersizlik ve çakışma önleme daha önemli olur.

Basit dilde hızlı tanımlar

İnsanlar "UUID vs ULID vs serial ID" tartışırken gerçekten her satıra nasıl benzersiz bir etiket verileceğini seçiyorlar. Bu etiket, veriyi ekleme, sıralama, birleştirme ve taşıma kolaylığını etkiler.

Serial ID'ler (integer/bigint)

Serial ID bir sayacıdır. Veritabanı 1 verir, sonra 2, sonra 3 ve devam eder (genelde integer veya bigint olarak saklanır). Okunması kolaydır, depolaması ucuzdur ve genelde hızlıdır çünkü yeni satırlar indeksin sonuna gelir.

UUID'ler

UUID 128-bit'lik, rastgele görünen bir tanımlayıcıdır, örneğin 3f8a.... Çoğu kurulumda veritabanından bir sonraki sayıyı sormadan üretilebilir, bu yüzden farklı sistemler bağımsız olarak ID oluşturabilir. Takas olarak rastgele görünen eklemeler indeksleri daha fazla yorar ve bigint'e göre daha fazla alan gerektirebilir.

ULID'ler

ULID de 128-bit'tir ama kabaca zamana göre sıralanacak şekilde tasarlanmıştır. Yeni ULID'ler genelde eski olanların sonuna gelirken yine de küresel benzersizlik sağlar. UUID'lerin "her yerde üretilebilir" faydasının bir kısmını, daha dostça sıralama davranışı ile elde edersiniz.

Basit bir özet:

• Serial: en küçük ve varsayılan olarak sıralıdır.
• UUID: bağımsız üretmesi en kolay, insan dostu değil, genelde rastgele sırada.
• ULID: UUID gibi bağımsız üretilebilir, ama kabaca zamana göre sıralanır.

Serial ID'ler tek veritabanlı uygulamalar ve dahili araçlar için yaygındır. UUID'ler verinin birden fazla servis, cihaz veya bölge tarafından yaratıldığı durumlarda görülür. ULID'ler ise dağıtık ID üretimini istiyor ama sıralamayı, sayfalamayı veya "en yeniler" sorgularını önemsiyorsanız popülerdir.

İndeksleme ve performans: pratikte neler değişir

Birincil anahtar genelde bir indeksle desteklenir (çoğunlukla B-tree). O indeksi sıralanmış bir rehber gibi düşünün: her yeni satır hızlı arama için doğru yere konulmalı.

Rastgele ID'lerde (klasik UUIDv4) yeni girdiler indeksin her yerine düşer. Bu veritabanının birçok indeks sayfasına dokunması, sayfa bölünmelerinin daha sık olması ve ekstra yazmalar yapması anlamına gelir. Zamanla indeks churn artar: ekleme başına daha fazla iş, daha fazla önbellek kaçağı ve beklenenden daha büyük indeksler.

Çoğunlukla artan ID'lerde (serial/bigint veya birçok ULID türü gibi zaman-sıralı ID'ler) veritabanı genelde yeni girdileri indeksin sonuna ekleyebilir. Bu önbelleğe daha dosttur çünkü son sayfalar sıcak kalır ve yüksek yazma oranlarında eklemeler daha düzgün olur.

Anahtar boyutu önemlidir çünkü indeks girdileri bedavadır:

• serial bigint: 8 byte
• UUID: 16 byte
• ULID: ikili olarak saklanırsa 16 byte, 26 karakterlik string olarak saklanırsa çok daha büyük

Daha büyük anahtarlar, bir indeks sayfasına daha az girdi sığdırır. Bu genelde daha derin indeksler, sorgu başına daha fazla sayfa okuma ve hızlı kalmak için daha fazla RAM ihtiyacı demektir.

Sürekli eklemeler olan bir "events" tablonuz varsa, rastgele UUID birincil anahtar bigint anahtardan daha erken yavaşlamaya başlayabilir, tek-satırlık aramalar hala iyi görünse bile. Beklenen ağır yazma durumunda indeks maliyeti genelde fark edeceğiniz ilk gerçek farktır.

Sıralama, sayfalama ve zaman sırası

"Daha fazla yükle" veya sonsuz kaydırma yaptıysanız, ID'lerin iyi sıralanmadığında yaşanan zorluğu zaten hissetmişsinizdir. Bir ID "iyi sıralanır" dediğimizde, ona göre sıralamanın stabil ve anlamlı bir sıra (çoğunlukla oluşturulma zamanı) vermesini kastediyoruz; bu sayede sayfalama öngörülebilir olur.

Rastgele ID'lerde (ör. UUIDv4) yeni satırlar dağılır. id ile sıralamak zamanla eşleşmez, ve "bu id'den sonra" imleç sayfalaması güvenilmez olur. Genelde created_at'a dönersiniz, ki bu iyidir ama dikkatli yapılmalı.

ULID'ler kabaca zaman-sıralı olacak şekilde tasarlanmıştır. ULID'ye göre sıralarsanız (string veya ikili formda), genelde yeni öğeler daha sonra gelir. Bu, imleç sayfalamasını basitleştirir çünkü imleç olarak son görülen ULID yeterli olabilir.

ULID'nin verdiği (ve vermediği) şey

ULID, akışlar için doğal zaman-benzeri sıralama, daha basit imleçler ve UUIDv4'e göre daha az rastgele ekleme davranışı sağlar.

Ancak ULID, birden fazla makinede aynı milisaniyede üretilen birçok ID olduğunda mükemmel zaman sıralaması garanti etmez. Kesin sıralama gerekiyorsa yine gerçek bir zaman damgası istersiniz.

created_at'in hala daha iyi olduğu zamanlar

Backfill yaparken, tarihsel kayıtları içe aktarırken veya net eşitlik kırma gerektiğinde created_at ile sıralamak genelde daha güvenlidir.

Pratik bir desen, created_at ile sıralamak ve ID'yi yalnızca eşitlik durumunda bağlayıcı olarak kullanmaktır: (created_at, id).

Daha sonra sharding: ID çakışmalarından kaçınma

Sharding, bir veritabanını birkaç daha küçük veritabanına bölmek demektir; her shard verinin bir kısmını tutar. Takımlar genelde tek bir veritabanının ölçeklenmesi zorlaştığında bunu sonradan yapar.

ID seçiminiz sharding'i ya yönetilebilir ya da acılı hale getirebilir.

Sıralı ID'lerle (otomatik artan serial veya bigint), her shard memnuniyetle 1, 2, 3... üretir. Aynı ID birden fazla shard'ta var olabilir. İlk kez verileri birleştirmeniz, satır taşımanız veya çapraz-shard özellikleri oluşturmanız gerektiğinde çakışmalarla karşılaşırsınız.

Koordinasyon (merkezi ID servisi veya shard başına aralıklar) ile çakışmaları önleyebilirsiniz, ama bu ek parçalar getirir ve darboğaz olabilir.

UUID ve ULID, her shard'ın bağımsız ID üretmesini sağlayarak koordinasyon ihtiyacını azaltır çünkü çakışma riski son derece düşüktür. Eğer verileri birden fazla veritabanına ayırmayı düşünüyorsanız, bu saf dizilere karşı güçlü bir argümandır.

İşe yarayan basit bir plan (ve maliyeti)

Yaygın bir uzlaşma, bir shard ön eki eklemek ve her shard'ta yerel bir sıra kullanmaktır. Bunu iki sütun olarak saklayabilir veya bir değere paketleyebilirsiniz.

Bu işe yarar ama özel bir ID formatı yaratır. Her entegrasyon bunu anlamalıdır, sıralama küresel zaman düzeni anlamını kaybeder ve shard'lar arasında veri taşımak ID'leri yeniden yazmayı gerektirebilir (bu da ID'ler paylaşılıyorsa referansları bozar).

Erken bir soru sorun: verileri asla birleştirmeniz ve referansları sabit tutmanız mı gerekecek? Eğer evet ise, baştan küresel olarak benzersiz ID'ler planlayın veya daha sonra bir göç için bütçe ayırın.

Veri dışa aktarma ve içe aktarma iş akışları

Dışa aktarma/ithalat ID seçiminin teoriden çıktığı andır. Prod'u staging'e klonladığınız, yedeği geri yüklediğiniz veya iki sistemden verileri birleştirdiğiniz anda ID'lerin taşınabilir ve stabil olup olmadığını görürsünüz.

Serial (otomatik artan) ID'lerle başka bir veritabanına eklemeleri güvenle yeniden oynatıp referansların korunmasını bekleyemezsiniz; orijinal numaraları korumadıkça yabancı anahtarlar bozulur. Eğer sadece bir alt küme satır (ör. 200 müşteri ve ilgili siparişler) içe aktaracaksanız, tabloları doğru sırada yüklemeli ve birincil anahtarları birebir korumalısınız. Herhangi bir yeniden numaralandırma olursa yabancı anahtarlar kırılır.

UUID ve ULID veritabanı sırasına bağlı olarak oluşturulmadığı için, ortamlar arasında taşımak ve ilişkileri korumak daha kolaydır. Satırları kopyalayabilir, ID'leri olduğu gibi tutabilir ve ilişkiler doğru kalır. Bu, yedekten geri yükleme, kısmi ihracatlar veya veri birleştirmelerde yardımcı olur.

Örnek: Üretimden 50 hesabı hata ayıklamak için staging'e aktarın. UUID/ULID birincil anahtarlarıyla bu hesapları ve ilişkili satırları (projeler, faturalar, loglar) içe aktarabilir ve her şey doğru parent'e işaret eder. Serial ID'lerde genelde bir çeviri tablosu (old_id -> new_id) oluşturup yabancı anahtarları içe aktarım sırasında yeniden yazarsınız.

Toplu içe aktarmalar için temeller ID tipinden daha önemlidir:

• İmport edici varsayılan olarak yeni ID üretmemeli.
• Ebeveynleri çocuklardan önce içe aktarın ve yüklemeden sonra yabancı anahtarları doğrulayın.
• Serial ID kullanıyorsanız dizileri sıfırlayın yoksa sonraki ekleme çakışabilir.
• ULID kullanıyorsanız, bunları tutarlı şekilde (string vs ikili) saklayın ve dışa aktarın.

10 dakikada nasıl seçilir

Gelişmekten daha çok ağrı verecek olanı düşünerek hızlıca sağlam bir karar verebilirsiniz.

1. Gelecekteki en büyük riskleri yazın. Somut olaylar: birden fazla veritabanına bölünme, başka bir sistemden müşteri verisi birleştirme, çevrimdışı yazmalar, ortamlar arasında sık veri kopyalama.

2. ID sıralamasının zamanla eşleşmesi gerekip gerekmediğine karar verin. "En yeniler ilk" istiyorsanız ULID (veya başka bir zaman-sıralı ID) temiz bir uyumdur. created_at ile sıralamayı kabulleniyorsanız UUID ve serial her ikisi de çalışır.

3. Yazma hacmini ve indeks hassasiyetini tahmin edin. Ağır eklemeler bekliyorsanız ve birincil anahtar indeksiniz sürekli yazma altında kalacaksa serial BIGINT genelde B-tree'lere en kolay olandır. Rastgele UUID'ler daha fazla churn yaratır.

4. Bir varsayılan seçin, sonra istisnaları belgeleyin. Basit tutun: çoğu tablo için bir varsayılan ve ne zaman sapılacağına dair net bir kural.

5. Değişiklik yapmaya yer bırakın. ID'lere anlam yüklemekten kaçının, ID'lerin nerede oluşturulacağına (DB vs uygulama) karar verin ve kısıtları açık tutun.

Yaygın hatalar ve tuzaklar

En büyük tuzak, popüler diye bir ID seçip sonra sorgulama, ölçek veya veri paylaşımı ile çatıştığını görmek. Çoğu problem aylar sonra ortaya çıkar.

Yaygın başarısızlıklar:

• Maliyeti kontrol etmeden her yerde UUID kullanmak. UUIDv4 indeksleri şişirebilir ve önbellek dostu olmayı azaltabilir. Uygulama çalışır ama yazma hızında ve yedek boyutunda maliyet ödersiniz.
• Serial ID'lere güvenip sonra verileri birden fazla sistem, bölge veya shard arasında birleştirmeniz gerektiğinde çakışmalarla karşılaşmak. Hızlı çözümler (offsetler, önekler) tüm entegrasyonlara sızabilir.
• ULID her şeyi hızlandırır diye varsaymak. Sıralama ve zaman bazlı sıralama konusunda yardımcı olur ama yavaş join'leri, eksik indeksleri veya geniş satırları düzeltmez. Bazı jeneratörler ağır eşzamanlılıkta kesin monoton olmayabilir.
• Ardışık ID'leri halka açık olarak ifşa etmek. URL'leriniz veya API'leriniz 123, 124, 125 gibi olursa insanlar yakın kayıtları tahmin edip sisteminizi tarayabilir.
• Proje ortasında ID tipini değiştirmek ama bir göç planı olmadan yapmak. Yabancı anahtarlar, önbellekler, loglar ve dış payload'lar eski ID'leri uzun süre referanslamaya devam edebilir.

Erken ele alınması gereken uyarı işaretleri:

• Ortaklardan ithalat bekliyorsanız veya ortamlar arasında düzenli olarak veri birleştiriyorsanız.
• Ayrı bir zaman damgasına güvenmeden zaman-sıralı sayfalama istiyorsanız.
• ID'leri sistem dışına (URL'ler, webhooks, mobil uygulamalar) paylaşacaksanız.
• Büyük bir ID göçü için kesinti göze alamayacaksanız.
• İndeks boyutu ve yazma hızı önemli olacak kadar büyük tablolar bekliyorsanız.

Kararlanmadan önce hızlı kontrol listesi

Veritabanı ve sorgu gerçekleri

Bir birincil anahtar türü seçin ve çoğu tabloda ona sadık kalın. Türleri karıştırmak (bir yerde bigint, başka yerde UUID) join'leri, API'leri ve göçleri zorlaştırır.

Beklenen ölçeğinizde indeks boyutunu tahmin edin. Geniş anahtarlar birincil indeksleri ve bellek/IO ihtiyacını büyütür.

Sayfalamayı nasıl yapacağınızı karar verin. Eğer ID ile sayfalamayı seçiyorsanız, ID'nin öngörülebilir bir sıralamaya sahip olduğundan emin olun (veya bunun olmayacağını kabul edin). Zaman damgasına göre sayfalama yapacaksanız created_at'i indeksleyin ve tutarlı kullanın.

Geleceğe hazırlık kontrolü

İçe aktarma planınızı üretime benzer veriyle test edin. Kayıtları kırmadan yeniden oluşturabildiğinizi doğrulayın ve tekrar içe aktarmaların yeni ID üretmediğinden emin olun.

Çakışma stratejinizi yazın. ID'yi kim üretiyor (DB veya uygulama) ve iki sistem çevrimdışıyken oluşturulan kayıtlar daha sonra senkronize olduğunda ne olur?

Halka açık URL'lerin ve logların istemeden sayıları veya dahili shard ipuçlarını sızdırmadığından emin olun. Serial ID kullanıyorsanız insanların yakın ID'leri tahmin edebileceğini varsayın.

Gerçekçi bir örnek: MVP'den çok sistemli veriye

Tek bir kurucu basit bir CRM başlatır: kişiler, fırsatlar, notlar. Bir Postgres veritabanı, bir web uygulaması ve ana hedef hızlıca yayınlamaktır.

İlk başta serial bigint birincil anahtar mükemmel hisseder. Eklemeler hızlıdır, indeksler düzenli kalır ve loglarda okumak kolaydır.

Bir yıl sonra bir müşteri denetim için çeyreklik ihracatlar ister ve kurucu pazarlama aracından lead'leri içe aktarmaya başlar. İçsel olan ID'ler şimdi CSV'lerde, e-postalarda ve destek biletlerinde görünür. İki sistem de 1, 2, 3... kullanıyorsa birleştirmeler karışır. Kaynak sütunları, eşleme tabloları eklemek veya içe aktarma sırasında ID'leri yeniden yazmak zorunda kalırsınız.

İkinci yılda bir mobil uygulama çıkar. Çevrimdışı olarak kayıt oluşturması ve sonra senkronize etmesi gerekir. Artık veritabanına konuşmadan istemci tarafında ID üretilebilmesini ve farklı ortamlarda veriler yerleştiğinde düşük çakışma riskini istersiniz.

Sıkça iyi işleyen bir uzlaşma:

• İçsel join'ler ve depolama verimliliği için bigint birincil anahtar tutun.
• Paylaşım, senkronizasyon ve ihracatlar için ayrı değişmez bir public ID (ULID veya UUIDv7 varsa UUIDv7) ekleyin.
• İhracat dosyalarında ve sistemler arası birleştirmelerde public ID'yi anahtar olarak kullanın.

Projeniz için pratik sonraki adımlar

UUID, ULID ve serial ID arasında kararsızsanız, verilerinizin nasıl hareket edip büyüyeceğine göre karar verin.

Ortak durumlar için tek cümlelik seçimler:

• Tek veritabanlı dahili araç ve düşük entegrasyon riski: bigint serial birincil anahtar kullanın.
• Paylaşılabilir URL'ler veya istemci tarafı oluşturma olan halka açık uygulama: UUID kullanın (tahmini zor, sistemler arası güvenli).
• Tenant veya bölgeye göre ileride bölünme ihtimali olan SaaS: ULID (veya UUIDv7) kullanın ki yeni satırlar indekste birbirine yakın kalsın.
• Ortaklardan çok sayıda ithalat ve çevrimdışı cihazlar: harici varlıklar için saf serial ID'den kaçının.

Karıştırmak genelde en iyi cevaptır. Sunucuda asla dışarı çıkmayacak dahili tablolar (join tabloları, arka plan işleri) için serial bigint; kullanıcılar, organizasyonlar, faturalar gibi dışa açılabilecek varlıklar için UUID/ULID kullanın.

Eğer Koder.ai üzerinde inşa ediyorsanız, çok fazla tablo ve API üretmeden önce ID deseninizi belirlemek faydalıdır. Platformun planlama modu ve snapshots/rollback özellikleri, şema değişikliklerini küçükken uygulayıp doğrulamayı kolaylaştırır.