UUID જનરેટર

UUID v4 જનરેટર: શું છે અને કેવી રીતે કામ કરે છે

આ પેજ તમારા માટે એક અથવા વધુ UUID v4 ઓળખકર્તાઓ જનરેટ કરે છે — 36 અક્ષરોની રેન્ડમ સ્ટ્રિંગ, જે 8-4-4-4-12 હેક્સ ફોર્મેટમાં હોય છે. તમે નક્કી કરી શકો છો કે કેટલા આઈડી જોઈએ (મહત્તમ 100), અને તે અપરકેસમાં દેખાય કે લોઅરકેસમાં, કે તેમાં હાઇફન હોય કે ન હોય. આ બધી પ્રક્રિયા તમારા બ્રાઉઝરમાં જ થાય છે, સર્વર પર કંઈ મોકલાતું નથી. તમે એક આઈડી ક્લિક કરીને ક્લિપબોર્ડ પર કૉપિ કરી શકો છો, અથવા "કૉપિ ઑલ" બટન વડે બધા જ આઈડી એકસાથે કૉપિ કરી શકો છો.

UUID v4 122 બીટ્સની રેન્ડમનેસ વાપરે છે, તેમાં કોઈ એમ્બેડેડ ટાઈમસ્ટેમ્પ નથી. આથી દરેક મૂલ્ય અનુમાન કરી શકાય તેમ નથી, અને બે સરખા આઈડી મળવાની સંભાવના સામાન્ય રીતે ગણી શકાય તેટલી ઓછી છે. UUID v7 અથવા ULIDથી વિપરીત, v4 આઈડી કોઈ ચોક્કસ ક્રમમાં ગોઠવાતા નથી — તેમનામાં સમયની કોઈ માહિતી હોતી નથી. તેથી જો તમે તેને ડેટાબેઝમાં પ્રાથમિક કી તરીકે વાપરો છો, તો તે ડેટાબેઝના ઈન્ડેક્સને વિખેરી શકે છે, કારણ કે તે કોઈ ચોક્કસ ક્રમમાં સૉર્ટ થતા નથી.

આ પેજ તમને અપરકેસ અને હાઇફન ટૉગલ કરવાની સુવિધા આપે છે. ડિફૉલ્ટ આઉટપુટ લોઅરકેસ અને હાઇફન સાથે હોય છે. કોઈપણ વિકલ્પ બદલવાથી આખો સેટ ફરીથી જનરેટ થાય છે.

UUID v4 ની રચના અને 122 બીટ રેન્ડમનેસ

UUID v4 16 ઓક્ટેટ્સ (128 બીટ્સ) માંથી બનેલો હોય છે. પરંતુ તેમાંના 6 બીટ્સ વર્ઝન અને વેરિઅન્ટ માટે નિશ્ચિત હોય છે. બાકીના 122 બીટ્સ સંપૂર્ણપણે રેન્ડમ હોય છે. આ 122 બીટ્સને 32 હેક્સ અક્ષરોમાં દર્શાવવામાં આવે છે, અને જ્યારે હાઇફન ચાલુ હોય ત્યારે 8-4-4-4-12 પેટર્નમાં 4 હાઇફન ઉમેરવામાં આવે છે, જે કુલ 36 અક્ષરો બનાવે છે.

આ ફોર્મેટ RFC 4122 માં વ્યાખ્યાયિત થયેલ છે. દરેક UUID v4 આઈડીમાં ચોથા ઓક્ટેટના ચાર બીટ્સ વર્ઝન નંબર 4 દર્શાવે છે, અને આઠમા ઓક્ટેટના બે બીટ્સ વેરિઅન્ટ 10 દર્શાવે છે. મતલબ, રેન્ડમ ભાગમાંથી 6 બીટ્સ નિશ્ચિત હોય છે, અને બાકીના 122 બીટ્સ જ રેન્ડમ હોય છે.

આ જ કારણ છે કે UUID v4 ને "રેન્ડમ UUID" પણ કહેવામાં આવે છે. તેમાં સમય, મશીન આઈડી, અથવા અન્ય કોઈ ઓળખી શકાય તેવી માહિતી હોતી નથી. દરેક આઈડી બીજા કોઈપણ આઈડીથી સ્વતંત્ર હોય છે.

