On Tuesday, 19 August 2014 14:51:42 UTC+8, Martin Krasser wrote:

For full CQRS support, the discussions so far (in several other threads) 
> make the assumption that both write and read models are backed by the same 
> backend store (assuming read models are maintained by PersistentView actor, 
> receiving a stream of events from synthetic or physical "topics"). This is 
> a severe limitation, IMO. As Greg already mentioned elsewhere, some read 
> models may be best backed by a graph database, for example. Although a 
> graph database may be good for backing certain read models, it may have 
> limitations for fast logging of events (something where Kafka or Cassandra 
> are very good at). Consequently, it definitely makes sense to have 
> different backend stores for write and read models. 
>

Yes, I agree.  This is mentioned in my (long and poorly formatted) post: 
https://groups.google.com/d/msg/akka-user/SL5vEVW7aTo/ybeJKoayd_8J
 

> If akka-persistence should have support for CQRS in the future, its 
> design/API should be extended to allow different backend stores for write 
> and read models (of course, a provider may choose to use the same backend 
> store to serve both which may be a reasonable default). This way 
> PersistentActors log events to one backend store and PersistentViews (or 
> whatever consumer) generate read models from the other backend store. Data 
> transfer between these backend stores can be implementation-specific for 
> optimization purposes. 
>

I personally cannot see why Akka Persistence has to extend that far?  I 
think it may be able to stop at reliable (at least once delivery) to 
another actor connecting to a query store on the read side.   I think it 
may only need to cover [1] and [2] in this diagram:

<https://www.dropbox.com/s/z2iu0xi4ki42sl7/annotated_cqrs_architecture.jpg>

without forgetting sagas ;-)

BTW, can a PersistentView do AtLeastOnceDelivery?  I don't think so as ALOD 
seems to need a PersistentActor to maintain its delivery state.  But then 
how can a PersistentView reliably deliver events to an actor representing a 
query store?

It seems one needs a PersistentView that can read from a real (or 
synthetic) persistent event stream but also have its own persistence 
journal to maintain its delivery state.  Is this possible with some mixture 
of extend/mixins?
 

> For example
>
> - Cassandra (for logging events) => Spark (to batch-process logged events) 
> => Graph database XY (to store events processed with Spark), or
> - Kafka (for logging events) => Spark Streaming (to stream-process logged 
> events) => Database XY (to store events processed with Spark Streaming)
> - ...
>
> These are just two examples how read model backend stores can be populated 
> in a highly scalable way (both in batch and streaming mode). Assuming 
> akka-persistence provides an additional plugin API for storage backends on 
> the read model side (XY in the examples above) a wide range of CQRS 
> applications could be covered with whatever scalability and/or ordering 
> requirements needed by the respective applications. In case you want to 
> read more about it, take a look at akka-analytics 
> <https://github.com/krasserm/akka-analytics> (it is very much work in 
> progress as I'm waiting for Spark to upgrade to Akka 2.3 and Kafka to Scala 
> 2.11)
>
> WDYT?
>

That sounds very interesting, thank you for explaining. I will read up on 
Akka-Analytics.

I guess though for simpler systems the read side application could use Akka 
Persistence to write to various query stores (as I mentioned above) and 
also handle queries from the clients (send query to query store, process 
response, repackage for client).  

Finally, how do you see Cassandra comparing to Event Store in providing 
synthetic streams for the read side (i.e. can it)?

Cheers,
Ashley.


-- 
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to