2012-07-15 56 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