બ્રાઉઝર રેન્ડમનેસ અને સુરક્ષા

આ પેજ પરનું બધું જ જનરેશન તમારા બ્રાઉઝરમાં જ થાય છે. તેના માટે crypto.getRandomValues() API વપરાય છે, જે ક્રિપ્ટોગ્રાફિક રીતે સુરક્ષિત સ્યુડોરેન્ડમ નંબર જનરેટર (CSPRNG) છે. આનો અર્થ એ કે તમારી માહિતી ક્યારેય સર્વર પર નથી મોકલાતી, અને કોઈ તૃતીય પક્ષ તેને જોઈ શકતો નથી.

આ સુવિધા સુરક્ષા-સંવેદનશીલ એપ્લિકેશનો માટે ખૂબ જ ઉપયોગી છે — જેમ કે સેશન આઈડી, ટોકન્સ, અથવા એક વખત વપરાતા પાસવર્ડ (OTP). જનરેશન દરમિયાન કોઈપણ નેટવર્ક કૉલ થતો નથી, તેથી ઈન્ટરનેટ કનેક્શન ન હોય તો પણ તમે આઈડી જનરેટ કરી શકો છો.

બ્રાઉઝરનો CSPRNG ઓપરેટિંગ સિસ્ટમના રેન્ડમનેસ સ્ત્રોતો પર આધાર રાખે છે. આમાં CPU રેન્ડમનેસ, માઉસ મૂવમેન્ટ, કીબોર્ડ ઇનપુટ, અને અન્ય સિસ્ટમ સ્ત્રોતો શામેલ છે. આથી જનરેટ થયેલા આઈડી ખૂબ જ ઉચ્ચ ગુણવત્તાના હોય છે અને તેમનું અનુમાન લગાવવું લગભગ અશક્ય છે.

ટકરાવની સંભાવના: 122 બીટ્સ કેમ પૂરતા છે

UUID v4 માં 122 રેન્ડમ બીટ્સ હોય છે. આથી કુલ શક્ય અનન્ય આઈડીની સંખ્યા 2^122 = 5.3 × 10^36 છે. આટલી મોટી સંખ્યામાં ટકરાવ (collision) ની સંભાવના ગણવા માટે જન્મદિવસ સમસ્યા (birthday problem) નો ઉપયોગ થાય છે.

જન્મદિવસ સમસ્યા મુજબ, જો N શક્ય મૂલ્યો હોય, તો ટકરાવની 50% સંભાવના આવરી લેવા માટે આશરે sqrt(N) મૂલ્યો જનરેટ કરવા પડે. UUID v4 માટે, આ આંકડો લગભગ 2^61 = 2.3 × 10^18 આઈડી છે. વ્યવહારમાં, આ રોજિંદા ઉપયોગથી ઘણો મોટો આંકડો છે.

ઉદાહરણ તરીકે, જો તમે દર સેકન્ડે 1 બિલિયન UUID v4 આઈડી જનરેટ કરો, તો 50% ટકરાવની સંભાવના આવરી લેવા માટે લગભગ 73,000 વર્ષ લાગશે. આથી, સામાન્ય એપ્લિકેશનો માટે આ સંભાવના નગણ્ય છે.

પરંતુ, આ ફક્ત સૈદ્ધાંતિક ગણતરી છે. વાસ્તવમાં, બ્રાઉઝરનો રેન્ડમનેસ સ્ત્રોત સંપૂર્ણપણે રેન્ડમ હોય છે, અને દરેક વખતે જનરેટ થતા આઈડી સંપૂર્ણપણે અલગ હોય છે. કોઈપણ જાણીતા હુમલાથી આઈડીની આગાહી કરી શકાતી નથી.

ડેટાબેઝ પર અસર: ઈન્ડેક્સ ફ્રેગમેન્ટેશન

UUID v4 નો સૌથી મોટો ગેરલાભ ડેટાબેઝમાં પ્રાથમિક કી તરીકે ઉપયોગ કરતી વખતે જોવા મળે છે. કારણ કે v4 આઈડી રેન્ડમ હોય છે, તે કોઈ ચોક્કસ ક્રમમાં સૉર્ટ થતા નથી. જ્યારે તમે ડેટાબેઝમાં નવો રેકોર્ડ ઉમેરો છો, ત્યારે નવો આઈડી ગમે ત્યાં શામેલ થઈ શકે છે — શરૂઆતમાં, વચ્ચે, અથવા અંતમાં.

