Tasarımın bir parçası olarak UUID'yi gerçekten ne zaman kullanmaya zorlanıyorsunuz?

UUID'nin amacını gerçekten görmüyorum . Bir çarpışma olasılığının fiilen sıfır olduğunu biliyorum , ancak aslında sıfırın imkansıza yakın olmadığını biliyorum .

UUID kullanmaktan başka seçeneğiniz olmadığı bir örnek verebilir misiniz? Gördüğüm tüm kullanımlardan, UUID'siz alternatif bir tasarım görebiliyorum. Elbette tasarım biraz daha karmaşık olabilir, ancak en azından sıfır olmayan bir başarısızlık olasılığına sahip değil.

UUID bana global değişkenler gibi kokuyor. Global değişkenlerin daha basit tasarım için yaptığı birçok yol vardır, ancak sadece tembel tasarımı.

Ruby için UUID oluşturucusunu / ayrıştırıcısını yazdım, bu yüzden kendimi konu hakkında oldukça iyi bilgilendirilmiş olarak görüyorum. Dört ana UUID sürümü vardır:

Sürüm 4 UUID'ler, aslında UUID sürümünü ve varyantını tanımlamak için biraz bit döndürme ile şifreleme açısından güvenli bir rasgele sayı üretecinden alınan 16 baytlık rasgeleliktir. Bunların çarpışması son derece düşük bir ihtimaldir, ancak bir PRNG kullanılırsa veya gerçekten, gerçekten, gerçekten, gerçekten, gerçekten kötü bir şansa sahip olursanız olabilir.

Sürüm 5 ve Sürüm 3 UUID'leri, bir UUID oluşturmak için bir ad alanını zaten benzersiz bir veri parçasıyla birleştirmek için sırasıyla SHA1 ve MD5 karma işlevlerini kullanır. Bu, örneğin, bir URL'den bir UUID oluşturmanıza izin verecektir. Buradaki çarpışmalar, yalnızca temeldeki hash fonksiyonunun da bir çarpışması varsa mümkündür.

Sürüm 1 UUID'leri en yaygın olanlardır. Ağ kartının MAC adresini (sahte olmadıkça benzersiz olmalıdır), artı bir zaman damgası ve UUID'yi oluşturmak için olağan bit döndürmeyi kullanırlar. MAC adresi olmayan bir makine durumunda, 6 düğüm baytı kriptografik olarak güvenli bir rastgele sayı üreteci ile üretilir. Zaman damgası önceki UUID ile eşleşecek kadar hızlı sırayla iki UUID üretilirse, zaman damgası 1 artırılır. Aşağıdakilerden biri olmadıkça çarpışmalar meydana gelmemelidir: MAC adresi sahte; İki farklı UUID üreten uygulamayı çalıştıran bir makine, aynı anda UUID'ler üretir; Ağ kartı olmayan veya MAC adresine kullanıcı düzeyinde erişimi olmayan iki makineye aynı rastgele düğüm sırası verilir ve aynı anda UUID'ler oluşturulur;

Gerçekçi olarak, bu olayların hiçbiri tek bir uygulamanın kimlik alanında tesadüfen meydana gelmez. Örneğin, İnternet çapında bir ölçekte veya kötü niyetli kişilerin bir kimlik çakışması durumunda kötü bir şey yapabilecekleri güvenilmeyen bir ortamda kimlikleri kabul etmediğiniz sürece, bu endişelenmeniz gereken bir şey değildir. Benimle aynı sürüm 4 UUID'sini üretirseniz çoğu durumda önemli olmadığını anlamak çok önemlidir. Kimliği sizinkinden tamamen farklı bir kimlik alanında oluşturdum. Başvurum asla çarpışmayı bilmeyecek, bu yüzden çarpışmanın önemi yok. Açıkçası, kötü niyetli aktörlerin olmadığı tek bir uygulama alanında, dünyadaki tüm yaşamın yok olması, siz bir sürüm 4 UUID'de bile çarpışmadan çok önce gerçekleşecektir.

