5

So I'm currently diving the CQRS architecture along with the EventStore "pattern".

It opens applications to a new dimension of scalability and flexibility as well as testing.

However I'm still stuck on how to properly handle data migration.

Here is a concrete use case:

Let's say I want to manage a blog with articles and comments.

On the write side, I'm using MySQL, and on the read side ElasticSearch, now every time a I process a Command, I persist the data on the write side, dispatch an Event to persist the data on the read side.

Now lets say I've some sort of ViewModel called ArticleSummary which contains an id, and a title.

I've a new feature request, to include the article tags to my ArticleSummary, I would add some dictionary to my model to include the tags.

Given the tags did already exist in my write layer, I would need to update or use a new "table" to properly use the new included data.

I'm aware of the EventLog Replay strategy which consists in replaying all the events to "update" all the ViewModel, but, seriously, is it viable when we do have a billion of rows?

Is there any proven strategies? Any feedbacks?

4

2 回答 2

5

我知道 EventLog Replay 策略，它包括重播所有事件以“更新”所有 ViewModel，但是，说真的，当我们确实有十亿行时它是否可行？

我会说“是”:)

您将为新的摘要功能编写一个处理程序，无论如何都会更新您的查询端。所以你已经有了代码。编写特殊的一次性迁移代码可能不会为您带来太多收益。当您必须对需要进行一些数据转换的新系统进行初始更新时，我会使用迁移代码，但在这种情况下，您的基础架构将存在。

您只需将相关事件发送到新的处理程序，这样您也不会重播所有内容。

无论如何，如果您有十亿行数据，您的服务器可能能够处理负载:)

于 2013-09-11T04:34:53.863 回答
2

我目前正在使用 JOliver 的 NEventStore。

当我们开始时，当应用程序启动时，我们正在通过我们的非规范化器/事件处理程序重播整个商店。

我们最初将所有数据保存在内存中，但知道这种方法从长远来看是不可行的。

我们目前使用的方法是我们可以重放单个反规范化器，这会使事情变得更快，因为您不会通过没有改变的反规范化器不必要地重放事件。

但我们发现的技巧是我们需要提交的另一种表示形式，以便我们可以查询我们按事件类型处理的所有事件 - 一个无法针对普通存储执行的查询。

于 2013-10-03T10:17:42.387 回答