UUID Generator

यह किसके लिए है?

एक UUID (या GUID) एक 128-bit पहचानकर्ता है — 5 समूहों में 32 hex digits के रूप में लिखा जाता है, जैसे 550e8400-e29b-41d4-a716-446655440000। ये बिना समन्वय के systems में टकराव-मुक्त हैं: कहीं भी कोई भी process एक generate कर सकती है और दो के कभी टकराने की संभावना व्यावहारिक रूप से शून्य है। उपयोगी जब आपको database से बात करने से पहले एक ID की आवश्यकता हो, जब आप row counts के leak होने से बचना चाहें, या जब एक ID client-side पर generate करनी हो और बाद में sync करनी हो। यह टूल RFC 4122 / RFC 9562 के अनुरूप UUIDs v4 (random) या v7 (time-ordered) रूप में, आपके browser में क्रिप्टोग्राफिकली-सुरक्षित यादृच्छिकता से उत्पन्न करता है।

कब इस्तेमाल करें

• वितरित systems के लिए primary keys जहां आप एक ID के लिए database में round-trip नहीं करना चाहते।
• API requests के लिए idempotency keys (stripe, payment providers, queue messages)।
• File-upload identifiers, session tokens, logs में correlation IDs।
• कहीं भी जहां आप अन्यथा एक auto-incrementing ID expose करते और leak करते कि आपके पास कितने records हैं।
• Test डेटा — एक click में सौ records को यथार्थवादी identifiers के साथ seed करें।

v4 बनाम v7 — कौन सा उपयोग करूं?

• v4 (random) — 122 bits यादृच्छिकता, कोई embedded creation समय नहीं। तब उपयोग करें जब आप IDs और creation order के बीच शून्य correlation चाहते हैं, या जब ID एक hash-map / non-clustered index में रहेगा जहां ordering मायने नहीं रखती।
• v7 (time-ordered) — 48-bit Unix-ms timestamp prefix + random tail। नए database primary keys के लिए इसे default करें। Timestamp prefix B-tree indexes को locality देता है (हाल के inserts एक ही pages पर जाते हैं, v4 की तुलना में बहुत बेहतर cache व्यवहार), और IDs मोटे तौर पर कालानुक्रमिक क्रम में sort होते हैं। RFC 9562 (May 2024) में परिभाषित — अधिकांश use cases के लिए ULID और v1/v6 का स्थान लेता है।

आम गलतियाँ

• UUIDs रहस्य नहीं हैं। v4 में 122 bits entropy है और यह अप्रत्याशित है, लेकिन format स्वयं कुछ भी authorize नहीं करता। एक UUID को session token या password-reset token के रूप में उपयोग न करें जब तक आप इसे एक रहस्य की तरह नहीं मानते (HTTPS-only, time-limited, single-use)।
• v7 creation समय leak करता है। पहले 48 bits उस millisecond को encode करते हैं जब इसे बनाया गया था। आंतरिक IDs के लिए ठीक है; खराब यदि आप नहीं चाहते कि उपयोगकर्ता जानें कि records कब बनाए गए थे। उस स्थिति में v4 का उपयोग करें।
• Index आकार मायने रखता है। एक UUID 16 bytes है बनाम bigint के लिए 8 — आपके B-tree indexes बड़े हो जाते हैं। वितरित/बिना-समन्वय के लिए सार्थक है, अक्सर एक sequential ID वाले single-server apps के लिए सार्थक नहीं है।
• v4 database indexes को fragment करता है। Random IDs writes को index में फैलाते हैं, page cache hit rate और write throughput को नुकसान पहुंचाते हैं। यह v7 के लिए मूल तर्क है।
• v1 का उपयोग न करें। पुराना time-and-MAC variant generating machine का MAC पता leak करता है। v7 आधुनिक प्रतिस्थापन है।
• क्रिप्टो-सुरक्षित यादृच्छिकता का उपयोग करें। यह टूल crypto.getRandomValues का उपयोग करता है; कभी भी Math.random के साथ अपना खुद का न बनाएं — यह पर्याप्त रूप से random नहीं है और IDs पूर्वानुमेय हो जाते हैं।