understanding projections

EventStoreDB
1

I have some c# code that currently uses SubscribeToAllFrom to set up my projections for my read model

in the eventAppeared Handler I then filter those events to a subset of all the events in the system.

now that we have upgraded to eventstore v4 I am reviewing the projections to see if I can speed up this code, profiling shows that it spends a lot of time during a rebuild dealing with “uninteresting events”

It feels like if I create a projection like this for each of my c# projections and then have the projection subscribe to the output stream then I should get some major speed improvements

fromAll().when( {

‘EventType1’ : function(s,e) {linkTo(“ProjectionIndexStream-ProjectionType”, e)},

‘EventType5’ : function(s,e) {linkTo(“ProjectionIndexStream-ProjectionType”, e)},

‘EventType7’ : function(s,e) {linkTo(“ProjectionIndexStream-ProjectionType”, e)},

‘EventType8’ : function(s,e) {linkTo(“ProjectionIndexStream-ProjectionType”, e)},

‘EventType9’ : function(s,e) {linkTo(“ProjectionIndexStream-ProjectionType”, e)},

‘EventType12’ : function(s,e) {linkTo(“ProjectionIndexStream-ProjectionType”, e)}

})

is this the best way to write this projection or is there a better way?

Secondly: when I change my code - and need a new event type and want to rerun the c# projection - should I edit the projection or delete it and recreate it? should I version my output stream name or delete it and keep using it?

Thanks

R.

2

This is a question of efficiency vs agility. Every time your projections change you will need to re-run a large piece of work so that on each run they will run a smaller piece of work. How often are you doing the former vs the latter?

3

Out of curiosity, how did you measure?

When I looked at the same thing it turned out that deserializing an event (json.net), was the bigger task. (not counting actually writing to readmodel of course). Should be pretty easy to filter on eventtype, based on local projections.

The drawbacks of using a projection for another projection is that event store size increases (more io) and another layer of indirection is added (more latency).

/Peter

4

Thanks Greg - the only reason for a rebuild is because I have changed the projection - however I have been avoiding rebuilding my read model where I can - they take about 4 hours at the moment. My thinking was that by moving the logic to filter the events into event store - I could avoid the network costs of sending the events to the client and any additional overhead for dealing with them in the - I have not actually measured this but it feels like offloading the filter step to the server would help.

5

I think you might be surprised. usually its the IO to the readmodel that is the issue. Try bringing up an all subscription and just counting the total # of events in memory. How long does it take? Under most circumstances ES can send far faster then a projection can process them.