Hi Prakhyat, others have already provided good answers, I’d like to add one more point: if you build an OLTP system for “millions of transactions” then you’ll have to make a pretty big investment in case of an RDBMS solution just to cover the license fees; with that kind of money you can buy a LOT of storage, and as Vaughn pointed out the near-linear write characteristics of append-only logging allow much higher transaction rates than in-place updates. It is a trade-off between storage space, throughput and knowledge retention.
Regards, Roland 15 aug 2014 kl. 08:49 skrev Prakhyat Mallikarjun <[email protected]>: > Hi, > > Hi Team, > > I an working on a solution involving akka persistence and DDD/CQRS. The app > is configured with cassandra journal plugin to source the events.Snapshots > will also be stored in cassandra. Application is designed to have sharded > single writers. These single writers will eventually write state to in memory > datagrid. The state of the application is always maintained in in memroy data > grid, this is to make the reads faster. > > The app has below layers,: > > Front End > | > | > Processing Layer > | > | > Persistence Layer > | > | > In memory Datagrid Layer > | > | > Cassandra Durable DB > > > Front end--> Takes the command requests from web > Processing Layer-->Process the commands and can also source the commands > Persistence Layer --> Sharded Single writer PersistentActor will persist > event first into cassandra then will eventually update the domain state into > in memory datagrid. > > I accept the disks are very cheap. akka persistence/cqrs/DDD design requires > to store commands(if required),store events,store snapshot, store domian > state(read data and write data etc), Don't you think we will end up storing > lots and lots of objects? > > Tuning in data grid and cassandra....for durability, have to choose either > replication/distribution/multiple copies etc. Further overhead of storing > data and maintaining multiple copies. > > For big application's and also highly OLTP with millions of > transactions....data will grow in no time. Millions of transaction's means > million of events and these needs to be saved. This storing will take up > major disk space and will occupy space faster. > > This approach will lead to mammoth of data being saved. Planning on data > sizing will require lot of disk space(including data and multiple copies for > durability). Huge data means big big clusters. > > What are your thoughts? > > Note: I have the raised same query in eventsourced group. > > -Prakhyat M M > > -- > >>>>>>>>>> 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 http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- >>>>>>>>>> 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
