在CQRS / ES世界中进行报告 [英] Reporting in the CQRS/ES world
问题描述
我认为我了解ES + CQRS上下文中的读取模型的概念（如果没有，请更正）。但是，对于在严重报告中使用它，我仍然有一些疑问。假设我使用关系数据库加上一些ORM来填充读取模型。一个基本的摘要统计数据读取模型可能看起来像这样：
I think I understand the idea of the read model in the context of ES + CQRS (please correct me if not). However, I still have a few doubts about using it in the context of ‘serious’ reporting. Let us say I use a relational db plus some ORM to crud my read models. One basic ‘summary stats read model’ could look like this:
class SummaryStats1
{
public Guid TypeId { get; set; }
public string TypeName { get; set; }
public Guid SubTypeId { get; set; }
public string SubTypeName { get; set; }
public int Count { get; set; }
}
给出一个事件：
TypeId = 3acf7d6f-4565-4672-985d-a748b7706a3e
TypeName = Bla1
SubTypeId = 41532aa1-f5d1-4ec4-896b-807ad66f75fc
SubTypeName = Bla2
规范化器将：
（1）检查是否存在上述组合的实例（由TypeId，TypeName，SubTypeId，SubTypeName定义）
（2）如果没有实例，它将创建一个实例并将Count设置为一个。如果有的话，计数将增加一。
(1) Check whether there is an instance of the above combination (defined by TypeId, TypeName, SubTypeId, SubTypeName) (2) If there no instance it would create an instance and set Count to one. If there is it would increase the Count by one.
这是可接受的报告方法吗？我猜一个人可以针对这种非规范化的数据结构（用于过滤和其他sql投影）运行非常有效的选择：
Is this the acceptable reporting approach? I guess one can run very efficient selects against this de-normalised data structure (for filtering and other sql ‘projections’):
SELECT TypeName, Sum(Count) FROM SummaryStats1 GROUP BY TypeName
CQRS / ES专家是否同意？这是做事的方式（即创建这些专用的报告读取模型）吗？对源代码/实际示例的任何引用将不胜感激。
Would CQRS/ES experts agree with this? Is this 'the way' of doing things (i.e. create these dedicated report read models)? Any references to source code/real examples would be very much appreciated.
推荐答案
这是可接受的报告方法吗？
Is this the acceptatble reporting approach?
当然， 报告方法根据您的要求而有所不同，但总体思路是正确的。
whether it's the resporting approach of course varies depending on your requirements, but the general idea is correct.
摘要：
您可以生成读取模型（有时使用的官方术语是渴望读取派生）。
You generate your read models (the official term sometimes used is Eager Read Derivation) based on events coming from your domain.
读取模型可以是任何您想要的模型（sql，redis，mongo等）。无论如何，您的查询都能保持高性能。例如，在您的示例中，没有理由没有两个读取模型来更有效地执行查询（尽管您所描述的内容在大多数情况下可能已经足够）：
The read models can be anything you want (sql, redis, mongo, etc). Whatever enables your queries to be performant. In your example for instance there's no reason why you can't have 2 read models to even more efficiently do your queries (although what you describe is likely enough for most cases):
- 您描述的SQL视图
- 由
typeName分组的预聚合视图每次在查询时都必须进行分组（而不是在规范化器中计算分组）。
- your sql view as described
- a preaggregated view grouped by
typeNameso that you don't have to do the group each time on query-time (instead you calculate the grouping in the normalizer).
简而言之，没有如何构造读取模型的正确或错误方法。这样做的好处在于，您可以完全自由地以所需的任何方式（根据您所设想的查询模式和性能瓶颈）对读取的模型进行建模，而不必考虑这些模型如何影响写入（仅仅是因为它们不会cqrs拆分读写）
In short, there's no right or wrong way on how to construct your read models. The beauty is exactly that you're completely free to model you read models in any way you want (based on the query pattern and performance bottlenecks you envision) without having to think about how those models impact writes (simply because they don't since cqrs splits reads and writes)
将事件外包与CQRS结合使用可提供更好的可能性，即创建新的readmodel并通过重放过去事件的数据来填充它们。事件源。
Using eventsourcing in conjunction with CQRS gives for even nicer possibilties, namely to create new readmodels and populate them with data simply by replaying past events from the eventsource.
仅是一些可能被视为数据读取模型的示例：
Just some extra examples of what might be considered a 'read model' of your data:
- 带有Redis的INCR视图（这似乎是您所描述的替代方法）
- Elasticsearch / Solr搜索索引
- KV存储/索引，用于通过键进行一些快速查找。
想法又一次是通过推动更新使这些读取模型 /视图始终保持最新（最终保持一致）给他们的事件（通常是通过pubsub的方式）
Idea again, is that these 'read models'/ views are always kept up-to-date (eventually consistent) by pushing update events to them (usually by means of pubsub)
更多的阅读说明，请参见答案以及指向此问题的链接：
使用CQRS的阅读方实施方法
For more good reading see the answer plus links to this question: Read side implementation approaches using CQRS
这篇关于在CQRS / ES世界中进行报告的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
