Package managers keep using Git as a database, it never works out
5 months ago
- #package-managers
- #scalability
- #git
- 使用Git作为数据库很诱人，因为它提供免费的版本历史记录、通过拉取请求的审查流程以及分布式设计，但在大规模使用时往往表现不佳。
- 诸如Cargo、Homebrew、CocoaPods、Nixpkgs、vcpkg和Go模块等包管理器最初使用Git，但遇到性能问题后转向基于HTTP的协议或CDN等替代方案。
- Cargo改用稀疏HTTP协议以避免克隆整个索引，显著提升了用户性能。
- 由于GitHub因高成本和性能低下要求停止使用浅克隆，Homebrew转向JSON下载来更新tap。
- CocoaPods放弃Git改用CDN，减少了磁盘占用并加快了操作速度。
- Nixpkgs因其庞大的规模和频繁的CI查询而难以适应GitHub的基础设施，但无法轻松迁移出Git。
- vcpkg依赖Git树哈希进行版本控制，使得浅克隆存在问题，且没有简单的基于HTTP的解决方案。
- Go模块通过使用模块代理而非克隆仓库，将依赖解析速度从18分钟提升至12秒。
- 基于Git的Wiki和CMS平台面临可扩展性问题，导致性能低下和速率限制。
- Git继承了文件系统的限制，使其成为糟糕的数据库替代品，包括目录限制、大小写敏感问题、路径长度限制以及缺乏约束和索引等数据库功能。
- 这一模式表明，尽管Git在源代码的分布式协作方面表现出色，但不适合用作数据库或包注册表，最终必然迁移到更合适的解决方案。