滥用Git实现事件存储体系结构？

Question

Git本质上是事件存储的实现，其中存储的数据是目录结构中的文件。众所周知，它能够可靠地解决以下问题：

• 存储变化的历史
• 向客户端传输最小的数据以获取最新的数据
• 可以回滚到以前的状态吗？

可以通过在Git上编写包装器来创建事件存储。

假设我的业务需要存储可以用JSON格式表示的客户数据。系统中的一个或多个服务可以修改数据。我可以拥有一个名为{customer}.json的平面结构和文件的专用Git客户数据。当服务修改数据时，它包含一条有用的提交消息。

此解决方案不会扩展(如果有太多更改频繁的客户，远程Git服务(例如GitHub )将受到请求和节流的轰炸)，但假设我知道我将有1,000个客户和数据每10小时1次更改，那么该解决方案还有其他问题吗？

Answer 1

使用Git作为数据库通常是个坏主意。对于此用例，它并不是特别优化的，因为它写入的数据比数据库事务通常所需的要多，通常希望签出整个树，而且如果将来需要缩放，则很难分割。它也不能在多主模式下进行复制和可伸缩性操作。

此外，如果您这样做，您的历史将以病态的方式增长，这使得打包和重新打包在CPU和内存方面非常昂贵，这是由于Git对对象进行分层的方式。此时，您的Git托管提供商将注意到并要求您迁移到其他地方，此时您将需要切换到真正的数据库。

Answer 2

Git本质上是事件存储的实现，其中存储的数据是目录结构中的文件。

某种程度上-- git存储库为您提供了带有happens-before关系的工作树的快照，这些关系允许您跟踪谱系。

就其本身而言，它并不是特别擅长于语义。如果您需要更多的上下文，请参见基于任务的用户界面的讨论，但是实际上，您需要“编写好的提交消息”来描述对快照表示所做的更改。

它也是分散的，通过设计--如果你想要的是资本的中央权威的话，这可能会很尴尬--T真相。使用分散的权限，您必然更依赖于回忆、猜测和道歉。这不一定是坏的，但如果你还没有为此做好预算的话，这可能是个令人讨厌的惊喜。

当对工作树中的单个文档负有明确的责任时，这可能会减轻一些压力--假设树的不同部分之间的变化之间的延迟是可以接受的。