2012-07-15 69 views
3

是否可以通过StreamId而不是通过其他Stream属性来搜索流?例如,如果每个流在Headers中都有CustomerId,并且我想要搜索具有特定CustomerId的所有流。在EventStore中搜索流

回答

6

事件存储被设计为仅通过实体的密钥来支持检索。为了支持其他属性的检索,数据以最终一致的,非标准化的方式编制索引,专门针对每个用例并在不同的地方。所以事件存储只存储事件并支持查询任何类型的索引投影。这些有点像关系数据库中的持久性视图,但它们可以存储在简单的键值存储中。一起,一个活动商店和一个投影商店构成了架构背后的基础设施的一部分。看看here和该博客的其他部分,了解更多关于此主题的内容。

+0

错了。从你的角度来看,这可能是事实。但实际上,有一个非常流行的事件存储实现,它允许通过除聚集ID以外的其他属性来查询聚合。检查getEventStore。实际上,这样的事件存储实现似乎很不可用。或者在非常罕见和特殊的情况下使用。 GetEventStore是使用CQRS的中小型应用程序的正确方法。 – 2015-04-19 20:11:08

+0

错在哪?是的,EventStore投影系统可以允许您根据事件中的任何属性对事件进行索引,但问题仍然是该索引最终保持一致 - 它在后台进行更新。在实践中,更好的选择是将二级索引存储在快速原子存储中,如Redis。 – eulerfx 2015-04-20 14:40:44

+0

理论上的查找表可能会很好。但实际上,如果一个事件存储以毫秒/百万的事件产生这样的查找表是不可行的。预测允许您过滤事件。所以不需要生成/分割这样的查找表。由于您可以生成快照并利用投影,因此在涉及通过任何属性搜索聚合时,这是最好的方法。第一行您错了:“事件商店专门用于支持通过实体的关键字进行检索。” – 2015-04-21 18:47:59

2

这很可能是您尝试错误地使用事件存储。构建事件存储库仅用于保存和读取用于重建事件源聚合的已提交事件流。实施提供了用于方便地实施基础设施问题的标题,例如请求/响应相关ID,审计,安全性等。如果您发现自己将业务属性放在那里 - 比如客户ID,那么您可能需要按照@eulerfx的建议来构建一个读取模型。

如果它是您正在查找的ID,那么您应该考虑为该客户创建CustomerID实际的事件流ID。通过ID加载特定客户正是您期望事件存储所要做的事情。

2

EventStore现在有预测可以做你正在寻找的东西。请参阅此博客的详细信息

http://geteventstore.com/blog/20130227/projections-6-an-indexing-use-case/

+0

创建蒸汽很便宜,所以有很多其他流,例如:每次事件进入(处理)时由投影创建的CustomerId-123都是实现索引后的一种方法,不会造成太多性能损失。 – 2017-12-20 14:54:35