PostgreSQL और UUID को primary key के रूप में उपयोग करने के बारे में

• UUID का उपयोग अक्सर database table की primary key के रूप में किया जाता है
  • इन्हें बनाना आसान है, distributed systems के बीच साझा करना आसान है, और uniqueness की गारंटी मिलती है
  • UUID के आकार को देखते हुए यह सही विकल्प है या नहीं, इस पर सवाल उठ सकता है, लेकिन कई बार हमारे पास निर्णय लेने का विकल्प नहीं होता
• यह लेख "क्या UUID key के लिए उपयुक्त format है" पर नहीं, बल्कि PostgreSQL में UUID को primary key के रूप में कुशलतापूर्वक उपयोग करने के तरीकों पर केंद्रित है

PostgreSQL और UUID को primary key के रूप में उपयोग करना

• UUID क्या है?
  • UUID का उपयोग अक्सर database table की primary key के रूप में किया जाता है
  • इन्हें distributed systems के बीच आसानी से साझा किया जा सकता है और ये uniqueness सुनिश्चित करते हैं
  • UUID के आकार के कारण इसकी उपयुक्तता पर सवाल उठ सकते हैं, लेकिन कई बार कोई दूसरा विकल्प नहीं होता

PostgreSQL में UUID data type

• UUID को string के रूप में store करना

  • PostgreSQL, string store करने के लिए text data type प्रदान करता है
  • लेकिन text type, UUID store करने के लिए उपयुक्त नहीं है
  • PostgreSQL, UUID के लिए dedicated uuid data type प्रदान करता है
  • uuid type एक 128-bit data type है, और एक value store करने के लिए 16 bytes की जरूरत होती है
  • text type में 1 या 4 bytes का अतिरिक्त overhead जुड़ता है

• प्रयोग के परिणाम

  • तुलना के लिए दो tables बनाए गए: एक text type के साथ, दूसरा uuid type के साथ
  • 10,000,000 rows insert करने के बाद table size और index size की तुलना की गई
  • text type उपयोग करने वाली table 54% बड़ी थी, और उसका index size 85% बड़ा था

UUID और B-Tree index

• B-Tree index और UUID

  • random UUID, B-Tree index के लिए उपयुक्त नहीं है
  • B-Tree index ordered values के साथ बेहतर काम करता है
  • Java का UUID.randomUUID() UUID v4 लौटाता है, जो pseudo-random value होती है
  • UUID v7 समय-क्रम में sort होने वाली values बनाता है, इसलिए यह B-Tree index के लिए अधिक उपयुक्त है

• UUID v7 का उपयोग

  • Java में UUID v7 उपयोग करने के लिए java-uuid-generator library की जरूरत होती है
  • UUID v7 generate करने से insert performance बेहतर हो सकती है

UUID v7 का INSERT performance पर प्रभाव

• प्रयोग
  • UUID v7 उपयोग करने वाली table बनाई गई, और 10,000 rows को 10 बार insert करके performance मापी गई
  • परिणाम कुछ हद तक random थे, लेकिन UUID v7 insert करना लगभग 2 गुना तेज था

अतिरिक्त पढ़ने योग्य सामग्री

• PostgreSQL 17 में UUID v7 के native support की संभावना है
• UUID v7 format के बारे में जानकारी
• database primary key के रूप में UUID के performance पर प्रभाव

सारांश

• UUID की लंबाई की समस्या

  • optimization के बाद भी UUID, primary key के रूप में आदर्श type नहीं है
  • अगर विकल्प मौजूद हो, तो TSID जैसे दूसरे विकल्पों पर विचार करें

• optimization की आवश्यकता

  • अगर बड़े dataset या high traffic की उम्मीद है, तो optimization पर विचार करना चाहिए
  • primary key बदलना कठिन काम है, इसलिए शुरुआत से सही सेट करना महत्वपूर्ण है

• ध्यान देने योग्य बातें

  • लेखक PostgreSQL विशेषज्ञ नहीं हैं; वे केवल सीखी हुई बातों को साझा कर रहे हैं
  • यदि यह उपयोगी लगा हो, तो comment या Twitter के जरिए feedback देने का अनुरोध है

GN⁺ की संक्षिप्त प्रस्तुति

