Hacker News 中文摘要

RSS订阅

包管理器持续将Git当作数据库使用，结果总不尽人意 -- Package managers keep using Git as a database, it never works out

原文链接 | HN讨论 | 2025-12-26 23:03:45

文章摘要

将Git用作数据库看似诱人，能免费获得版本历史、评审流程和分布式特性，但实际效果不佳。Cargo和Homebrew都曾尝试使用Git存储索引，但随着数据增长，克隆和更新变得低效。Cargo后来改用稀疏HTTP协议按需获取元数据，大幅提升了效率，而Homebrew则因GitHub要求停止使用浅克隆。这些案例表明Git并不适合作为大规模数据库使用。

文章总结

将Git作为数据库的诱惑与困境

Git作为数据库的想法颇具吸引力——它自带版本历史记录、通过Pull Request提供审核流程、天生分布式，还能免费托管在GitHub上。然而多个包管理器的实践表明，这种方案最终都会遇到瓶颈。

典型案例分析：

  1. Cargo的演进
  • 初期采用Git仓库作为索引，随着规模增长出现性能问题
  • CI环境中全量克隆/丢弃的模式造成巨大浪费
  • 最终通过RFC 2789引入稀疏HTTP协议，实现按需查询
  • 目前99%请求已转向新协议，但Git索引仍以每日数千提交的速度增长
  1. Homebrew的转变
  • 因GitHub明确要求停止使用浅克隆
  • 更新操作消耗大量资源，.git目录可达1GB
  • 2023年转向JSON下载方案，更新频率从5分钟延长至24小时
  1. CocoaPods的突破
  • Specs仓库达到数十万podspecs的规模
  • 克隆/更新操作耗时数分钟，CI效率低下
  • 1.8版本彻底放弃Git，改用CDN直接提供文件
  1. Nixpkgs的挑战
  • 83GB仓库包含50万个树对象和2万个分叉
  • GitHub基础设施面临压力，曾出现只读风险
  • 由于特殊架构难以迁移到CDN方案
  1. vcpkg的困境
  • 依赖Git树哈希实现版本控制
  • 浅克隆导致版本解析失败
  • 目前仍深度绑定Git，缺乏替代方案
  1. Go模块的革新
  • 从18分钟优化到12秒的典型案例
  • 通过模块代理和校验和数据库解决安全问题
  • 彻底摆脱对版本控制工具的依赖

深层问题剖析：

  1. 文件系统限制
  • 目录文件数限制（如CocoaPods的16,000文件目录）
  • 大小写敏感性问题
  • Windows路径长度限制（260字符）
  1. 数据库功能缺失
  • 缺乏约束检查
  • 无锁机制
  • 缺少索引功能
  • 无结构化迁移方案

演进规律： 从简单目录→遭遇文件系统限制→实现分片→出现跨平台问题→构建服务端验证→最终转向HTTP/真实数据库

核心结论： Git在代码协作方面表现出色，但不适合作为包元数据存储方案。各包管理器的实践表明，最终都需要转向专用解决方案。新系统设计者应引以为鉴，避免重蹈覆辙。

评论总结

以下是评论内容的总结，按主要观点分类呈现：

【Git作为包管理工具的优缺点】 支持观点： - Git的数据模型具有独特优势（评论2："Like the network databases of old, but embedded in a Merkle tree"） - 是初创项目的理想选择（评论10："fantastic choice for starting your package manager"） - 免费托管平台降低了使用门槛（评论15："GitHub has been hosting infra for free"）

反对观点： - 存在规模限制（评论2："fundamental limits to scaling"） - 效率问题突出（评论6："from 18 minutes to 12 seconds"；评论11："O(1) beats O(n)"） - 依赖特定平台（评论14："centered around GitHub a lot"）

【替代方案讨论】 - SQL类方案（评论9："using anything other than a database"；评论13："sqlite seems ideal"） - 混合方案（评论18："rsync + server-generated index"） - 条件逻辑方案（评论21："Conan's solution is...pragmatic"）

【规模与效率的权衡】 - 早期简单方案具有合理性（评论22："if you're not sure whether your project will ever need to scale"） - 成功项目往往从简单开始（评论23："humble origins, it's a feature"） - 用户时间成本常被忽视（评论7："user time...externality"）

【具体问题案例】 - Go模块的证书问题（评论3："Go module will not accept package"） - 自动更新频率争议（评论20："such an insane default"） - 命名冲突问题（评论17："RFC was already taken"）

关键引用保留： 1. 关于Git优势： "Git is a fantastic choice of database for starting..."（评论10） "GitHub has been hosting infra for free..."（评论15）

  1. 关于效率问题： "from 18 minutes to 12 seconds"（评论6） "O(1) beats O(n)"（评论11）

  2. 关于替代方案： "sqlite seems to be ideal"（评论13） "rsync the complete port definitions..."（评论18）