- UUID v4 में बहुत अधिक randomness होती है, जिससे index inefficiency और excessive I/O होता है, और PostgreSQL में इसे primary key के रूप में इस्तेमाल करने पर performance गिरती है
- random inserts की वजह से page split और index fragmentation बार-बार होते हैं, साथ ही WAL log size बढ़ती है और write latency आती है
- UUID का आकार 16 bytes होता है, जो bigint से दोगुनी जगह लेता है, और इससे cache hit ratio घटता है तथा memory waste होता है
- इसे अक्सर security identifier समझ लिया जाता है, लेकिन RFC 4122 के अनुसार UUID, guess रोकने के लिए security mechanism नहीं है
- नए database में integer sequence-based key इस्तेमाल करने की सलाह दी जाती है, और अगर UUID ज़रूरी हो तो time-ordered UUID v7 बेहतर है
UUID v4 की performance समस्या
- PostgreSQL में UUID v4 primary key इस्तेमाल करने वाले database पिछले 10 सालों से लगातार performance degradation और excessive I/O दिखाते रहे हैं
- UUID v4 के 122 bits random होते हैं, इसलिए index ordering संभव नहीं होती
- insert के समय data sequential pages में store नहीं होता, जिससे random access होता है, और update/delete के समय भी inefficient lookup की ज़रूरत पड़ती है
- B-Tree index sorted data को ध्यान में रखकर बनाया गया है, लेकिन UUID v4 में ordering नहीं होती, इसलिए insert efficiency कम रहती है
- हर insert किसी भी arbitrary page पर लिखा जाता है, इसलिए mid-page split बार-बार होता है
- इससे write latency और WAL growth होती है
UUID की structure और alternatives
- UUID, 128-bit (16-byte) identifier होता है, और PostgreSQL में binary uuid type के रूप में store किया जाता है
- UUID v4 random bits पर आधारित है, जबकि UUID v7 अपने शुरुआती 48 bits में timestamp शामिल करता है, जिससे index efficiency बेहतर होती है
- PostgreSQL 18 (2025 के लिए निर्धारित) में UUID v7 का built-in support आने वाला है
- UUID v7 time-ordered sorting को संभव बनाता है, जिससे page density और cache efficiency बेहतर होती है
UUID चुनने के कारण और सीमाएँ
- multi-client या microservices environment में, जब collision-free identifier generation की ज़रूरत हो, तब UUID इस्तेमाल किया जाता है
- उदाहरण: कई database instances में एक साथ ID generate करना
- लेकिन RFC 4122 साफ़ कहता है: “UUID को unguessable मानकर न चलें”, इसलिए यह security identifier के लिए उपयुक्त नहीं है
- collision probability 2.71×10¹⁸ IDs generate होने पर 50% तक पहुँचती है; व्यवहार में collision दुर्लभ है, लेकिन performance cost बहुत ज़्यादा है
UUID की space और I/O inefficiency
- UUID, bigint (8 bytes) से दोगुनी और int (4 bytes) से चार गुना जगह लेता है
- बड़े tables में इससे storage space बढ़ती है और backup/restore समय भी बढ़ता है
- index page density प्रयोग के नतीजे
- integer index: 97.64%
- UUID v4 index: 79.06%
- UUID v7 index: 90.09%
- Cybertec test में UUID v4 index lookup के दौरान 8.5 million अतिरिक्त page accesses और 31229% I/O increase देखा गया
- समान conditions में bigint index ने 27,332 buffer accesses किए, जबकि UUID v4 ने 8,562,960 buffer accesses किए
cache और memory पर प्रभाव
- UUID की random distribution की वजह से buffer cache hit ratio कम रहता है
- cache में ज़्यादा pages load करने पड़ते हैं, और ज़रूरी pages अक्सर evict हो जाते हैं
- cache efficiency घटने से query latency बढ़ती है और memory usage भी बढ़ता है
- performance बनाए रखने के लिए regular index rebuild (
REINDEX CONCURRENTLY) या pg_repack इस्तेमाल करने की सलाह दी जाती है
performance कम करने के उपाय
- memory बढ़ाना: database size के 4 गुना RAM की सिफारिश (उदाहरण: DB 25GB → memory 128GB)
- work_mem tuning: sorting operations के लिए ज़्यादा memory allocate करके performance सुधारी जा सकती है
- Rails environment में
implicit_order_column सेट करके UUID की जगह created_at जैसे sortable field का उपयोग किया जा सकता है
- CLUSTER command से sortable field के आधार पर table को फिर से arrange किया जा सकता है, लेकिन इसके लिए exclusive lock चाहिए
integer key और sequence की सिफारिश
- नए database में integer sequence-based key इस्तेमाल करने की सलाह दी जाती है
integer (4 bytes) लगभग 2 अरब values देता है, जबकि bigint (8 bytes) उससे कहीं अधिक unique values देता है
- ज़्यादातर business apps के लिए integer काफ़ी है, जबकि बड़े scale की services में bigint अधिक उपयुक्त है
- UUID v4 की जगह UUID v7 या sequential_uuids extension इस्तेमाल करना एक व्यावहारिक विकल्प है
सारांश
- UUID v4 अपनी randomness की वजह से index inefficiency, high I/O, और poor cache efficiency पैदा करता है
- इसे security identifier के रूप में इस्तेमाल नहीं किया जा सकता, और इसमें space waste भी बहुत है
- integer sequence key ज़्यादातर applications के लिए बेहतर विकल्प है
- अगर UUID इस्तेमाल करना अनिवार्य हो, तो time-ordered UUID v7 चुनना चाहिए
- PostgreSQL में gen_random_uuid() को primary key के रूप में इस्तेमाल करने से बचना चाहिए
अभी कोई टिप्पणी नहीं है.