આનાથી B-ટ્રી ઈન્ડેક્સમાં ઘણી પેજ સ્પ્લિટ થાય છે. દર વખતે જ્યારે નવો આઈડી શામેલ થાય છે અને તેની સાથે સંબંધિત ઈન્ડેક્સ પેજ ભરાઈ ગયું હોય, ત્યારે ડેટાબેઝને તે પેજને બે ભાગમાં વિભાજીત કરવું પડે છે. આ પ્રક્રિયા ખર્ચાળ છે અને ડેટાબેઝ પર ભાર વધારે છે.

દાખલા તરીકે, PostgreSQL માં, રેન્ડમ UUID v4 સાથે ઈન્ડેક્સ ફ્રેગમેન્ટેશન ઘણી વાર 40-50% સુધી પહોંચી શકે છે. આનાથી ક્વેરી પ્રદર્શન ધીમું થાય છે, કારણ કે ડેટાબેઝને વધુ ઈન્ડેક્સ પેજ સ્કેન કરવા પડે છે.

સરખામણીમાં, UUID v7 અથવા ULID જેવા સમય-સૉર્ટ કરી શકાય તેવા આઈડી, મોટાભાગે ક્રમિક રીતે શામેલ થાય છે. આથી ઈન્ડેક્સ ફ્રેગમેન્ટેશન ઓછું થાય છે અને પ્રદર્શન સારું રહે છે.

પરંતુ, UUID v4 ની અનુમાન ન કરી શકાય તેવી પ્રકૃતિ કેટલીક એપ્લિકેશનો માટે ખૂબ જરૂરી છે — જેમ કે સુરક્ષા ટોકન્સ, સેશન આઈડી, અને વપરાશકર્તા આઈડી. આવા કિસ્સાઓમાં, ડેટાબેઝ ઑપ્ટિમાઇઝેશન અને ઈન્ડેક્સ ફ્રેગમેન્ટેશનને સ્વીકારવું પડે છે.

અપરકેસ અને હાઇફનના ટૉગલની અસર

આ પેજ પરના બે ટૉગલ — અપરકેસ અને હાઇફન — આઉટપુટના ફોર્મેટને અસર કરે છે. ડિફૉલ્ટ સ્ટેટસ લોઅરકેસ અને હાઇફન સાથે છે. જો તમે અપરકેસ ટૉગલ ચાલુ કરો, તો બધા હેક્સ અક્ષરો મોટા અક્ષરોમાં દેખાશે: 550E8400-E29B-41D4-A716-446655440000. જો હાઇફન બંધ કરો, તો 32 હેક્સ અક્ષરો સાથે કોઈ હાઇફન નહીં હોય: 550e8400e29b41d4a716446655440000.

આ ટૉગલનો ઉપયોગ તમારી એપ્લિકેશનની જરૂરિયાત મુજબ કરી શકાય છે. કેટલીક API અમુક ફોર્મેટની અપેક્ષા રાખે છે. ઉદાહરણ તરીકે, Windows રજિસ્ટ્રી ઘણીવાર અપરકેસ UUID ને પસંદ કરે છે, જ્યારે Linux અને macOS સામાન્ય રીતે લોઅરકેસ સાથે હાઇફન સ્વીકારે છે.

આ ટૉગલ બદલવાથી આખો સેટ ફરીથી જનરેટ થાય છે. આથી જો તમે 100 આઈડી જનરેટ કર્યા હોય અને પછી ફોર્મેટ બદલો, તો નવા 100 આઈડી જનરેટ થશે. આનો અર્થ એ કે ફોર્મેટ બદલતી વખતે જૂના આઈડી ગુમ થઈ જશે. આથી, જરૂરી હોય તો ફોર્મેટ બદલતા પહેલા બધા આઈડી કૉપિ કરી લેવા.

અન્ય ફોર્મેટ સાથે સરખામણી: UUID v7, ULID, NanoID

