This is a theory question, and I wanted to get some opinions. My
application is very write heavy, and I've found that CQRS can meet my
needs rather well. There are, however, times where I want to not have
to incur the cost of instantiating my aggregate, and simply store an
event directly.
Replay issues aside, what problems do you see with this? Let's take
it a step further and remove UnitOfWork from the equation as well, and
just send directly to the event store. Because some clients will be
sending historical commands (I want to capture history if they have an
outage, the client software isn't running etc. and have it weaved into
it's proper temporal context instead of when the command is sent).
I know that I also do not want to have any kind of transaction running
since it's just a single operation, and I want it to fail visibly if
it does. I also want the write to return as quickly as possible, so
no reads beforehand will significantly speed up the round trip time.
(I know the "correct" answer is to cache the aggregate, even so, there
is still a lock on the aggregate itself, plus lookup overhead, etc.)
doing this won’t get the AxonPol guys hunting you down. In fact, it’s a perfectly fine approach. There is even a pattern for it. Although the use of a Domain Model is usually the preferred approach, there is also the “Transaction Script”. Transaction Script is just a script that is executed, getting necessary data along the way. The outcome is exactly the same.
You need to take care in building up the correct EventMessages yourself in that case. Then store them in the event store, and publish them on the EventBus.
You can choose to use a CommandBus and implement the TransactionScript logic in a Command Handler, or even completely as a pojo service. Do note that if your script depends on “past actions”, you might have a hard time rebuilding the replay logic which Axon has already done for you if you use the Domain Model.
Just to let you know: I have done a PoC with a disruptor based command bus. On my machine, it can process 1.3M commands per second. The regular command bus did 400k on the same machine (laptop with 2-core 4-thread Core i7 processor). I have blogged about it here: http://blog.dutchworks.nl/2011/07/20/processing-1m-tps-with-axon-framework-and-the-disruptor/. All we need now is an EventStore implementation that can swallow that many events…
Very nice!! They have disruptors for output as well, did you try
using that over an event store? I had wanted to look into disruptors
for heavy I/O parts of the stack, glad to see it fits in nicely! In
regards to replay, I use a long timestamp value as my sequence so
replay doesn't become an issue (as long as timing is accurate
I have created a small (quick-n-dirty) filesystem event store that stores all events sequentially. It’s very fast in appending, but a little slower in reading. Generally, that’s no a problem in these types of systems. I can’t remember what the figures were, but disc access was absolutely the bottleneck here.
The disruptor works best if the number of processed matches the number of cores on the cpu. So adding another disruptor to take care of Event storage won’t make it any faster. But is should be possible to send the events over the wire to another machine, and persist them there.
We’ll be seeing more of the disruptor in Axon 2.0…
I've got an SSD disk in my laptop. However, benchmarks from LMAX show that "regular" disks are faster with sequential access. SSD's are faster with random, concurrent access.
When I've got the Axon 2.0 domain changes committed, I'll run the benchmarks on some high-end server somewhere. We'll see what Axon can deal with...
that's also my point of view. I guess there is only one way to find out...
I'll publish some benchmarking code when I'm done with the domain model changes in Axon 2.0. And then... SSD vs HDD battle! I'm eager to find out what kind of figures we can come up with.
