所以我现在正在使用CQRS架构以及EventStore“模式”。
它将应用程序打开到可扩展性和灵活性以及测试的新维度。
但是我仍然坚持如何正确处理数据迁移。
这是一个具体的用例：
假设我想管理一篇包含文章和评论的博客。
在写入方面，我正在使用MySQL，并且在读取端ElasticSearch，现在每次处理命令时，我都会在写入端保留数据，调度事件以在读取端保留数据
现在让我说我有一种名为ArticleSummary的ViewModel，它包含一个id和一个标题。
我有一个新的功能请求，要将文章标签添加到我的ArticleSummary，我会在模型中添加一些字典以包含标签。
鉴于我的写入层中已存在标记，我需要更新或使用新的“表格”来正确使用新包含的数据。
我知道EventLog重播策略，它包括重放所有事件以“更新”所有ViewModel，但是，严肃地说，当我们有十亿行时它是否可行？
有没有经过验证的策略？有什么反馈吗？
答案 0 :(得分：4)
我知道EventLog重播策略包括重放 所有事件都要“更新”所有的ViewModel，但是，严肃地说，就是这样 当我们有十亿行时可行吗？
我会说“是”：）
您将为新摘要功能编写处理程序，无论如何都会更新您的查询方。所以你已经有了代码。编写特殊的一次性迁移代码可能不会给你带来那么多。当你必须对一个需要进行一次数据转换的新系统进行初始更新时，我会使用迁移代码，但在这种情况下，你的基础设施就会存在。
您只需要将相关事件发送给新处理程序，这样您也不会重播所有内容。
无论如何，如果您有十亿行数据，您的服务器可能会处理负载：）
答案 1 :(得分：2)
我目前正在使用JOliver的NEventStore。
当我们开始时，我们在应用程序启动时通过我们的非规范化器/事件处理程序重放我们的整个商店。
我们最初将所有数据保存在内存中，但我们知道这种方法从长远来看是不可行的。
我们目前使用的方法是我们可以重放一个单独的非规范化器，这样可以使事情变得更快，因为你没有通过没有改变的变形器来不必要地重放事件。
我们发现的技巧是我们需要另一个提交的表示，这样我们就可以查询我们按事件类型处理的所有事件 - 一个无法对正常存储执行的查询。