cqrs查询性能
我想知道什么时候应该考虑在查询存储中使用多个表。
例如，考虑产品描述发生更改的问题。如果您有许多包含产品描述的聚合，则此更改可能会对只读查询存储的同步产生巨大影响。
在什么时候您应该考虑对数据进行轻微的标准化以避免冗长的同步问题？这是禁忌还是可以接受的妥协？
谢谢，
I'd like to know when you should consider using multiple table in your query store.
For example, consider the problem where a product has it's description changed. This change could potentially have a massive impact on the synchronisation of the read only query store if you had many aggregates that included the product description.
At which point should you consider a slight normalization of the data to avoid lengthy synchronisation issues? Is this a no-no or an acceptable compromise?
Thanks,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
CQRS 并不是要使用每个视图一个表，而是每个视图一个表是 CQRS 使系统变得更容易的一个方面。
这取决于您，并取决于您的具体情况和需求。我会这样看，该查询的最终一致性的成本与高查询性能的需求是多少。您可能需要考虑系统的以下两个特征：
1) 平均。该命令的一致性，即更新受该命令影响的所有读取模型需要多长时间（还要考虑针对更改的优化存储过程是否会优于使用 ORM 或其他抽象以这种方式更新数据库） ）。
我的猜测是，除非您谈论的是数百万条记录，否则这里的一致性足以满足您的要求和用户对一致性的期望，也许几秒钟。
2）查询性能的重要性。您每秒收到多少个查询？你能处理每次都进行 SQL 连接吗？
在大多数实际场景中，这些事情中的任何一个的优化都是没有意义的。无论记录如何，您都可以使用良好的 SP 在几秒钟内完成更新，这对于 UI 刷新来说已经足够一致（请记住，发出命令的 UI 一旦知道命令成功，就可以保持一致）。
而且您通常不需要在系统中进行太多的查询扩展，以至于单个连接会伤害您。您可能不希望在代码和存储过程中执行这些连接增加内部复杂性。
与 CQRS 中的所有内容一样，您不需要从第一天起就使用和优化它的每个方面。您可以逐步优化这些事情。今天使用连接，明天完全非规范化，反之亦然。
CQRS is not about using table-per-view, rather table-per-view is an aspect of a system that CQRS makes easier.
It's up to you and depends on your specific context and needs. I would look at it this way, what is the cost of the eventual consistency of that query vs. the need for high query performance. You may want to consider the following two characteristics of your system:
1) The avg. consistency of that command, i.e., how long it takes to update all of the read models affected by the command (also consider whether an optimized stored-proc for the change would outperform say using an ORM or other abstraction to update your database in this way).
My guess is unless you are talking millions, upon millions of records the consistency here is sufficient to meet your requirements and user expectations for consistency, maybe a few seconds.
2) The importance of query performance. How many queries are you getting per second? Can you handle doing a SQL join every time?
In most practical scenarios the optimization of either of these things is moot. You can probably do the update, regardless of records, using a good SP in seconds which is more than enough consistency for a UI refresh (keep in mind the UI that issued the command can be consistent as soon as they know the command succeeded).
And you usually don't need so much query scaling in a system that a single join will hurt you. What you may not want is the added internal complexity of performing these joins in your code and stored procs.
As with all things in CQRS, you don't need to use and optimize every aspect of it from day one. You can optimize these things incrementally. Use joins today, and fully denormalize tomorrow, or vice-versa.