4 ms·

Perhaps I am an old dinosaur, but this article merely annoyed me. "The key element to a memory image is using event sourcing, which essentially means that ever

Perhaps I am an old dinosaur, but this article merely annoyed me. "The key element to a memory image is using event sourcing, which essentially means that every change to the application's state is captured in an event which is logged into a persistent store." That is a key element of a database. It's called a logical log. "Furthermore it means that you can rebuild the full application state by replaying these events." Yup, logical log. "Using a memory image allows you to get high performance, since everything is being done in-memory with no IO or remote calls to database systems. " This is _exactly_ what sophisticated old-school databases do. You can have them require to write to the DB on commit, or just to memory, and have a thread take care of IO in the background. "Databases also provide transactional concurrency as well as persistence, so you have to figure out what you are going to do about concurrency." Righty-ho. "Another, rather obvious, limitation is that you have to have more memory than data you need to keep in it. As memory sizes steadily increase, that's becoming much less of a limitation than it used to be." So why not store your old-school DB in memory? I can understand the argument that you don't want to lock into a big DB vendor's license path, but the technical arguments here look distinctly weak to me. Maybe old-fashioned DBs are hipper than people think?

ynd 15y ago
When you say old-school DB do you mean something like mysql?
- kragen 15y ago
  Yes, MySQL is the kind of database that canonically uses approaches like physical logs and logical logs to provide ACID transactions (and, in MySQL in particular, replication.) The interesting thing that Prevayler and such things did was that they expanded the use of logical logs beyond simple relational tables to much richer sets of state.
  - ynd 15y ago
    Well I guess one difference between what he's proposing and mysql is that mysql forces you to write data abstractions that can fit into mysql. Same goes for NoSQL DBs. Using his approach you don't have to worry about that. Not sure that justifies dumping DBs altogether, but it's still an interesting advantage.
zzzeek 15y ago
These are all good points but the core of Fowler's article is that the persistence is against the application's object structures directly, with no translation to relational concepts needed (note I am the author of a very popular object-relational library, so I'm not in any way opposed to object-relational mapping...it's just interesting to see this approach that requires none). That it's stored in memory and is reconstructed against an event log are secondary to this.
- zwischenzug 15y ago
  Well, that put it much better than the article did. Since the points I've highlighted argue that he's talking about database features I'd call that a database without impedance mismatch, like erlang's Mnesia.
- fauigerzigerk 15y ago
  Initially he makes it sound like there is no translation into a different model but at the end of the article he takes it all back and for good reason: Also it's important to keep a good decoupling between the events and the model structure itself. It may be tempting to come up with some automatic mapping system that retrospects on the event data and the model, but this couples the events and model together which makes it difficult to migrate the model and still process old events. So, you're right that he doesn't envision a translation to a relational model but it's not just object structures either.
  - zzzeek 15y ago
    Right, but the event system in question could be built up nicely in a couple of hours most likely, and the level of "translation" would be minimal compared to OR mapping - no columns/rows/joins/tables/anything else like that. With such an application I'd probably still be writing the events themselves to a relational database for archiving and potentially sending out report-oriented data as well. I'm not sure how all of that would work out re: ultimately the whole app needs to be stored in an RDBMS anyway for various reasons but it seems interesting to try.

ynd 15y ago

When you say old-school DB do you mean something like mysql?

kragen 15y ago
Yes, MySQL is the kind of database that canonically uses approaches like physical logs and logical logs to provide ACID transactions (and, in MySQL in particular, replication.) The interesting thing that Prevayler and such things did was that they expanded the use of logical logs beyond simple relational tables to much richer sets of state.
- ynd 15y ago
  Well I guess one difference between what he's proposing and mysql is that mysql forces you to write data abstractions that can fit into mysql. Same goes for NoSQL DBs. Using his approach you don't have to worry about that. Not sure that justifies dumping DBs altogether, but it's still an interesting advantage.

zzzeek 15y ago

These are all good points but the core of Fowler's article is that the persistence is against the application's object structures directly, with no translation to relational concepts needed (note I am the author of a very popular object-relational library, so I'm not in any way opposed to object-relational mapping...it's just interesting to see this approach that requires none). That it's stored in memory and is reconstructed against an event log are secondary to this.

zwischenzug 15y ago
Well, that put it much better than the article did. Since the points I've highlighted argue that he's talking about database features I'd call that a database without impedance mismatch, like erlang's Mnesia.
fauigerzigerk 15y ago
Initially he makes it sound like there is no translation into a different model but at the end of the article he takes it all back and for good reason: Also it's important to keep a good decoupling between the events and the model structure itself. It may be tempting to come up with some automatic mapping system that retrospects on the event data and the model, but this couples the events and model together which makes it difficult to migrate the model and still process old events. So, you're right that he doesn't envision a translation to a relational model but it's not just object structures either.
- zzzeek 15y ago
  Right, but the event system in question could be built up nicely in a couple of hours most likely, and the level of "translation" would be minimal compared to OR mapping - no columns/rows/joins/tables/anything else like that. With such an application I'd probably still be writing the events themselves to a relational database for archiving and potentially sending out report-oriented data as well. I'm not sure how all of that would work out re: ultimately the whole app needs to be stored in an RDBMS anyway for various reasons but it seems interesting to try.