tag:blogger.com,1999:blog-22587889.post8064504785804219074..comments2024-02-11T13:21:47.930+05:30Comments on Ruminations of a Programmer: A Phase Shift for the ORMAnonymoushttp://www.blogger.com/profile/01613713587074301135noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-22587889.post-57262545334364886222011-07-31T21:07:38.676+05:302011-07-31T21:07:38.676+05:30Thanks for noticing .. Now uploaded ..Thanks for noticing .. Now uploaded ..Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-30110480617218219132011-07-29T19:53:41.511+05:302011-07-29T19:53:41.511+05:30I'd like to read your post but there seems to ...I'd like to read your post but there seems to be something wrong with the figures/drawings? Could you restore them? <br />Tnx <br /><br />bartBart Van den Boschhttps://www.blogger.com/profile/14360253132165507876noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-64213025276034335902010-06-30T23:54:35.332+05:302010-06-30T23:54:35.332+05:30Hi Sergio,
I have no doubt that terrastore wil...Hi Sergio,<br /><br /> I have no doubt that terrastore will have something similar to write behind, nothing in its architecture prevents it from having it, except for time (which, god knows, I wish I had more of it myself as well ;) ). Agreed regarding the event sourcing aspect, just wanted to bring up the point that there are many aspects to think about when you implement such design pattern.<br /><br />-shay.banonUnknownhttps://www.blogger.com/profile/09036647645083589323noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-50076402532652051272010-06-30T19:27:16.264+05:302010-06-30T19:27:16.264+05:30And yes, the handling for event-based updates is i...And yes, the handling for event-based updates is intended to be asynchronous (although it doesn't have to be).<br /><br />Another driver was this was on Amazon infrastructure (via EngineYard) and MySQL seems to be all-too-often in CPU I/O Wait state (shared network I/O to the disks) whereas MongoDB with memory-mapped files was blazing.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-47407758939432279792010-06-30T19:23:37.786+05:302010-06-30T19:23:37.786+05:30Dean Wampler pointed out your ideas to me, and thi...Dean Wampler pointed out your ideas to me, and this is a valuable meme to be spreading right now. I put some other rationale into my <a href="http://grahamis.com/blog/2010/06/10/squealer-intro/" rel="nofollow">blog</a> with more to follow soon. I'll be interested to read your article!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-28671319258727404152010-06-29T15:22:01.391+05:302010-06-29T15:22:01.391+05:30Hi Shay,
You're absolutely right: durability ...Hi Shay,<br /><br />You're absolutely right: durability and replication of queued messages are important, but again, we're just talking about implementation aspects, rather than the general validity of the EventSource/EventListener solution.<br />For example, talking about Terrastore, it currently doesn't implement message durability and replication, but this will change in the future ... just let it approach version 1.0 ;)<br />Other write-behind features such as conflation or batching are missing too and they're maybe not that suited for event sourcing ... but again, just use the right tool for the job and switch to full-power write-behind if needed.<br /><br />Thanks for sharing your thoughts, always interesting stuff coming from you indeed ...<br />Cheers!<br /><br />Sergio B.Sergio Bossahttps://www.blogger.com/profile/09315991044338298083noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-89126068893822923422010-06-29T01:29:54.078+05:302010-06-29T01:29:54.078+05:30I completely agree :-)
It's very important to...I completely agree :-)<br /><br />It's very important to model your domain correctly (identify your aggregates) and have as little translation as possible when persisting it. As an old ORM guy I now a days have a hard time justifying ORM's for all but the rarest cases.<br /><br />Your focus on using Event Sourcing (a corner stone i CQRS) to separate Core Domain Persistence & Searching/Querying/Reporting is essential to keep your domain model and its persistence model sane, because they serve very different purposes and have much different characteristics. <br /><br />/JeppeUnknownhttps://www.blogger.com/profile/04504548256907157598noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-8741798275411589502010-06-29T00:56:17.597+05:302010-06-29T00:56:17.597+05:30Hi,
Sergio, regarding #2. Once you use the even...Hi,<br /><br /> Sergio, regarding #2. Once you use the event listeners to update another transactional store, then you would want to make sure that whatever you do against the "nosql" of choice is also done against the other datastore. Fifo doesn't cut it, you must create a way to have it highly available. So if one node dies after the change applies to the nosql, but the event was not raised yet, you won't loose it. Thats basic stuff, and write behind mechanism does that in a highly available, async, and reliable manner. I am not saying that it can't be implemented in nosql solutions, just that its not something new, and current solutions that don't behave like it are lacking.<br /><br /> Debasish: Regarding the column based store. Personally, cassandra, while very powerful, feels very much alien to your typical domain modeling. Thats not how things should be... .<br /><br />-shay.banonUnknownhttps://www.blogger.com/profile/09036647645083589323noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-63915350313815357632010-06-28T22:03:01.088+05:302010-06-28T22:03:01.088+05:30Hi Debasish,
What do you think about CRQS applyi...Hi Debasish,<br /> <br />What do you think about CRQS applying to this kind of solutions?<br /><br />ThanksJuan Carloshttps://www.blogger.com/profile/16535931058193709455noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-70197675759996683362010-06-28T20:16:16.308+05:302010-06-28T20:16:16.308+05:30Hi Kimchy -
Regarding your observation #1, let me...Hi Kimchy -<br /><br />Regarding your observation #1, let me take the example of a column store like Cassandra. It's true with column stores you have to think differently. But still I think we ensure that the data is organized in the way the application requires it. Take for example the case for organizing users in a Twitter like application (ref Twissandra use case in http://www.rackspacecloud.com/blog/2010/05/12/cassandra-by-example/). There we make both User and Username as column families just to support scalable writes and heavy queries with usernames. Had we used an RDBMS, we would have designed it differently. Needless to mention the Cassandra design is closer towards how the application uses the data.<br /><br />Another example is a graph database to store routing information where we are actually manipulating graphs in the domain model.<br /><br />But I agree that not all designs are very intuitive and you need to play to the strengths of the store that you are using. So choosing the appropriate store is a prerequisite.<br /><br />Regarding your observation #2, I agree tim-async of Terracotta gives you more flexibility. I just cited an example that Terrastore implements. In this context, it's not unusual to make use of various Event Sourcing patterns that can be processed asynchronously for pushing stuff into a relational database.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-68407460897558760082010-06-28T19:43:47.726+05:302010-06-28T19:43:47.726+05:30Hi Kimchy,
a few observations over your notes.
R...Hi Kimchy,<br /><br />a few observations over your notes.<br /><br />Regarding #1, I agree column stores provide difficult mappings in the same way of relational stores, but document stores are different: by wisely identifying aggregates and related entities, you can safely serialize the whole aggregate graph as a document unit, and only have to manage aggregate relations.<br /><br />Regarding #2, it really depends on the event source implementation: if events are synchronously enqueued in FIFO order, you don't have any consistency and coordination problem, just a kind of "time-shifted" consistency. You may only have to deal with idempotent messages in some cases, but it often happens in async distributed systems.<br /><br />Finally, I understand hand-crafted write-behind may be more powerful than commit hooks: but still, that doesn't mean it's always a better solution ;)<br /><br />My two euro cents,<br />Cheers!<br /><br />Sergio B.Sergio Bossahttps://www.blogger.com/profile/09315991044338298083noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-73165478323819924762010-06-28T17:43:11.892+05:302010-06-28T17:43:11.892+05:30Few notes:
1. The assumption that NoSQL provides ...Few notes:<br /><br />1. The assumption that NoSQL provides closer modeling to your domain model is not really true across the board. Column based storage are not really closer (Cassandra as an example), document based ones do come closer, but suffer from things like relationships.<br /><br />2. Once you use an event listener mechanism to apply changes done to an external data source, you run into your typical 2 resources coordination and consistency problems. For example, if firing the event is done on a different thread, and that node dies, your event might not have fired. In this case, you need to replicate the "need to fire an event" or make it highly available.<br /><br />In general what you say make tons of sense, and have been done for quite some time by data grids. Its called write behind, which solves the above problems, and is an order of magnitude more powerful (and more complex to implement ;) ) than post commit hooks... .<br /><br />-<a href="http://www.kimchy.org" rel="nofollow">shay.banon</a>Unknownhttps://www.blogger.com/profile/09036647645083589323noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-32356225964403635632010-06-28T13:58:31.818+05:302010-06-28T13:58:31.818+05:30Interesting view. It reminds me the Complex Event ...Interesting view. It reminds me the Complex Event Processing systems or Rules Engines, where the application handle real time events, but can still store relevant bits to a Database, generally in an asynchronous way.<br /><br />But here you have 2 data stores. Depending on the application, you may need to code some checks for consistency.Anonymousnoreply@blogger.com