CQRS vs Transactional Data Store and Cache

[scot...@yahoo.com]

I have been threading discussions in couple places about this topic,
but this seems like the best place to hold it. To be clear I am not
looking for information implementation preferences, such as event
sourcing. I am just trying to understand what sets CQRS apart from
using a transactional data store and a cache to seperate the command
interactions and query interactions, respectively.

[Adam Dymitruk]

You don't EVER query the transactional side. Caching implies you do it
from time to time. It's important that the reporting structure is
different than the transactional. Reading is best done from different
structure than the one you write to.

--
Adam

http://adventuresinagile.blogspot.com/
http://twitter.com/adymitruk/
http://www.agilevancouver.net/
http://grou.ps/altnetvan/

[Rinat Abdullin]

IMHO: Performance, scalability, added business value and simplicity.

[Rinat Abdullin]

Adam, I would suspect that "EVER" is a bit harsh)) Probably 80-95% of
real-world systems do query the transactional side for
reading/reporting purposes, and it lots of these this implementation
would even be justified from the ROI perspective.

[Adam Dymitruk]

You're not doing CQRS if you are putting getters on your domain
objects to get their state for the UI. I'm not sure if I would want to
allow this exception at any point. On the other hand, I have to issues
for reusing the event store for other purposes - non-business logic
related purposes.

[Rinat Abdullin]

Yes, absolutely. This will be the deviation from the CQRS
architecture, if you read for domain objects (when CQRS is used
together in the solution with the domain objects). Yet, financially
this deviation might be worth it in some cases. I would even say,
larger the system is, higher is the probability that there are areas
that would benefit from non-CQRS approach (to optimize the overall
costs).

[Adam Dymitruk]

CQRS is not for every problem.

[scot...@yahoo.com]

Caching doesn't imply that you read anything from the transactional
data store. The cache is just another data store that may have a
different shape than the transactional store. You could choose to
populate a cache by reading the transactional store (pull), just like
you could choose to populate a cache by publishing events using pub/
sub or an observer pattern (push). Either way that's an implementation
detail and it remains abstracted from the client.

However, it sounds like you are saying that the pull model is
unacceptable in CQRS. Is that correct, or is that just in the purest
sense of the term? In other words, is reading from the database as
little as possible acceptable? If not, what about database identity
(autonumber) columns or sequences? If I never did a read how would I
ever know what the value is?

On Sep 9, 11:37 am, Adam Dymitruk <a...@dymitruk.com> wrote:
> You don't EVER query the transactional side. Caching implies you do it
> from time to time. It's important that the reporting structure is
> different than the transactional. Reading is best done from different
> structure than the one you write to.
>
>

> --
> Adam
>

[Rinat Abdullin]

Reading from DB is even unavoidable in some cases.

For example, if you are in a transition from in-house DTO-based
solution towards the distributed cloud-hosted CQRS system, at some
point of gradual migration you might have views stored in DB tables.
Logically this still might be a valid CQRS solution (architecture is
persistence-ignorant anyway).

[Polemann]

Aren't you mixing up CQRS and Event Sourcing. Its perfectly valid to
use CQRS with a relational data store (your standard 3NF db). You can
bypass the domain for your queries an still use the transactional
store without violating cqrs.

[scot...@yahoo.com]

I agree that using the same store doesn't violate CQRS. However, I
don't think there are any performance advantages to using the
principals when you don't separate them. As far as using a separate
transactional store for the query responsibility I see no issue there
either. A cache could very easily be a relational store.

But to bring the conversation back to my original question, what sets

CQRS apart from using a transactional data store and a cache to
seperate the command interactions and query interactions,

respectively?

My expectation is that there isn't an answer, because using the stores
in that manner is CQRS. I keep thinking I am missing something with
CQRS, so I am just looking for someone to confirm that, or reject it
with some salient points that back up the statement.

[Nuno Lopes]

Hi Scott,

I think I already gave you my answer in Greg's site. But here it goes.

Wikipedia defines cache as follows:

"In computer science, a cache (pronounced /ˈkæʃ/ kash) is a component that improves performance by transparently storing data such that future requests for that data can be served faster. " - http://en.wikipedia.org/wiki/Cache

IMHO a View in CQRS is not about caching, but about enabling alternative ways of structuring information in a domain model according to the client needs. Much as the View in MVC is not about caching, but about presenting information in a way humans mental models can understand. 

Granted a View can cache data, but it is not necessarily de case. For instance, if using an ORM, clients could directly access the RDBMS for queries. There no explicit cache scheme involved.

One of the projects we did, when interfacing Google search machines, we ended up needing to publish sets of content so that it could be properly indexed. 

So the CMS publishes such as ArticlePublished containing the the content published. The event is then handled by a processor that dumps the content in a format ready to be indexed by Google  a GoogleView.

So we have a read model for Google Machines and we have a transactional model.

Does this help?

Nuno

[Nuno Lopes]

I think In Greg's site I also gave an example using a Workflow system named W4 where we developed a separate View using a different structure so that queries could be done faster.

