Git को डेटाबेस की तरह इस्तेमाल करने वाले पैकेज मैनेजर आखिरकार असफल होते हैं

 (nesbitt.io)
7 पॉइंट द्वारा GN⁺ 2025-12-27 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • कई package managers ने version control और collaboration की सुविधा के कारण Git को डेटाबेस की तरह इस्तेमाल किया, लेकिन scale बढ़ने पर performance और maintenance की समस्याओं से टकराए
  • Cargo, Homebrew, CocoaPods आदि ने Git index के आकार में वृद्धि, धीमे update, और CI environments की अक्षमता के कारण आखिरकार HTTP-आधारित index या CDN अपनाए
  • vcpkg अब भी Git tree hash पर आधारित है, और shallow clone environment में build failures और जटिल workaround पैदा होते हैं
  • Go module system ने GOPROXY और checksum database (sumdb) अपनाकर Git dependency हटाई और security व speed बेहतर की
  • Git code collaboration के लिए बेहतरीन है, लेकिन package metadata queries या बड़े registry management के लिए उपयुक्त नहीं है — यह बात बार-बार सामने आई है

Git को डेटाबेस की तरह इस्तेमाल करने की बार-बार असफल कोशिश

  • Git के version history, distributed structure, और free hosting जैसे फायदे इसे आकर्षक बनाते हैं, लेकिन डेटाबेस की तरह इस्तेमाल करने पर यह scalability limits से टकराता है
  • कई package managers ने Git को index के रूप में अपनाया, लेकिन समय के साथ performance degradation और infrastructure burden बढ़ता गया

Cargo

  • crates.io index की शुरुआत Git repository के रूप में हुई थी, और सभी clients पूरा clone करते थे
    • repository के बड़ा होने पर delta resolution चरण में libgit2 का performance bottleneck सामने आया
    • CI environments में हर build पर पूरा index डाउनलोड होता था, जिससे भारी बर्बादी होती थी
  • RFC 2789 के जरिए sparse HTTP protocol लाया गया, ताकि केवल जरूरी metadata ही HTTPS से लिया जाए
    • अप्रैल 2025 तक 99% requests sparse mode का इस्तेमाल कर रही थीं
    • Git index अब भी मौजूद है, लेकिन ज्यादातर users उसे access नहीं करते

Homebrew

  • GitHub ने Homebrew से shallow clone का उपयोग बंद करने को कहा, और update को “बेहद महंगा operation” बताया
    • homebrew-core का .git folder लगभग 1GB तक पहुंच गया, और update के समय delta resolution से देरी होती थी
  • फ़रवरी 2023 में Homebrew 4.0.0 ने tap updates को JSON download model में बदल दिया
    • Git fetch हटने से update speed बढ़ी, और auto-update cycle भी 5 मिनट से 24 घंटे कर दी गई

CocoaPods

  • iOS/macOS के package manager CocoaPods का Specs repository, जिसमें लाखों podspecs थे, बहुत बड़ा हो गया
    • clone और update में कई मिनट लगते थे, और CI time का बड़ा हिस्सा Git operations में खर्च होता था
  • GitHub ने CPU rate limit लगाया, और shallow clone को server load का कारण बताया
  • टीम ने automatic fetch बंद करना, full clone पर जाना, repository sharding जैसी अस्थायी कार्रवाइयाँ कीं
  • version 1.8 से CDN-आधारित HTTP distribution अपनाया गया, जिससे users का लगभग 1GB disk space बचा और install speed काफी बेहतर हुई

Nixpkgs

  • Nix client side पर पहले से ही tarball-based channels इस्तेमाल करता है, ताकि Git clone से बचा जा सके
    • package expressions को S3 और CDN से HTTP पर serve किया जाता है
  • लेकिन GitHub की infrastructure पर 83GB repository और 20,000 forks का बोझ पड़ा
    • नवंबर 2025 में GitHub ने replica consensus failures और maintenance task errors की रिपोर्ट दी
    • local clone 2.5GB का है, लेकिन पूरा fork network GitHub storage पर दबाव डालता है

vcpkg

  • Microsoft का C++ package manager vcpkg Git tree hash से versioning करता है
    • builtin-baseline के जरिए किसी खास commit point के ports दोहराने के लिए पूरा history चाहिए
  • shallow clone environments (GitHub Actions, DevContainers) में build failures होते हैं
    • समाधान के रूप में fetch-depth: 0 सेट करना पड़ता है, यानी पूरा history डाउनलोड करना पड़ता है
  • Git tree hash structure के कारण commit tracking संभव नहीं, और यह structural limitation आसानी से सुधारी नहीं जा सकती
  • अब भी केवल Git repository-based registry ही supported है, HTTP या CDN alternative नहीं है

Go module system

  • Grab engineering team ने module proxy अपनाने के बाद go get समय 18 मिनट → 12 सेकंड कर दिया
  • पुराने तरीके में हर dependency का पूरा repository clone करना पड़ता था, ताकि go.mod पढ़ा जा सके
  • Go team को VCS tool dependencies और security vulnerabilities की चिंता थी
  • Go 1.13 से GOPROXY default बना, जो module source और go.mod को HTTP पर serve करता है
    • sumdb (checksum database) module integrity और persistence सुनिश्चित करता है

Git को डेटाबेस की तरह इस्तेमाल करने पर आम समस्याएँ

  • Git-based wiki (Gollum) में बड़े repositories पर directory browsing और page loading धीमे हो जाते हैं
    • GitLab, Gollum का उपयोग बंद करने की योजना बना रहा है
  • Git-based CMS (Decap), GitHub API request limit (5,000) से टकराता है
    • लगभग 10,000 से अधिक items पर performance गिरती है, और empty cache वाले नए users request storm पैदा करते हैं
  • GitOps tool (ArgoCD) में repository clone के समय disk space limit पार हो जाती है
    • एक ही commit पूरा cache invalid कर सकता है, और बड़े monorepo के लिए अलग scaling चाहिए

Git डेटाबेस के रूप में संरचनात्मक रूप से क्यों अनुपयुक्त है

  • directory limit: files की संख्या बढ़ने पर performance गिरती है
    • CocoaPods में 16,000 directories के कारण बहुत बड़े tree objects बने, जिन्हें hash-based sharding से संभाला गया
  • case sensitivity issue: Git case-sensitive है, लेकिन macOS और Windows नहीं
    • Azure DevOps ने conflicts रोकने के लिए server-side blocking feature जोड़ा
  • path length limit: Windows की 260-character limit से git status errors आते हैं
  • database features की कमी:
    • CHECK/UNIQUE constraints, locking, indexing, migration — कुछ भी मौजूद नहीं
    • हर package manager को अपना validation और indexing system खुद बनाना पड़ता है

निष्कर्ष

  • Git source code collaboration के लिए बेहतरीन है, लेकिन package metadata queries या बड़े registry management के लिए उपयुक्त नहीं
  • ज्यादातर package managers आखिरकार HTTP-आधारित index या database की ओर चले गए
  • Git के फायदे — version history और PR workflow — आकर्षक हैं, लेकिन database replacement के रूप में यह असफल रहा
  • नया package manager design करते समय Git index आकर्षक लग सकता है, लेकिन Cargo·Homebrew·CocoaPods·vcpkg·Go के उदाहरणों की तरह वही सीमाएँ अंततः सामने आती हैं

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.