• यह लेख PostgreSQL में UUID को primary key के रूप में उपयोग करते समय कुशल तरीकों पर चर्चा करता है
• प्रयोगों के जरिए दिखाया गया है कि UUID v7 उपयोग करने से insert performance बेहतर हो सकती है
• बड़े dataset या high traffic की स्थिति में optimization आवश्यक हो सकता है
• TSID जैसे अन्य विकल्पों पर भी विचार किया जा सकता है

[savvykang]

क्या UUID के लिए standard format (hexadecimal + hyphen) की बजाय base62 encoding की उम्मीद करना ज़्यादा मांग होगी?

[qurare]

uuidv7 अजेय है
uuidv8+ तो "भगवान" है

[bbulbum]

सबसे बड़ी बाधा यह है कि यह इंसानों के लिए सहज नहीं है.. मुझे अभी भी कई मामलों में यह हिस्सा ज़रूरी लगता है..

[GN⁺]

Hacker News राय

• B-tree के अनुकूल primary key के लिए bigserial इस्तेमाल करने और बाहरी record locator विकल्प के रूप में string-encoded UUID पर विचार करने की सिफारिश की गई है

  • अगर non-technical उपयोगकर्ता इसका हवाला देंगे, तो पहले PNR-style locator जैसे सरल विकल्पों पर विचार करें
  • किसी service या application के schema के भीतर PK प्रकारों को mix न करें
  • unique identifier के रूप में UUIDv7 का उपयोग तभी करें जब डेटा में timecode अंतर्निहित हो
  • hashids का उपयोग न करें; इसमें cryptographic quality नहीं है और यह आम लोगों के लिए परिचित भी नहीं है
  • encoding करते समय base64 या hyphen वाले alphabet का उपयोग न करें

• database schema design करते समय separation of concerns और mechanical sympathy के सिद्धांतों को ध्यान में रखें

• Stripe के typed random ID वास्तव में random नहीं हैं

  • इनमें metadata, embedded timestamp, shard और reference key, version information आदि शामिल होते हैं
  • व्यक्तिगत रूप से base58-encoded AES-encrypted bigserial+HMAC locator को प्राथमिकता दी जाती है

• Postgres में random UUID कोई बड़ी समस्या नहीं है

  • UUID (16 bytes) serial (4 bytes) या bigserial (8 bytes) से बड़ा है, लेकिन पूरे table स्तर पर यह कोई बड़ी समस्या नहीं है

• Postgres में serial vs. random UUID vs. ordered UUID पर विचार करने से पहले और भी कई चीज़ों की चिंता करनी चाहिए

• हाल ही में Postgres PK के रूप में ULID चुना गया, और इस लेख से काफ़ी मदद मिली: https://brandur.org/nanoglyphs/026-ids

• ULID को पसंद करने का कारण यह है कि यह UUID type के साथ compatible है, और इसमें built-in timestamp होता है, इसलिए ID के आधार पर sort करने पर यह timestamp क्रम में sort होता है

• अगर तुलना में int64 भी शामिल हो, तो UUID और पारंपरिक approach के overhead की तुलना करना अच्छा होगा

• insertion performance, performance का मूल्यांकन करने का एक खराब तरीका है

  • insertion के समय B-Tree performance बेहतर होती है, लेकिन बड़े पैमाने के transaction में यह कैसी होगी, यह सवाल है

• SQLite में UUID4 को इसलिए प्राथमिकता दी जाती है क्योंकि transaction lock के दौरान page cache conflict की संभावना कम होती है

  • Postgres systems में भी यह इसी तरह लागू हो सकता है

• integer auto-increment primary key को प्राथमिकता दी जाती है

  • इसे समझना आसान है और sort करना सरल है
  • बड़े batch projects में आख़िरी primary key को store करके उससे बड़े सभी मानों को fetch किया जा सकता है

• UUIDv7 insertion time benchmark में UUID generation time शामिल है

  • बस index update cost को अलग करके देखना चाहेंगे

• PostgreSQL 17 में UUIDv7 support शामिल होने की संभावना कम है

  • हाल के काम में committer को हटा दिया गया, और version 17 पहले से ही feature freeze में है

• python-ulid का उपयोग शुरू किया है, और ULID, UUID से बेहतर है

• UUID v7 standard link पुराना हो चुका है, इसलिए RFC 9562 देखें: https://datatracker.ietf.org/doc/html/rfc9562