You also have to remember that not all systems use Relational Databases, We can use a OODBMS to the domain model and develop alternative views to speed up relational queries,

You can also publish data out of an OLTP to a OLAP system for the purpose of business analysis and so on.

This pattern is seldom used in the industry IMHO, yet it has never been characterizes.

We spent ages realizing that if not for relational queries probably we could have used other storage mechanisms for domain models.

The nice thing about CQRS, is that once we realize how it can be applied, it can become part of the system design from the ground up, rather then applying it in slices. If all systems published their events by design, not just for the purpose of caching, probably we would not face the integration hurdles we face every day.

Cheers,

Nuno

[scot...@yahoo.com]

Nuno, you present a great viewpoint and I thoroughly enjoyed reading
the write up on your blog. I would have to argue that the work you did
on Google Indexing essentially created a cache for Google. You took
data from a transactional store, transformed it to static content and
stored it somewhere else so that requests for that data would be
served faster. To add the rest of the paragraph from the Wikipedia
article on cache you referred to:

"The data that is stored within a cache might be values that have been
computed earlier...that are stored elsewhere. If requested data is
contained in the cache (cache hit), this request can be served by
simply reading the cache, which is comparably faster. Otherwise (cache
miss), the data has to be recomputed or fetched from its original
storage location, which is comparably slower."

I agree that Google needs a different view of the data, but I see your
transformation as similar to a calculation in that you don't want to
Google to have to index dynamic content since it would put strain on
your system.

I completely agree with your comment on relational databases, and I
was trying to be careful by calling them transactional stores for that
exact reason. However, you point out that you could publish views out
of systems that are not transactional as well. It still seems to me
that the point of CQRS is to separate command and query so that you
can scale out the system. Sure you could still use the same datastore,
but what's the advantage?

So maybe the disconnect is that I am looking at a different level than
you. I am thinking about the stores and how they are used, but the
CQRS principals you are referring to are at the domain. IMHO, I see
value in using the domain models (views), but I don't think it makes
sense without separate stores, as I don't think one would realize the
benefits of truly separating command from query. However, maybe that
benefit isn't what the base principals are about. Perhaps the use of
seperate data stores is an implementation detail, albeit an important
one.

On Sep 12, 5:30 pm, Nuno Lopes <nbplo...@gmail.com> wrote:
> Hi Scott,
>
> I think I already gave you my answer in Greg's site. But here it goes.
>
> Wikipedia defines cache as follows:
>

> "In computer science, a cache (pronounced /ˈkæʃ/ kash) is a component that improves performance by transparently storing data such that future requests for that data can be served faster. " -http://en.wikipedia.org/wiki/Cache

[Johanna Belanger]

Hi Scott,

One benefit that I see from CQRS, even when using the same backing
store for commands and queries, is that it simplifies both the domain
and the querying.

On the domain side, we no longer need to provide getters that serve
the queries, and the queries don't influence the design of the domain.

On the query side, instead of mapping from the store to the domain and
then again to DTOs, we can just map straight from the store to the
DTO. If our backing store has powerful query capabilities, we can make
full use of them to simplify and shrink our query logic. CQRS makes it
easier to use the right tool for the job.

It's essentially an application of the Single Responsibility
Principle, with the change isolation and simplification benefits that
principle provides.

HTH,
Johanna

On Sep 13, 10:11 pm, "scottr...@yahoo.com" <scottr...@yahoo.com>
wrote:

[Greg Young]

Can you give your definition of what a cache is? It sounds to me like
any time you keep a transformation of data you call it a "cache"..
i.e. would you call a data warehouse a cache?

--
Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer
de votre attention

[Jonathan Oliver]

@Greg,

A "cache" is the term that Udi uses as an introductory concept before
he introduces us to the "persistent view model"--you call it the read
model. The primary reason for this is to move people away from
thinking about "the database". which people seem to automatically
associate with a relational database. In other words, when hear
cache, think read model, because it's a cached copy of the
denormalization from domain model to read model. Re-read Scott's
original post on this thread with this definition in mind.

On Sep 15, 12:33 am, Greg Young <gregoryyou...@gmail.com> wrote:
> Can you give your definition of what a cache is? It sounds to me like
> any time you keep a transformation of data you call it a "cache"..
> i.e. would you call a data warehouse a cache?
>

> On Tue, Sep 14, 2010 at 1:11 AM, scottr...@yahoo.com

[Udi Dahan]

scottrudy,

CQRS is not just about the technical implementation - the one-way
non-failing commands are really at the crux of it all, and those are based
on the needs of multi-user collaborative domains where we can't prevent
users from seeing or acting on stale data. It is this philosophy that makes
CQRS powerful.

Cheers,

-- Udi Dahan

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.851 / Virus Database: 271.1.1/3130 - Release Date: 09/12/10
07:34:00

[Greg Young]

I don't think this version of the definition of cache matches up with
the rest of the world.

We could call a data warehouse a cache then.

[seagile]

Right on!

[Johanna Belanger]

Thanks, Yves. =)