使用git仓库作为数据库后端
我正在做一个处理结构化文档数据库的项目。我有一棵类别树（〜1000个类别，每个级别上多达〜50个类别），每个类别包含数千个（最多，例如〜10000个）结构化文档。每个文档都是某种结构化形式的几千字节的数据（我更喜欢YAML，但也可能是JSON或XML）。 该系统的用户执行几种类型的操作： 通过ID检索这些文档 通过文档中的某些结构化属性搜索文档 编辑文件（即添加/删除/重新命名/合并）；每个编辑操作都应记录为带有一些注释的事务 查看特定文档记录的更改的历史记录（包括查看更改文档的人员，时间和原因，获取较早的版本-如果需要，可以还原为该版本） 当然，传统解决方案将使用某种文档数据库（例如CouchDB或Mongo）来解决此问题-但是，此版本控制（历史记录）使我产生了一个疯狂的主意-为什么我不应该将git存储库用作此应用程序的数据库后端？ 乍一看，可以这样解决： 类别=目录，文档=文件 通过ID获取文档=>更改目录+读取工作副本中的文件 使用编辑注释编辑文档=>由不同的用户进行提交+存储提交消息 历史=>正常的git日志和旧事务的检索 search =>这是一个比较棘手的部分，我想这需要定期将类别导出到关系数据库中，并为列提供索引，以便我们通过 此解决方案还有其他常见陷阱吗？有没有人尝试过实现这样的后端（例如，对于任何流行的框架-RoR，node.js，Django，CakePHP）？该解决方案是否会对性能或可靠性产生任何潜在影响？即，是否证明git会比传统数据库解决方案慢得多，或者存在任何可伸缩性/可靠性陷阱？我认为，这种推/拉彼此的存储库的服务器集群应该相当健壮和可靠。 基本上，告诉我，如果这个解决方案将工作和为什么它会或不会做？