Bir kaynağın ID’si GUID mi olmalı, yoksa sıralı mı?
(twitter.com/dylayed)Belirli bir kaynağı benzersiz biçimde tanımlayan bir ID’nin nasıl oluşturulacağı denince, genelde başlıca iki yöntemin kullanıldığını biliyorum. Bunlardan biri, veritabanı tablosunun Primary Key alanına Auto Increment verip ortaya çıkan sıralı tamsayı değerini olduğu gibi kullanmak; diğeri ise rastgele 128 bitlik bir değer olan GUID’i (UUID olarak da bilinir) her seferinde üretip kullanmaktır.
Web’de gördüğümüz sayısız hizmetin verisinin önemli bir kısmından RDBMS sorumludur ve bu tür DBMS’lerdeki Auto Increment hem dahili olarak epey optimize edilmiştir hem de kullanan geliştirici açısından anlaması ve tahmin etmesi kolaydır; ayrıca veriyi geliş sırasına göre sıralamak da basittir. Sonuçta sadece sayıyı 1’er 1’er artırırsınız. Ancak bu yöntem, bazı durumlarda güvenlik açısından dışarıya açılmaması gereken bilgileri ifşa edebilir (örneğin rakip bir şirket, hizmetinizin kullanıcı sayısı gibi temel metrikleri kolayca sezebilir) ya da dağıtık mimarilerde sorun yaratabilir.
GUID kullanımı ise bunun tam tersi özellikler taşır. GUID, başka bir bağımlılık olmadan çakışma olasılığı sıfıra çok yakın, fiilen benzersiz bir 128 bitlik değeri her seferinde üretip kullandığı için dağıtık mimarilerde sorun çıkarmaz; ayrıca dışarıya başka anlamlı bilgilerin sızmasına da yol açmaz. Ancak rastgele üretilmiş bir değeri RDBMS’te kullanmak performans düşüşüne neden olabilir ve kendi başına veriyi giriş sırasına göre sıralamak da mümkün değildir. Bu zayıflığı gidermek için, tamamen rastgele olmak yerine zaman bilgisinin de eklendiği ve kusurlu bir sıralılık taşıyan Timeflake gibi çözümler de kullanılır. Ben doğrudan kullanmadım ama Laravel gibi framework’lerin de bu yaklaşımı kullandığını duydum.
Kişisel olarak, şu an çalıştığım şirkette Microsoft Office 365 veya Graph API gibi GUID’i aktif biçimde kullanan ürünlerle entegre çalışan yazılımlar geliştirdiğim için, GUID’i yoğun kullanan yaklaşımın da oldukça iyi olabileceğini düşünmeye başladım. Ama sonuçta bu tür konularda hangisinin daha iyi olduğu kullanım alanına ve amaca göre değişir; dolayısıyla her yöntemin artılarını ve eksilerini net biçimde bilmek faydalıdır. Bu yüzden, bununla ilgili olarak kurgusal bir servis geliştiricisinin günlüğünü içeren bir tweet zincirini tanıtıyorum. (Korece)
15 yorum
Son dönemde Shinhan Card'da sahte kullanım vakası yaşandı; bununla bağlantılı olarak, ilgili kart şirketinin kredi kartı numaralarını sıralı şekilde vermesi nedeniyle yurt dışından gelebilecek sahte kullanımlara maruz kalma riski olduğu ortaya çıktı.
Numarayı sadece biraz değiştirdiler ve "ödeme" gerçekleşti… Kopyalanmaya açık kredi kartları
Finansal Denetim Kurumu, Shinhan Card'daki son sahte kullanımlar vb. için önlem hazırlıyor
Birçok kişinin yorum yazması sayesinde daha önce pek bilmediğim birçok şeyi öğrenmiş oldum.
Bu sayede Hashids, Nano ID ve Instagram’ın kullandığı yöntem gibi şeyleri de ilk kez öğrenmiş oldum.
Muhtemelen
ulidile benzer bir motivasyonla, öneri aşamasında olan bir Internet Draft bulunduğu için ben de bu spesifikasyonu önceki bir projede kullanmıştım.https://github.com/uuid6/uuid6-ietf-draft
Bu şekilde üretilen ID sistemlerini sık görüyoruz; artık en azından UUID benzeri olanların tek bir standartta birleşmesi gereken noktaya gelmiş gibiyiz.
Ama dağınık halde çoğalan standartları tek bir standart altında birleştirecek yeni bir standart yaratma girişiminin, çoğu zaman piyasaya yalnızca yeni bir rakip daha çıkarmaktan ibaret olduğu söylenir. hahaha
https://xkcd.com/927/
Aynen haha, sanırım bu yüzden herkes yeni id önerileri ortaya atıyor.
Kısa süre önce Gyuwon bunu paylaşmıştı; ama aslında bu o kadar da karmaşık bir mesele değil, değil mi?
https://byterot.blogspot.com/2013/02/…
Ben de bunun "basit bir sorun" olduğuna dair ifadenin ek açıklamasını istiyorum.
Hangi açıdan bunun basit bir mesele olduğunu söylüyorsunuz?
Bu yazıda "With storage nowadays very cheap, this normally is not a problem from the storage point of view." deniyor, ancak bu id’nin ağ üzerinde dolaşması gereken durumlar, bellekte key olarak rol oynaması ya da büyük hacimli verilerde birçok yerde kullanılan bir anahtar olması gibi, birkaç byte bile azaltmanın önemli olduğu durumlar var; bu yüzden duruma göre UUID’yi reddetmek gereken durumlar da olabiliyor gibi görünüyor.
Bu yazıda söylenen sorun, rastgele üretilmiş bir değerin primary key olarak kullanılmasıyla ortaya çıkan performans düşüşü gibi görünüyor
(başka bir sorundan da bahsediliyorsa ve ben fark edemediysem lütfen söyleyin)
Bu sorunun cevabı zaten var. Zaman sırasına göre cursor based pagination yaparken ortaya çıkan sorunla aynı; bu yüzden muhtemelen herkes bunu zaten çözmüştür.
Bunun hangi açıdan karmaşık bir mesele olduğunu ben de merak ediyorum.
Söylediğiniz durumun reddedilmesi gereken bir durum olduğunu belirttiğinize göre, sanki basit bir mesele gibi görünüyor...
Karmaşık mesele, insanın bir türlü şu ya da bu yönde karar veremediği durum değil midir?
"Basit bir sorun" ifadesinin anlamı yoruma açık olduğu için, bunu hangi anlamda kullandığınızı merak edip sormuştum. Sorunun kendisinin zor bir problem olmaması mı, yoksa yazının sunduğu net bir cevap(?) olduğu için üzerinde düşünmeye çok fazla gerek kalmaması mı gibi.
İlkine gelince, yukarıda da söylediğim gibi bazı durumlarda
id'nin veritabanı dışında da geçerli olması gerekebildiği için dikkate alınacak unsur sayısı artıyor ve bunun basit bir sorun olmadığını düşünüyorum.python/django için bunun gibi bir şey de var: https://pypi.org/project/django-hashid-field/1.0.0/
Oh, Hashids diye bir yöntem de varmış.
Eğer salt sızarsa, yukarıdaki ana metinde bahsedilen bilgi sızıntısı sorunu ortaya çıkabilir; yine de bence iyi bir yöntem.
ulidde var. 128 bit, zamana göre sıralanabilir.https://github.com/ulid/spec
Benzer şekillerin bu kadar çok olması, galiba insanların düşüncelerinin de çoğunlukla birbirine yakın olduğunu gösteriyor…?