Ayrıca 2 ^ 64 * 16, 256 eksabayttır. Olduğu gibi, tek bir uygulama alanında% 50 bir kimlik çarpışması olasılığınız olmadan önce 256 eksabayt değerinde kimlik depolamanız gerekir.

UUID'lerin sizi satın aldığı ve aksi takdirde yapması çok zor olan şey, merkezi bir otoriteye danışmak veya koordinasyon sağlamak zorunda kalmadan benzersiz bir tanımlayıcı elde etmektir . Böyle bir şeyi bir tür yönetilen altyapı olmadan elde edebilmenin genel sorunu, UUID'lerin çözdüğü sorundur.

Doğum günü paradoksuna göre, 2 ^ 64 UUID oluşturulduktan sonra bir UUID çarpışmasının gerçekleşme olasılığının% 50 olduğunu okudum. Şimdi 2 ^ 64 oldukça büyük bir sayı, ancak% 50'lik bir çarpışma olasılığı çok riskli görünüyor (örneğin,% 5'lik bir çarpışma şansı olmadan önce kaç UUID'nin olması gerekir - bu bir olasılık çok büyük gibi görünse bile) .

Bu analizdeki sorun iki yönlüdür:

1. UUID'ler tamamen rastgele değildir - UUID'nin zaman ve / veya konuma dayalı ana bileşenleri vardır. Dolayısıyla, bir çarpışmada herhangi bir gerçek şansa sahip olmak için, çarpışan UUID'lerin farklı UUID üreticilerinden aynı anda üretilmesi gerekir. Birkaç UUID'nin aynı anda üretilebilmesi için makul bir şans olsa da, bu çok küçük UUID kümesi arasında bir çarpışma olasılığını neredeyse imkansız hale getirmek için yeterince başka gunk (konum bilgisi veya rastgele bitler dahil) olduğunu söyleyebilirim. .

2. daha kesin konuşmak gerekirse, UUID'lerin yalnızca karşılaştırılabilecekleri diğer UUID'ler arasında benzersiz olması gerekir. Veritabanı anahtarı olarak kullanmak için bir UUID oluşturuyorsanız, kötü bir alternatif evrende başka bir yerde aynı UUID'nin bir COM arayüzünü tanımlamak için kullanılıyor olması önemli değildir. Tıpkı Alpha-Centauri'de "Michael Burr" adında biri (veya başka bir şey) varsa, kafa karışıklığına neden olmayacağı gibi.

Her şeyin sıfır olmayan bir başarısızlık şansı vardır. UUID'lerin çarpışmasından çok daha büyük olasılıkla sorunlara (yani aklınıza gelebilecek hemen hemen her şeye) konsantre olurdum.

"Mantıklı" ya da sizin deyiminizle "etkili" üzerine bir vurgu: Gerçek dünyanın nasıl çalıştığı yeterince iyi. "Pratik olarak benzersiz" ve "gerçekten benzersiz" arasındaki bu boşluğun kapatılmasında yer alan hesaplama işinin miktarı çok büyük. Benzersizlik, azalan getiri sağlayan bir eğridir. Bu eğrinin bir noktasında, "yeterince benzersiz" in hala karşılanabilir olduğu bir çizgi vardır ve o zaman ÇOK dik bir şekilde eğiliriz. Daha fazla benzersizlik eklemenin maliyeti oldukça büyük hale gelir. Sonsuz benzersizliğin sonsuz maliyeti vardır.

UUID / GUID, nispeten konuşursak, evrensel olarak benzersiz olduğu makul olarak kabul edilebilecek bir kimlik oluşturmanın hesaplama açısından hızlı ve kolay bir yoludur . Bu, daha önce bağlantısız sistemlerden gelen verileri entegre etmesi gereken birçok sistemde çok önemlidir. Örneğin, iki farklı platformda çalışan ancak bir noktada içeriği bir sistemden diğerine aktarmanız gereken bir İçerik Yönetim Sisteminiz varsa. Kimliklerin değişmesini istemezsiniz, bu nedenle sistem A'dan gelen veriler arasındaki referanslarınız bozulmadan kalır, ancak sistem B'de oluşturulan verilerle herhangi bir çarpışma istemezsiniz. Bir UUID bunu çözer.

