ہر جدید ڈیٹا بیس، تقسیم شدہ نظام، اور API منفرد شناخت کار استعمال کرتے ہیں — اور 2026 میں، انہیں کنٹرول کرنے والا معیار بنیادی طور پر بدل گیا ہے۔ UUID (یونیورسل یونیک آئیڈنٹیفائر) ایک 128-بِٹ لیبل ہے جو کسی بھی مرکزی رابطہ کے بغیر کمپیوٹر سسٹمز کے درمیان معلومات کی شناخت کر سکتا ہے۔ نئے RFC 9562 (جس نے مئی 2024 میں RFC 4122 کی جگہ لی) کے تحت، منظر نامہ بدل گیا ہے: UUID v4 اب بھی بے ترتیب IDs کے لیے انتخاب ہے، لیکن UUID v7 اب ڈیٹا بیس کی بنیادی کلیدوں کے لیے تجویز کردہ معیار ہے، کیونکہ اس کا وقت کے مطابق ترتیب والا ڈھانچہ B-tree انڈیکس کے ٹکڑے ٹکڑے ہونے کو روکتا ہے۔
یہ گائیڈ مکمل تصویر پیش کرتا ہے: UUIDs کیسے کام کرتے ہیں، کون سا ورژن کب استعمال کریں، اور انہیں درست طریقے سے کیسے نافذ کریں۔
RFC 9562 کو سمجھنا: جدید UUID معیار
UUID ایک 128-بِٹ نمبر ہے جس کی انفرادیت عملی طور پر یقینی ہے — کسی مرکقی اتھارٹی کی ضرورت نہیں۔ ویکیپیڈیا کے مطابق، دو UUIDs کے ٹکرانے کا امکان صفر کے اتنے قریب ہے کہ حقیقی ایپلی کیشنز کے لیے ناممکن سمجھا جاتا ہے۔ مختلف ٹیمیں آزادانہ طور پر ڈیٹا کو لیبل کر سکتی ہیں، اس یقین کے ساتھ کہ ان کے IDs ٹکرائیں گے نہیں۔
مئی 2024 میں، IETF نے RFC 9562 جاری کیا، پرانا RFC 4122 ریٹائر کر دیا۔ یہ اپ ڈیٹ جدید تقسیم شدہ سسٹمز کے مطالبات کا جواب تھا، جنہیں ایسے IDs چاہیے تھے جو منفرد بھی ہوں اور وقت کے مطابق ترتیب دینے کے قابل بھی۔ تین نئے ورژن متعارف کرائے گئے: v6، v7، اور v8۔
UUID کی اناٹومی: ورژن اور ویرینٹس
آپ عموماً UUID کو 32 ہیکزاڈیسمل حروف کے طور پر دیکھتے ہیں جو ہائیفن سے پانچ گروپوں میں تقسیم ہوتے ہیں (8-4-4-4-12):
550e8400-e29b-41d4-a716-446655440000
^
version
دو کلیدی فیلڈز آپ کو بتاتے ہیں کہ UUID کیسے بنایا گیا:
| فیلڈ | مقام | یہ کیا بتاتا ہے |
|---|---|---|
| ورژن بِٹس | ساتویں بائٹ کے پہلے 4 بِٹس (تیسرے گروپ کا پہلا حرف) | کون سا الگورتھم استعمال ہوا (مثلاً "4” = v4، "7” = v7) |
| ویرینٹ بِٹس | نویں بائٹ | UUID ویرینٹ — RFC 9562 ایک 10 بِٹ پیٹرن استعمال کرتا ہے |
جیسا کہ SnapUtils وضاحت کرتا ہے، ویرینٹ بِٹس جدید RFC 9562 UUIDs کو پرانے Apollo یا Microsoft فارمیٹس سے الگ کرتے ہیں۔
UUID v7 ڈیٹا بیس کا نیا گولڈن اسٹینڈرڈ کیوں ہے
UUID v4 کا سب سے بڑا نقصان یہ ہے کہ یہ مکمل طور پر بے ترتیب ہے۔ جب B-tree انڈیکس میں بنیادی کلید کے طور پر استعمال ہوتا ہے، تو ڈیٹا بیس کو غیر متوقع مقامات پر نئی قطاریں داخل کرنی پڑتی ہیں۔ CreateUUID کے مطابق، یہ "پیج اسپلٹس” کا سبب بنتا ہے — ڈیٹا بیس کو جگہ بنانے کے لیے مسلسل ڈیٹا کو دوبارہ منظم کرنا پڑتا ہے، جس سے تحریر سست ہوتی ہے اور میموری ضائع ہوتی ہے۔
UUID v7 اسے ID کے آغاز میں ایک 48-بِٹ Unix Epoch ٹائم اسٹیمپ (ملی سیکنڈ کی درستگی) رکھ کر حل کرتا ہے۔ اس سے IDs یکساں بڑھتے ہیں — نئے ہمیشہ پرانے سے بڑے ہوتے ہیں۔ ڈیٹا بیس محض انڈیکس کے آخر میں شامل کر سکتا ہے، آپ کو یکساں بڑھتے عدد کی کارکردگی UUID کی عالمی انفرادیت کے ساتھ دیتا ہے۔
UUID v7 وقت اور انٹروپی کو کیسے متوازن رکھتا ہے
UUID v7 باقی 74 بِٹس کو ایک CSPRNG (کرپٹوگرافکلی سیکیور pseudo-random نمبر جنریٹر) سے بھرتا ہے۔ ویکیپیڈیا کے مطابق، آپ کو 50% تصادم کے امکان تک پہنچنے کے لیے تقریباً ایک سیکنڈ میں 1 بلین UUIDs 85 سال تک پیدا کرنے ہوں گے۔ کسی بھی حقیقی ایپلی کیشن کے لیے، UUID v7 عملاً تصادم سے محفوظ ہے۔
اسٹوریج کی بہترین مشقیں: Binary(16) بمقابلہ String(36)
آپ UUIDs کو کیسے اسٹور کرتے ہیں، یہ اسی بات جیسی اہمیت رکھتا ہے جتنا کہ آپ کون سا ورژن استعمال کرتے ہیں:
| اسٹوریج فارمیٹ | جگہ | انڈیکس کارکردگی | تجویز |
|---|---|---|---|
| Binary(16) | 16 بائٹ | زیادہ (متراصم) | بہترین مشق |
| اصل UUID ٹائپ | 16 بائٹ | زیادہ (بہترین) | PostgreSQL کے لیے بہترین |
| سٹرنگ (Char 36) | 36–72 بائٹ | کم (ٹکڑے ٹکڑے) | گریز کریں |
SnapUtils ہمیشہ سٹرنگز کے بجائے اصل ٹائپس استعمال کرنے کی تجویز دیتا ہے۔ PostgreSQL میں، اصل uuid ٹائپ ڈیٹا کو ایک متراصم 16-بائٹ بائنری فارمیٹ میں اسٹور کرتا ہے جبکہ معیاری سٹرنگ پر مبنی استفسارات کی بھی سہولت دیتا ہے۔
UUID بمقابلہ GUID: کوئی فرق ہے؟
GUID (گلوبل یونیک آئیڈنٹیفائر) UUID معیار کا مائیکروسافٹ کا نفاذ ہے۔ تاریخی طور پر، بائٹ کی ترتیب (endianness) میں فرق تھا — ابتدائی مائیکروسافٹ GUIDs نے پہلے تین فیلڈز کے لیے little-endian استعمال کیا، جبکہ معیاری UUIDs نے big-endian (نیٹ ورک بائٹ آرڈر) استعمال کیا (SnapUtils)۔
2026 تک، یہ زیادہ تر ایک نام رکھنے کا رواج ہے۔ RFC 9562 کے تحت، یہ یکساں کام کرتے ہیں۔ .NET میں Guid.NewGuid() پائتھن میں uuid.uuid4() کے ساتھ مکمل مطابقت رکھتا ہے۔ آپ Windows/Azure کے حلقوں میں "GUID” اور لینکس اور اوپن سورس کمیونٹیز میں "UUID” سنیں گے۔
جدید UUIDs کا نفاذ: زبان بہ زبان
| زبان | UUID v4 | UUID v7 |
|---|---|---|
| Python | بلٹ ان uuid ماڈیول |
uuid6 یا uuid7 پیکیج |
| JavaScript | crypto.randomUUID() |
uuid npm پیکیج (v10+) |
| PostgreSQL | gen_random_uuid() (PG 13+) |
اصل uuidv7() (PG 17+) یا ایکسٹینشنز |
| .NET | Guid.NewGuid() |
کمیونٹی پیکیجز |
| Rust | uuid crate (v1.7+) |
v7 فیچر کے ساتھ uuid crate |
حتمی IDs: UUID v5
اگر آپ کو کسی دیے گئے ان پٹ (جیسے URL یا صارف نام) کے لیے ہر بار وہی ID درکار ہو، تو UUID v5 استعمال کریں۔ یہ ایک namespace UUID اور name سٹرنگ کو SHA-1 سے ہیش کرتا ہے — جب آپ مرکزی ڈیٹا بیس سے استفسار نہیں کر سکتے تو ڈی ڈپلیکیشن کے لیے بہترین ہے۔
UUID v1 کا پرائیویسی سبق
UUID v1 ٹائم اسٹیمپ اور کمپیوٹر کے MAC ایڈریس کا استعمال کرتا ہے۔ اسے بڑی حد تک ترک کر دیا گیا ہے کیونکہ یہ ہارڈویئر کی معلومات لیک کرتا ہے۔ ایک مشہور مثال: میلیسا وائرس کا سازکار اسی لیے پکڑا گیا کیونکہ متاثرہ ورڈ دستاویزات میں UUIDs میں اس کا مخصوص MAC ایڈریس شامل تھا۔
ایڈوانس RFC 9562: v6، v8، اور خاص UUIDs
RFC 9562 نے تقسیم شدہ نظام کی مخصوص ضروریات کے لیے خاص ورژنز شامل کیے:
| ورژن | مقصد | کب استعمال کریں |
|---|---|---|
| v6 | دوبارہ ترتیب دیا گیا v1 ٹائم اسٹیمپ — ترتیب دینے کے قابل جبکہ v1 کی درستگی برقرار | لاجد v1 سسٹمز کی منتقلی |
| v8 | کسٹم — ڈویلپر کی وضاحت کردہ ڈیٹا کے لیے 122 بِٹس | تجرباتی یا وینڈر مخصوص اسکیمز |
| Nil UUID | 00000000-0000-0000-0000-000000000000 |
خالی پلیس ہولڈر |
| Max UUID | FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF |
رینج اینڈ پوائنٹ مارکر |
نتیجہ
RFC 9562 نے جدید کلاؤڈ دور کے لیے منفرد شناخت کاروں کو اپ ڈیٹ کیا ہے۔ عملی رہنمائی:
- ڈیٹا بیس بنیادی کلیدیں → UUID v7 استعمال کریں، وقت کے مطابق ترتیب والی، ٹکڑے ٹکڑے نہ ہونے والی انسٹرشن کے لیے
- عمومی بے ترتیبی → UUID v4 اب بھی بالکل ٹھیک ہے
- ڈی ڈپلیکیشن → UUID v5 آپ کو حتمی IDs دیتا ہے
- اسٹوریج → ہمیشہ Binary(16) یا اصل UUID ٹائپس استعمال کریں، کبھی سٹرنگز نہیں
ایکشن آئٹم: اپنے ڈیٹا بیس سکیماز کی جانچ کریں۔ اگر آپ لاکھوں قطاروں والی ٹیبلز میں بنیادی کلید کے طور پر UUID v4 استعمال کر رہے ہیں، تو UUID v7 میں منتقلی ایک سادہ تبدیلی ہے جو انڈیکس ٹکڑے ٹکڑے ہونے کو نمایاں طور پر کم اور استفسارات کو تیز کر سکتی ہے۔
اکثر پوچھے جانے والے سوالات
کیا UUID وہی ہے جو GUID؟
کارکردگی کے لحاظ سے، ہاں۔ GUID UUID معیار کا مائیکروسافٹ کا نفاذ ہے۔ RFC 9562 کے تحت، ان کا رویہ یکساں ہے — آپ انہیں .NET، Java، اور Python ایپلی کیشنز کے درمیان باہمی استعمال کر سکتے ہیں۔
کیا حقیقی منظرنامے میں دو UUIDs کبھی ٹکرا سکتے ہیں؟
ریاضی کے لحاظ سے ممکن، عملاً ناممکن۔ UUID v4 کے لیے، آپ کو 50% تصادم کے امکان تک پہنچنے کے لیے تقریباً 2.71 کنٹلین IDs پیدا کرنے ہوں گے۔ Generate-Random.org کے مطابق، ایک سیکنڈ میں 1 بلین UUIDs 85 سال تک پیدا کرنے سے آپ کو صرف 50% موقع ملتا ہے کہ ایک واحد تصادم ہو۔
کیا میں ڈیٹا بیس میں UUIDs کو سٹرنگز یا بائنری کے طور پر اسٹور کروں؟
ہمیشہ Binary(16) یا اصل UUID ٹائپ (PostgreSQL میں دستیاب) کو ترجیح دیں۔ 36 حروف کی سٹرنگ دو گنا زیادہ جگہ استعمال کرتی ہے اور انڈیکس لک اپس اور جوائنز کو نمایاں طور پر سست کرتی ہے۔SnapUtils نوٹ کرتا ہے کہ RFC 9562 کے کارکردگی فوائد اس وقت زیادہ سے زیادہ ہوتے ہیں جب اسٹوریج متراصم رہے۔
میں UUID v4 کے بجائے UUID v5 کب استعمال کروں؟
جب آپ کو حتمی IDs درکار ہوں تو v5 استعمال کریں — ایک ہی ان پٹ ہمیشہ وہی UUID پیدا کرتا ہے، ڈیٹا بیس سے استفسار کے بغیر۔ جب آپ کو مکمل بے ترتیبی درکار ہو اور آپ یہ یقینی بنانا چاہیں کہ شناخت کار کو اس کے ماخذ تک ریورس انجینئر نہیں کیا جا سکے، تو v4 استعمال کریں۔
جواب دیں