事件溯源 SQL Server 删除答案

【问题标题】：Event Sourcing SQL Server Delete事件溯源 SQL Server 删除
【发布时间】：2018-07-19 20:16:00
【问题描述】：

我们在 Microsoft SQL Server 2016 Enterprise 中使用事件溯源。三年后，我们想从写入和读取模型中删除数据。公司出于隐私和合规原因提出此要求。

我们想按客户订单日期的年份删除。（例如，当前年份是 2018 年，任何 2015 年或以下）。

我相信 Write Event Store 是不可变的；只能插入，不能删除。回放事件也需要它（或者我们也可以使用 ES 快照）。

是否允许使用不可变写入事件存储规则在事件源事件中删除？ MSSQL中正确的删除规则是什么？

某些主题：

(a) 客户可以在一年后返回，我们只收集增量数据。所以我们可能需要保留一些 eventstore 数据。 3年规则可以变成4年

(b) 此外，我们按订单日期的年份删除（与 Etlcreatedate 和 Etlupdatedates 不同）

【问题讨论】：

【解决方案1】：

事件存储是一个仅追加的持久性。这意味着它公开的接口不包含对持久事件的删除或更新操作；这是因为事件存储的正常操作不需要此类操作。

但是，事件存储可以迁移，更准确地说，它包含的事件可以在新版本的事件存储中进行修改 - 旧的事件存储保持不变，但修改/处理的事件存储在新的事件中店铺。然后，应用程序的配置可以引用新的事件存储，并且可以归档或删除旧的事件存储。

此迁移可以通过一次性脚本离线完成。它不需要在实时系统上运行。

可以对事件进行很多转换，在Greg's Young book 中介绍：复制和替换、两个聚合 - 一个流、一个聚合 - 两个流、复制 - 转换等。

在您的情况下，为了尊重隐私和合规性，您可以匿名化包含个人客户数据的事件。例如，您可以用空格替换客户的地址、姓名或任何个人数据。这样，您就不会弄乱聚合和读取模型上的事件重播。

迁移事件存储后，您应该重建所有受影响的读取模型，以确保清除所有个人/敏感/必须删除的信息。

如果您真的想删除旧事件（即早于 2014 年），那么您应该将所有这些旧事件折叠到快照类型/初始化类型事件中，这将使您的聚合处于有效的初始状态。这对于将来应该能够接收命令的聚合是必需的。

对于不应该再存在的聚合，您可以删除旧事件。

附注当我说“删除”时，我的意思是您根本不会将它们复制到新的事件存储中。

【讨论】：

【解决方案2】：

关于是否允许删除的问题，双方都有争论，但最终都是见仁见智，没有普遍的答案。我在实现事件溯源的Axon Framework 用户中就这个主题（和其他主题）进行了民意调查。一大群人偶尔会删除事件，另一大群人认为永远不应该这样做：没有明确的赢家。

如果您希望能够根据某些事件属性（例如订单日期）删除事件，部分解决方案可能是将这些字段作为元数据与您的事件一起存储，以及事件负载（在单独的柱子）。这将允许简单有效的删除查询。

如果您希望严格遵守事件存储的仅附加性质（不删除和更新）但需要删除数据，您可以考虑加密擦除：在写入时加密事件字段，将密钥存储在事件存储，在需要删除数据时删除键。这是我们在（商业）AxonIQ GDPR Module 中实现的。

【讨论】：