在事件存储区中保存每个聚合的最新版本的快照

Question

我们目前使用SQL支持的事件存储（典型的2表实现），团队中的一些人担心，即使我们只使用事件存储进行写操作，事情可能会变得有点慢，因此建议不要到处添加快照，而是实际保持每个聚合的最新状态（以JSON格式）完全一致（与事件流）的快照。系统上的所有查询最终都将在读端完成，典型的SQL数据库将从ES（写）端以最终一致性的方式更新。

拥有这样一个系统将允许我们享受拥有事件存储的好处，同时完全消除任何可能的性能问题。我们目前没有使用任何“时间旅行”功能，尽管迟早会这样。

这是个好办法吗？里面有些东西让我不舒服。例如，如果我们需要某种时间旅行特性，在每个聚合的事件流中没有快照将证明是性能灾难。当然，我们可以拥有每个聚合实例的最新快照，也可以拥有整个事件流的快照。

如果我们决定走这条路，我们应该将给定聚合的快照更新事务化到同一聚合上的事件更新，还是应该只更新事件并以最终一致的方式更新快照？

Answer 1

在给系统添加不必要的复杂性之前，您可能应该运行自己的基准测试。我们已经注意到，当需要查询和应用数千个事件来从事件流重建聚合时，会出现一些性能问题，其中JSON到对象的反序列化是最大的性能瓶颈。如果您的每个聚合只有很少的事件（例如，<100)，您可能不会注意到实践中的任何显著差异。

大多数事件存储区记录每n事件/提交一次快照，例如每50-100次事件，并在程序集上查询最新的快照并应用自上次快照以来丢失的事件。如果还将所有旧快照保存在快照数据库中，时间旅行特性将与通常的查询一样快，并且只需要稍微多一点的持久性空间，而这在现在是便宜的。

应该始终从原始事务中写入快照（并且可以在另一个线程中生成），因为如果缺少最后一个快照，这并不重要，但是您不希望您的业务事务由于快照写入事务中的错误而失败。

根据您通常的系统正常运行时间和数据大小，将快照保存在内存或分布式缓存/graid或其他数据库（非SQL）中可能是有意义的。