આ પેજ તમને UUID v4, UUID v7, ULID, અને NanoID ફોર્મેટ વચ્ચે પસંદગી કરવા દે છે. પરંતુ જ્યારે તમે UUID v4 પસંદ કરો છો, ત્યારે તેના અનન્ય ગુણધર્મો સમજવા મહત્વપૂર્ણ છે.

UUID v4 સૌથી વધુ રેન્ડમ બીટ્સ (122) પ્રદાન કરે છે. આથી અનુમાન કરવું સૌથી મુશ્કેલ છે. પરંતુ તેમાં સમયની માહિતી ન હોવાથી, તે ડેટાબેઝ ઈન્ડેક્સ માટે શ્રેષ્ઠ નથી.

UUID v7 તેનાથી વિપરીત છે — તેમાં 48 બીટ્સ ટાઈમસ્ટેમ્પ અને 74 બીટ્સ રેન્ડમનેસ હોય છે. આથી તે સમય પ્રમાણે સૉર્ટ થઈ શકે છે, અને ઈન્ડેક્સ ફ્રેગમેન્ટેશન ઓછું થાય છે. પરંતુ તેમાં રેન્ડમનેસ ઓછી છે.

ULID પણ સમય-સૉર્ટ કરી શકાય છે, પરંતુ તેનું ફોર્મેટ અલગ છે — 26 અક્ષરોમાં ક્રોકફોર્ડ બેઝ32 એન્કોડિંગ વાપરે છે. NanoID સૌથી નાનું (ડિફૉલ્ટ 21 અક્ષરો) છે અને તે URL-સુરક્ષિત અક્ષરોનો ઉપયોગ કરે છે.

તમારી પસંદગી તમારી જરૂરિયાત પર આધાર રાખે છે. જો સુરક્ષા અને અનુમાન ન કરી શકાય તેવો ગુણધર્મ મહત્વપૂર્ણ હોય, તો UUID v4 શ્રેષ્ઠ છે. જો ડેટાબેઝ પ્રદર્શન મહત્વપૂર્ણ હોય, તો UUID v7 અથવા ULID વિચારી શકો છો.

FAQ

1. UUID v4 માં ટકરાવની સંભાવના કેટલી છે? 2^122 શક્ય મૂલ્યો સાથે, 50% ટકરાવની સંભાવના આવરી લેવા લગભગ 2.3 × 10^18 આઈડી જનરેટ કરવા પડે. વ્યવહારમાં, આ સંભાવના નગણ્ય છે.

2. શું હું UUID v4 ને ડેટાબેઝમાં પ્રાથમિક કી તરીકે વાપરી શકું? હા, પરંતુ ધ્યાન રાખો. તેનાથી ઈન્ડેક્સ ફ્રેગમેન્ટેશન થાય છે, કારણ કે રેન્ડમ આઈડી કોઈ ક્રમમાં સૉર્ટ થતા નથી. સમય-સૉર્ટ કરી શકાય તેવા વિકલ્પો (UUID v7, ULID) ડેટાબેઝ માટે વધુ સારા છે.

3. શું આ પેજ મારી માહિતી સર્વર પર મોકલે છે? ના. બધું જ જનરેશન તમારા બ્રાઉઝરમાં જ થાય છે. કોઈપણ માહિતી સર્વર પર મોકલાતી નથી.

4. હું 100 થી વધુ આઈડી કેવી રીતે જનરેટ કરી શકું? આ પેજ મહત્તમ 100 આઈડી જનરેટ કરે છે. જો તમને વધુ જોઈએ, તો તમે બહુવિધ વખત જનરેટ કરી શકો છો.

5. અપરકેસ અને લોઅરકેસ વચ્ચે શું તફાવત છે? કોઈ તકનીકી તફાવત નથી. બંને સમાન UUID છે. ફક્ત દેખાવ બદલાય છે. કેટલીક સિસ્ટમો અપરકેસ પસંદ કરે છે, કેટલીક લોઅરકેસ.

6. શું હું UUID v4 ને ફરીથી જનરેટ કર્યા વગર ફોર્મેટ બદલી શકું? ના. જ્યારે તમે કોઈપણ વિકલ્પ (કાઉન્ટ, અપરકેસ, હાઇફન) બદલો છો, ત્યારે આખો સેટ ફરીથી જનરેટ થાય છે. જૂના આઈડી સાચવવા હોય તો પહેલા તેમને કૉપિ કરી લો.