Bir UUID oluşturmak kesinlikle gerekli değildir. Bununla birlikte, çevrimdışı kullanıcıların her birinin çok düşük bir çarpışma olasılığı olan bir şey için bir anahtar oluşturabileceği bir standarda sahip olmak uygundur .

Bu, veritabanı çoğaltma çözümüne vb. Yardımcı olabilir.

Çevrimiçi kullanıcıların ek yük veya çarpışma olasılığı olmadan bir şey için benzersiz anahtarlar üretmesi kolay olurdu , ancak UUID'lerin amacı bu değil.

Her neyse, Wikipedia'dan alınan, çarpışma olasılığı hakkında bir kelime:

Bu rakamları bir perspektife koymak için, bir kişinin bir göktaşı tarafından vurulma riskinin yıllık 17 milyarda bir olduğu tahmin edilmektedir, bu da bir yılda birkaç on trilyon UUID oluşturma ve bir kopyaya sahip olma olasılığına eşittir. Başka bir deyişle, yalnızca önümüzdeki 100 yıl boyunca her saniye 1 milyar UUID oluşturduktan sonra, yalnızca bir kopya oluşturma olasılığı yaklaşık% 50 olacaktır.

Klasik bir örnek, iki veritabanı arasında kopyalama yaptığınız zamandır.

DB (A), int ID 10 ile bir kayıt ekler ve aynı zamanda DB (B), ID 10'da bir kayıt oluşturur. Bu bir çarpışmadır.

UUID'lerle eşleşmeyeceklerinden bu olmayacak. (neredeyse kesin)

Ayrıca vücudunuzdaki her parçacığın oturduğunuz sandalyeden aynı anda tünel açması ve kendinizi aniden yerde otururken bulmanızın sıfır olmayan bir olasılık da vardır.

Bunun için endişeleniyor musun?

UUID'lerden kaçınmak için bir planım var. Bir yere bir sunucu kurun ve ona sahip olun, böylece bir yazılım parçası evrensel olarak benzersiz bir tanımlayıcı istediğinde, o sunucuyla bağlantı kurar ve sunucu bir tanesini verir. Basit!

Açıkça kötü niyetleri görmezden gelsek bile, bununla ilgili bazı gerçek pratik sorunlar olması dışında. Özellikle, bu sunucu başarısız olabilir veya internetin bir kısmından erişilemez hale gelebilir. Sunucu arızasıyla başa çıkmak çoğaltma gerektirir ve bunu düzeltmek çok zordur (fikir birliği oluşturmanın neden tuhaf olduğunu öğrenmek için Paxos algoritmasına ilişkin literatüre bakın) ve oldukça yavaştır. Ayrıca, tüm sunuculara 'ağın belirli bir kısmından erişilemezse, o alt ağa bağlı istemcilerden hiçbiri hiçbir şey yapamayacaktır çünkü hepsi yeni kimlikleri bekleyecektir.

Öyleyse ... Dünyanın ömrü boyunca başarısız olma olasılığı düşük olan bunları oluşturmak için basit bir olasılık algoritması kullanın veya (fon edin ve) bir dağıtım PITA'sı olacak ve sık sık arızalara neden olacak büyük bir altyapı oluşturun. Hangisine gideceğimi biliyorum.

Çarpışma olasılığı hakkındaki tüm konuşmayı anlamıyorum. Çarpışma umurumda değil. Yine de performansı önemsiyorum.

https://dba.stackexchange.com/a/119129/33649

UUID'ler, çok büyük tablolar için bir performans felaketidir. (200.000 satır "çok büyük" değildir.)

KARAKTER SETİ utf8 - CHAR (36) 108 bayt yer kapladığında 3 numaranız gerçekten kötüdür!

