GitLab के Postgres स्कीमा डिज़ाइन पर मेरे नोट्स (2022)

 (shekhargulati.com)
1 पॉइंट द्वारा GN⁺ 2024-02-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें

GitLab Postgres स्कीमा डिज़ाइन पर मेरे नोट्स

  • GitLab के Postgres स्कीमा को देखकर, अपनी डिज़ाइन की तुलना करना और GitLab की schema definitions से best practices सीखना।
  • GitLab एक ओपन-सोर्स DevOps प्लेटफ़ॉर्म है, GitHub का विकल्प और self-hosting के लिए उपलब्ध है।

सही Primary Key प्रकार का उपयोग

  • जब डेटाबेस छोटा होता है तब यह बड़ा मुद्दा नहीं लगता, लेकिन स्केल बढ़ने पर primary key storage space, write speed और read speed को प्रभावित कर सकता है।
  • GitLab के पास 573 tables हैं: इनमें से 380 tables में bigserial primary key type है, 170 में serial4, और बाकी 23 में composite primary key है।

Internal और External ID का उपयोग

  • अपनी internal primary key को बाहर expose न करना अच्छा practice है।
  • GitLab issues, ci_pipelines, deployments, epics जैसी tables में internal ID (id) और external ID (iid) दोनों का उपयोग करता है।

text data type और CHECK constraint का उपयोग

  • GitLab schema में character varying(n) और text दोनों हैं, लेकिन text का उपयोग ज्यादा है।
  • text में length limit नहीं होती, इसलिए लंबाई की सीमाएँ CHECK constraints से define की जाती हैं।

Naming conventions

  • सभी tables plural form में हैं और namespace देने के लिए module prefix use किया गया है।
  • table और column नाम snake_case format का पालन करते हैं।

Timestamp में time zone का उपयोग

  • GitLab दोनों उपयोग करता है: timestamp with timezone और timestamp without timezone।
  • सिस्टम operations के लिए timestamp without timezone और user actions के लिए timestamp with timezone use होते हैं।

Foreign key constraints

  • GitLab अधिकांश tables में foreign key constraints use करता है, लेकिन audit_events, abuse_reports, web_hooks_logs, spam_logs जैसी कुछ tables में नहीं।

बड़े tables की partitioning

  • GitLab query performance सुधारने के लिए बड़े हो सकने वाले tables को partition करता है।

Trigrams और gin_trgm_ops के साथ LIKE search use cases को support करना

  • GitLab efficient खोज के लिए GIN (Generalized Inverted Index) index का उपयोग करता है।

jsonb का उपयोग

  • GitLab schema कई tables में jsonb डेटा type का उपयोग करता है।

अन्य tips

  • बदलने योग्य tables में updated_at जैसी audit fields रखी जाती हैं, जबकि immutable log tables में नहीं।
  • Enums को character varying के बजाय smallint में store करके space बचाया जाता है।

GN⁺ की राय:

  • GitLab का स्कीमा डिज़ाइन DB design के लिए अच्छे insights देता है और बड़े पैमाने पर चलने वाले systems के लिए schema optimization पर महत्वपूर्ण lessons देता है।
  • GitLab ओपन-सोर्स होने की वजह से, ये schema design निर्णय अन्य developers के लिए practical examples बनते हैं जिन्हें अपने projects में apply किया जा सकता है।
  • GitLab schema से सीख मिलती है कि datatype चुनना, indexing strategy, partitioning और foreign key constraints का सही उपयोग जैसे decisions सीधे DB performance और maintainability को प्रभावित करते हैं।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-02-18
