Thanks to Konrad for pointing out the recommended journals! (I guess I would like to try java+akka persistence+PostgreSQL now) And thanks to Daniel too for all the suggestions and sharing experience!
This may not be related to this topic but since you are sharing some other things I would share some too: I have experience with DDD in multiple projects in production and I have even tried CQRS in a small project once in the past too. On the other hand I tend to use DomainEvents a lot (EDA) but persist/update Aggregates as snapshots instead of rebuilding them from events mostly. Its seems easier to me and nobody was interested in keeping any history in the form of events or any other form so far in my projects. I have also experience with Cassandra/DDD at scale using LWTs/CAS. I know they say this can be 3 times slower and we do not recommend it but we did it and it works but you need experienced Cassandra administrators, you need to monitor it carefully because if it gets overloaded a little especially if you use LWTs very bad things can happen like downtime for long periods and so on.. there are many people that had bad experience with it in the past like big clusters slowly and steadily going down and they were not able to do anything to stop them. And you know that many people tend to manually shard/build clusters on top of RDBMS like Facebook/Youtube/Pinterest/... And now it seems that Akka is the best tool if you want both of these (DDD+CQRS), right? I have been looking at Akka in the past and if I remember correctly the only way to get "actor per Aggregate per Akka cluster" was to use cluster singletons which is not a solution. Now as I'm reading the docs it seems that cluster sharding improved and this is supported, right? https://doc.akka.io/docs/akka/snapshot/cluster-sharding.html >It could for example be actors representing Aggregate Roots in Domain-Driven Design terminology. Here we call these actors “entities”. These actors typically have persistent (durable) state, but this feature is not limited to actors with persistent state. > >Cluster sharding is typically used when you have many stateful actors that together consume more resources (e.g. memory) than fit on one machine. If you only have a few stateful actors it might be easier to run them on a Cluster Singleton node. By supported I mean that Aggregates can now be spread across the cluster (and not sitting on the oldest node like when using cluster singletons) and also you cannot get the same Aggregate/actor on more then one cluster node at a time even during split brain or any other kind of failures, right? On Thursday, November 30, 2017 at 12:00:19 PM UTC+2, Daniel Stoner wrote: > > I would second Konrads suggestion of going with the Cassandra version. I > have had great experiences with that, and the AWS DynamoDB community > version (Albeit it lacked a lot of features and we ended up porting our own > version and bug fixing/extending it. Surprisingly this ended up being a lot > easier than I was expecting and we began by rethinking the testing on the > library first to verify our understanding of its behaviour). > > The real question is - Have you tried using Akka persistence in your test > environment? Or even locally on your own PC? (It's easy to spin up > Cassandra on your PC from my memory of doing it). > > If your considering going towards Event Sourcing then be aware that it can > be tricky, long term in production (Having used it for 3 years) event > adaptation and migration becomes mandatory to understand and integral. You > really wish you'd knew about it on day one when you designed your persisted > events. > If you run a cluster topology then transient errors in your cluster which > for all intents and purposes may even go unnoticed - can mess with your > stored events and cause critical failure at the point you try to restart > the application - several days after that network blip manifested! > > Will you choose Protobuf for your database entities and then have problems > interrogating your production data if your system fails to start up? Will > you write your own serializer/use something like JSON so that you can debug > this one day? > > There are many topics to understand before you should be making the call > on which one of these journals to use in production and I suggest you try > out running a cluster somewhere with persistence implemented and a > continuous integration pipeline that deploys on every commit without > downtimes. See if you can support keeping it alive and have the necessary > practices in place to remedy issues with it. Load test it heavily with > tools such as Gatling or Apache JMeter - nothing causes nodes to drop out > of the cluster quite like huge stop the world garbage collections when you > run at scale! > > I don't mean at all to scare you off - writing applications which scale > well horizontally and utilize advanced patterns such as Event Sourcing (And > receive all the benefits which that comes with!) is hugely rewarding and > gives your software a definite edge over other architectures. But do try to > make sure that you understand what the cost is of having them and the extra > architectural, maintenance and support implications it may have on your > product. > > Perhaps have a read of: https://martinfowler.com/eaaDev/EventSourcing.html > If your thinking of heading in that direction - then try to understand how > it is Akka designed great solutions for each of the problems that this > architecture poses. > > On Wednesday, 29 November 2017 16:22:39 UTC, Konrad Malawski wrote: >> >> LevelDB is not, in any case, intended for production systems. >> >> Production ready journals would be: >> - the cassandra one, maintained by the akka team, it is most mature and >> has most features >> - the jdbc one, community maintained but seems to work well >> - we’ve heard of people using the mongo one, but I can’t say if that’s a >> good idea, likely not? >> >> Happy hakking >> >> -- >> Cheers, >> Konrad 'ktoso <http://kto.so>' Malawski >> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/> >> >> On November 30, 2017 at 1:13:58, Dobrin Ivanov ([email protected]) >> wrote: >> >> Hi, >> >> I'm trying to investigate whether to use akka persistence in production >> using java. >> >> I've been looking at >> https://doc.akka.io/docs/akka/snapshot/persistence.html >> >> And also tried this example : >> https://github.com/akka/akka-samples/tree/2.5/akka-sample-persistence-java >> >> The article refers to (native LevelDB) >> https://github.com/fusesource/leveldbjni while the example refers to >> (some java LevelDB port) https://github.com/dain/leveldb ... not sure >> why? >> >> Simply changing to use the native one in the example does not work: >> java.lang.NoClassDefFoundError: org/iq80/leveldb/impl/Iq80DBFactory >> >> >> >> >> Q1: So if I do not need a cluster/failover/replication (or i my want to >> do it myself for example) then can I use LevelDB in production? And if yes >> - I guess it should be the native one? >> >> >> Q2: Then the article recommends replicated journals. So does anybody use >> akka-persistence-jdbc OR okumin/akka-persistence-sql-async in production >> for example? >> Are there any recommendations? >> I guess they can be used in java too and not only in scala but please >> correct me if I'm wrong. >> >> Thanks! >> (inexperienced akka user) >> >> -- >> >>>>>>>>>> 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> >> -- >>>>>>>>>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