UUID'ler (GUID'ler) çok "rastgele" dir. Bunları büyük tablolarda UNIQUE veya PRIMARY anahtar olarak kullanmak çok verimsizdir. Bunun nedeni, her yeni UUID veya SELECT by UUID INSERT'inizde tablo / indeks etrafında atlamak zorunda olmanızdır. Tablo / dizin önbelleğe sığmayacak kadar büyük olduğunda (bkz. İnnodb_buffer_pool_size, RAM'den daha küçük olması gerekir, tipik olarak% 70), 'sonraki' UUID önbelleğe alınmayabilir, dolayısıyla yavaş disk vuruşu. Tablo / dizin önbellekten 20 kat daha büyük olduğunda, isabetlerin yalnızca 1 / 20'si (% 5) önbelleğe alınır - siz G / Ç'ye bağlısınız.

Bu nedenle, UUID'leri de kullanmayın.

"küçük" masalarınız var veya farklı yerlerden benzersiz kimlikler oluşturduğunuz için onlara gerçekten ihtiyacınız var (ve bunu yapmanın başka bir yolunu bulamadınız). UUID'ler hakkında daha fazla bilgi: http://mysql.rjweb.org/doc.php/uuid (Standart 36 karakterli UUID'ler ile BINARY (16) arasında dönüştürme yapmak için işlevler içerir.)

Aynı tabloda hem UNIQUE AUTO_INCREMENT hem de UNIQUE UUID'ye sahip olmak israftır.

Bir INSERT oluştuğunda, tüm benzersiz / birincil anahtarların kopyalar için kontrol edilmesi gerekir. InnoDB'nin PRIMARY ANAHTAR sahibi olma gereksinimi için her iki benzersiz anahtar yeterlidir. BINARY (16) (16 bayt) biraz hantal (PK yapmaya karşı bir argüman), ama o kadar da kötü değil. İkincil anahtarlarınız olduğunda hacim önemlidir. InnoDB, PK'yi her ikincil anahtarın sonuna sessizce yapıştırır. Buradaki ana ders, özellikle çok büyük tablolar için ikincil anahtarların sayısını en aza indirmektir. Karşılaştırma için: INT UNSIGNED, 0,4 milyar aralığı ile 4 bayttır. BIGINT 8 bayttır.

Örneğin basit bir veritabanı uygulaması için alternatiflere bakarsanız, yeni bir nesne oluşturmadan önce her seferinde veritabanını sorgulamak zorunda kalırsanız, UUID kullanmanın sisteminizin karmaşıklığını etkili bir şekilde azaltabileceğini göreceksiniz. Verilen - int anahtarları kullanırsanız, 128bit UUID'nin dörtte birinde saklanacak olan 32bit vardır. Verilen - UUID oluşturma algoritmaları, bir sayıyı artırmaktan daha fazla hesaplama gücü kullanır. Ama kim umursar? Aksi takdirde benzersiz numaralar atamak için bir "otorite" yi yönetmenin ek yükü, amaçladığınız benzersiz kimlik alanına bağlı olarak, büyüklük sırasına göre bundan kolayca ağır basar.

UUID'de == tembel tasarım

Kavgalarını seçmek konusunda hemfikir değilim. Yinelenen bir UUID istatistiksel olarak imkansızsa ve matematik kanıtlanmışsa neden endişelenelim? Küçük N UUID oluşturma sisteminiz etrafında tasarım yapmak için zaman harcamak pratik değildir, sisteminizi geliştirmenin her zaman bir düzine başka yolu vardır.

Son işimde, UUID ile benzersiz şekilde tanımlanmış üçüncü şahıslardan nesneler alıyorduk. Bir UUID-> uzun tamsayı arama tablosu koydum ve birincil anahtarlarım olarak uzun tamsayı kullandım çünkü bu şekilde çok daha hızlıydı.

Sürüm 1 algoritmasını kullanarak, aynı MAC adresinden milisaniye başına 10 UUID'den daha az üretildiği kısıtlaması altında çarpışmanın imkansız olduğu görülmektedir.

