重新生成查询数据库答案

【问题标题】：Regenerating Querying Database重新生成查询数据库
【发布时间】：2012-05-04 14:27:27
【问题描述】：

我拥有的网站有一个运行良好的简单 CQRS 架构。一个事件被不同的订阅者发布和接收，其中一个使报告数据库保持同步 [在 RavenDb 中]。

例如，我的报告数据库已损坏/丢失。使用事件溯源，我可以重播事件并重建报告数据库，但是我 [当前] 不使用事件溯源；我有一个简单的 nHibernate 持久化到关系存储。解决方案是创建一个“重新生成”类型的脚本，该脚本基本上将基于关系存储发送所有事件（例如，PersonCreatedEvent 后跟 30xPersonLikedBlogPostEvent 等）？它本质上与事件源所做的事情相同，但事件是从关系模型中推断出来的。

这里有点被难住了，因为可维护性和 DR 显然很重要。

【问题讨论】：

标签： architecture cqrs maintainability event-sourcing

【解决方案1】：

如果您不存储事件，则无法进行再生。如果您使用关系存储仅生成“已创建”事件，您将无法从这种“重新生成”中获得任何好处。

【讨论】：

谢谢，我不太关心从对象历史的真实表示等中重新生成的好处，但是拥有 RavenDb 报告数据库对于站点的性能 SLA 很重要。但是，我正在转向事件采购。问候

【解决方案2】：

如果您存储了发送到服务器的所有命令（例如，在日志中），您可以从第一个命令到最后一个命令将所有命令发送到总线，并且您可以重现所有查询端。那就是命令采购。借助命令溯源，您可以随时轻松地进行事件溯源。

【讨论】：

【解决方案3】：

您无需实施成熟的事件溯源解决方案即可实现这一目标。如果您只是将所有事件存储在事件日志中，则可以根据需要检索和重放它们。

【讨论】：

【解决方案4】：

我认为没有简单/快速的解决方案。如果您将数据从关系源迁移到事件源，这实际上是您需要做的。正如您所说，您唯一能做的就是为每个实体脚本以合理的顺序编写事件（即 CreatedEvent 然后是您的其他状态更改事件）。但是当您捕获这些事件时，我会将它们存储起来，以便您以后可以重新运行它们。

【讨论】：