Hacker News टिप्पणियाँ

  • Primary key को बाहरी रूप से expose करना आमतौर पर अच्छी practice नहीं मानी जाती। खासकर जब integer या bigint जैसे क्रमिक auto-increment पहचानकर्ता उपयोग किए जाएँ, क्योंकि वे अनुमानित (guessable) हो सकते हैं।

    • primary key को public नहीं करने की यह सलाह सही मानी गई थी, खासकर sequentially बढ़ने वाली integer IDs के मामले में यह और भी महत्वपूर्ण है क्योंकि वे अनुमान लगाकर खोजी जा सकती हैं।

  • उदाहरण के लिए, 2020 में GitHub के पास 128 मिलियन सार्वजनिक repositories थीं। अगर हर repo में करीब 20 issues मानें, तो serial range पार हो जाएगा। साथ ही, किसी table का type बदलना काफी महँगा पड़ सकता है।

    • GitHub के सार्वजनिक repos और संभावित issues की संख्या के आधार पर यह दिखाया कि serial range ओवरफ्लो हो सकती है, और table type बदलने की लागत का मुद्दा भी उठाया गया।

  • UUID कॉलम के storage size को लेकर रखा गया तर्क मजबूत नहीं लगता। अगर table में पहले से 5 अन्य कॉलम हों, तो 128-bit और 64-bit में बड़ा फर्क नहीं दिखता।

    • लेख में कहा गया कि UUID कॉलम के आकार से ज्यादा performance महत्वपूर्ण है। UUIDv4 पूरी तरह random होता है, इसलिए index performance के लिए आदर्श नहीं; UUIDv7 शायद बेहतर विकल्प हो सकता है।

  • foreign key महँगी होती हैं—यह दलील बार-बार दोहराई जाती है लेकिन लगभग verify नहीं की गई। डेटाबेस का सही उपयोग करना बिना दोबारा build करने की तुलना में ज्यादा knowledge और experimentation मांगता है, और अक्सर बेहतर नतीजा देता है।

    • लेखक ने foreign key की लागत वाले आम दावे पर सवाल उठाया और ज़ोर दिया कि डेटाबेस को सही तरीके से इस्तेमाल करना अहम है।

  • क्या किसी ने GitLab और GitHub के बीच performance gap पर कुछ लिखा या नोटिस किया है?

    • GitLab और GitHub के performance अंतर में रुचि जताते हुए उन्होंने कहा कि GitLab के पेज कई बार GitHub की तुलना में noticeably धीमे लगते हैं।

  • मुझे CI variables CI_PIPELINE_IID और CI_MERGE_REQUEST_IID में अतिरिक्त I क्यों जोड़ा गया, यह समझ नहीं आ रहा था। अनुमान था कि शायद यह database-related चुनाव हो, यह पोस्ट इसे clear कर देता है।

    • CI_PIPELINE_IID और CI_MERGE_REQUEST_IID में अतिरिक्त "I" क्यों जोड़ा गया, इस पर जिज्ञासा जताई गई और यह समझ आया कि यह शायद database design से जुड़ा फैसला था, जिसकी पुष्टि लेख में मिलती है।

  • यह पोस्ट बहुत useful था। कोई similar पोस्ट और कहीं मिल सकती है?

    • लेखक ने बताया कि लेख बेहद मददगार था और इसी तरह की अन्य सामग्री खोजने की इच्छा जताई।

  • क्या सिर्फ मुझे ही लगता है कि schema design और development तकनीकी तौर पर पीछे छूट चुके हैं?

    • यह चिंता व्यक्त की गई कि schema design और development शायद outdated हो गए हैं, खासकर migration के समय data loss का जोखिम दिखता है। साथ ही यह सवाल भी कि database/ORM क्यों external ID और internal ID को auto-handle नहीं करते।

  • 1경 यानी 1000000000 ट्रिलियन के बराबर होता है।

    • 32-bit और 64-bit integers के बीच व्यावहारिक चयन की बात करते हुए लगभग 1 ट्रिलियन-cardinality संभालने के लिए 5-byte integer type की जरूरत पर चर्चा की गई।

  • Postgres के native UUID v4 type पर table size करीब 25% बढ़ जाता है, और insert speed bigserial की तुलना में करीब 25% कम हो जाती है।

    • UUIDv4 और bigserial के बीच performance gap पर सवाल उठाया गया और पूछा गया कि UUIDv4 क्यों worse performance दिखाता है।