我们使用apachekafka作为一种事件源机制，有效地将事件分发到多个存储库，以基于服务于数据的服务的用例构建应用程序状态。例如，假设我们有服务a和服务b。服务a和服务b都有一个相同人员的存储库，但是根据用例，数据的视图是不同的。我们的想法是，由于我们需要针对不同用例的数据的新视图，我们可以将事件流重放到新的或现有的存储库中。这是基于这里和这里概述的关于流处理和事件源的思想，通过事件重建应用程序状态。。
作为我们业务模式的一部分，我们可能会处理针对这些人的频繁更改（例如，姓名、地址和日期的更改有些频繁）。出现的一个新用例是，我们可能需要执行一个时态查询（即，向我显示在特定日期和时间的人的数据是什么样子）。显而易见的答案是，将所有事件重放到某个特定时刻，以重建应用程序状态。虽然这听起来在理论上是合理的，但我认为，当你可能在数年内有数十亿个事件发生时，这并不能很好地扩展。
目前的解决方案是，我们的kafka消费者将根据活动（例如地址更新、姓名更新等）从单个主题处理这些事件，并将个人数据的主副本更新为“现在”的样子，然后将更改增量的副本存储在一个单独的存储中，该存储被适当地键入，以便我们可以将更改与特定的人关联起来。理想情况下，我们认为键/值存储（nosql）是该数据的正确存储。这种方法是使用这个存储来重放所有的delta，以满足一个人的时态查询需求。
问题是，这种方法是否适合为数据的临时查询构建存储？在处理大量数据时，是否有其他方法甚至工具解决了这一需求？kafka对于等式中的事件源部分似乎是正确的，但是我担心的是，为了审计、灾难恢复和临时（时间点）查询的目的，需要将事件保持多年。