Kavramsal olarak, UUID'ler için orijinal (sürüm 1) oluşturma şeması, UUID sürümünü, UUID'yi oluşturan bilgisayarın MAC adresiyle ve Batı'da Miladi takvimin benimsenmesinden bu yana 100 nanosaniye aralıkların sayısıyla birleştirmekti. . Pratikte, gerçek algoritma daha karmaşıktır. Bu şema yeterince "opak" olmadığı için eleştirildi; hem UUID'yi oluşturan bilgisayarın kimliğini hem de bunu yaptığı zamanı gösterir.

Nasıl çalıştığını yanlış anladıysam birisi beni düzeltir

Onlar çünkü UUIDs diyenlerin için kötü tasarım vardır olabilir DB tuşları olmaz oluşturulan iken çarpmasıyla, (bazı gülünç küçük olasılık at), ... sen DB üzerinde bir çarpışma neden insan hatası olasılığı nedeniyle bazı un anahtarları oluşturulan biliyorum - Öngörülen ihtiyaç, UUID4 çarpışma olasılığından FAR FAR FAR daha yüksektir. Biz biliyoruz db yeniden takdirde yine 1 ile kimlikleri başlayacağını ve kaç bizi biz emin biz hiç gerek asla iken bir tablo yeniden zorunda? Bilinmeyen bilinmeyenlerle işler ters gitmeye başladığında paramı UUID güvenliğine yatırırdım.

Bir UUID gerektiren başka birinin API'sini kullanmanız gereken durumlar dışında, elbette her zaman başka bir çözüm vardır. Ancak bu alternatifler UUID'lerin yaptığı tüm sorunları çözecek mi? Hepsini tek seferde çözebilecekken, her biri farklı bir sorunu çözmek için daha fazla hack katmanı ekleyecek misiniz?

Evet, UUID'lerin çarpışması teorik olarak mümkündür. Başkalarının da belirttiği gibi, gülünç bir şekilde, dikkate alınmaya değmeyeceği noktaya gelme olasılığı düşüktür. Bugüne kadar hiç olmadı ve büyük olasılıkla asla olmayacak. Unut gitsin.

Çarpışmalardan kaçınmanın en "açık" yolu, tek bir sunucunun her eklentide benzersiz kimlikler oluşturmasına izin vermektir, bu açık bir şekilde ciddi performans sorunları yaratır ve çevrimdışı oluşturma sorununu hiç çözmez. Hata.

Diğer "açık" çözüm, benzersiz sayı bloklarını önceden dağıtan merkezi bir otoritedir; bu, UUID V1'in esasen üretici makinenin MAC adresini kullanarak yaptığı şeydir (IEEE OUI aracılığıyla). Ancak yinelenen MAC adresleri, her merkezi otoritenin eninde sonunda çuvalladığı için meydana gelir, bu nedenle pratikte bu, bir UUID V4 çarpışmasından çok daha olasıdır. Hata.

UUID'lerin kullanılmasına karşı en iyi argüman "çok büyük" olmalarıdır, ancak (önemli ölçüde) daha küçük bir şema kaçınılmaz olarak en ilginç sorunları çözmede başarısız olacaktır; UUID'lerin boyutu, bu problemleri çözmedeki yararlılıklarının doğal bir yan etkisidir.

Sorununuzun UUID'lerin sunduklarına ihtiyaç duyacak kadar büyük olmaması mümkündür ve bu durumda başka bir şey kullanmaktan çekinmeyin. Ancak probleminiz beklenmedik bir şekilde büyürse (ve çoğu büyürse), daha sonra geçiş yaparsınız ve ilk başta bunları kullanmadığınız için kendinizi tekmelersiniz. Başarı için tasarlamak o kadar kolayken neden başarısızlık için tasarım yapasınız ki?

UUID'ler, farklı kit parçalarına dağıtılabilen süper küresel değişkenler olduklarından daha kötüsü, küresel değişkenlerle ilişkili tüm kötü kodlama uygulamalarını içerir.

Son zamanlarda, bir yazıcının tam bir değiştirme modeliyle değiştirilmesiyle böyle bir soruna rastlandı ve istemci yazılımlarından hiçbirinin çalışmayacağını gördü.