Improve Quality of EventSourcing.LogStorage.LogConsistencyProvider

[sebastianburckhardt]

This provider, while functional, do not quite deliver what we expect from a production-quality event sourcing system. I am planning to work on improvements that make this provider more realistically useful.

1. Change the storage layout so that logs are not stored in a single object, but automatically broken into pieces of manageable size (e.g. specified by a SegmentSize configuration parameter).

2. Add support for automatic snapshotting.

With these optimizations, users can do event-sourcing, and get good performance and robustness, on top of the existing, standard storage provider API (i.e. they do not have to configure a special type of event store first). This could be quite helpful to get the event-sourcing support off the ground more quickly.

I am going to focus on the first one for now; since it cuts down the replay time significantly, it reduces the need to do snapshotting.

[sebastianburckhardt]

I noticed that there is currently a limitation in the way StorageProviders are designed: they assume that there is a one-to-one correspondence between storage locations and grains.

For the purposes in this thread, I would need the ability to use multiple storage locations for each grain (so I can store log segments and snapshots). Can anyone think of a way to support this that does not require changing the IStorageProvider interface (and thereby break all existing providers, which is exactly what we don't want to do)? The methods currently look like this:

XXXStateAsync(string grainType, GrainReference grainReference, IGrainState grainState);

so I don't really have a clean way to pass a sub-location (e.g. "segment22"or "snapshot234").

[jdom]

IMO the IStorageProvider is not really a good abstraction that we should take forward for ES too... We would run into throughput problems pretty fast than if the journaling provider uses the full power of each platform it is adapting...

[galvesribeiro]

Yeah, I agree with @jdom. Like I said before, current storage provider should stay as is (although people already suggested a revamp on it for V2) and the ES store should be a diff implementation with diff abstractions IMHO...

[sebastianburckhardt]

I do think it is possible to get decent throughput for event sourcing even if going through a key-value store interface.

And I think it would be nice to allow users to use standard key-value stores for event sourcing - there are so many cheap & easy-to-configure options available.

But, this is not a high priority so I will put this issue on ice for now, especially since the existing IStorageProvider interface does not currently let me use multiple storage locations per grain.

[galvesribeiro]

@sebastianburckhardt when I say that current storage provider interface is not well designed for ES IMHO, I'm not saying that the underlying storage tech (e.g. Azure Tables, etc) isn't as well. Look at StreamStone... It uses AT really well for ES but it don't store the whole state as a single line in the table, like we do with current storage implementations.

If you think IStorageProvider is a goot fit to deal with GES or with AT as StreamStone does, then go for it. I'm just saying that the way I see it, it is not but I may be totally wrong. 😄

[jan-johansson-mr]

Hi guys,

The event sourcing implementation seems not up to production standard, according to the documentation at Event Sourcing. Did the effort move forward, or is the documentation not up to date?

Kind regards, Jan Johansson

[jason-bragg]

@jan-johansson-mr, There are groups that are using the event sourcing library (or a derivation of it) in production, so it's arguably production ready, but unlike other tech we've pulled over from MSR, no one on the core team has had time to vet and harden it. This is mostly due to prioritization and resources, not a lack of interest or trust in the current implementation.

I'd advise anyone interested in using it in production perform their own investigation on the tech and consider that improvements to it may be necessary. While the core team has not had the bandwidth to drive the effort to harden this functionality, we will make time to review and vet bug fixes and improvements needed by teams for production use.

[sebastianburckhardt]

The development of better storage providers was always part of the plan, and I would love to see it become real. I think at the current point of time, some people have implemented their own storage provider using the custom log consistency provider interface.

However, without some commitment or enthusiasm from the Orleans core team I am not willing to invest time at this point, as I have no guarantee that my work will actually be merged and have any impact. My last PR on event sourcing (#3773) has been sitting there for a very long time.

[digisimon]

Hi @sebastianburckhardt Currently I'm playing around with Orleans.EventSourcing and Event Store as storage provider. Because of an endless loop in CustomStorage.LogViewAdaptor I stumbled upon Issue #5107 and then found this issue here. Do you have any further information if those old PRs will get some attention in a forseeable future? Maybe @sergeybykov could make a statement on the future of Orleans.EventSourcing?

[jan-johansson-mr]

I've written my own custom event store to the Orleans event sourcing. However, I was initially confused about how event sourcing was defined (#5676). I think the focus are on other areas for now. Maybe community can chip in with pull requests for another provider that hopefully will pass quality and then make it into Orleans.

Let me stray off topic for a while...

There are other areas too that may need some love, e.g. stream providers (there is out of the box support for OrleansServiceBus (Azure I believe), AzureStorage, AWS SQS and Google Cloud Platform Utilities. If you're not using any of these providers, then you can use Microsoft.Orleans.OrleansProviders that is in-memory and not production ready solution for streaming. I've read that some effort has been made to use RabbitMQ, but none have made it so far into Orleans (due to this and that).

Now back to topic :-)

I think that the event sourcing implementation that we have will stay the same for a long time, and that's okay. Maybe some other good quality solution hits Orleans, or rewrite of API surface or whatever, and that's okay too :-)

[Caldas]

@sergeybykov or anyone from Orleans Core team (you need need a @coreteam), the current Event-Source providers available aren't enough. Any plans regarding this area?

[sergeybykov]

@Caldas No plans in the near term as we are busy with a number of other things. We are more than open to contributions. 🙂