CosmosDB docs should contain a recommendation on how to save costs when using actor state management to handle large documents about docs HOT 5 CLOSED

Hey @olitomlinson

Yeah we've been running with all properties excluded from indexing for a while. That was driven more from a performance aspect in our case but happily helped with costing too. So we're running no indexing and compressed data at the moment and seeing huge ROI for that. Obviously the compression really only works when you're interacting with the state store in a key-value kind of way but that is how Dapr works through the state management API so it's relevant.

Truth be told, they've made our product viable in the longer term.

I'll try get a PR out for this soon 👍🏻

from docs.

@KrylixZA IMO this is good content to add!

Also, did you attempt to disable indexing on the container, as it's my understanding that this can be a huge RU saver for writes?

from docs.

@KrylixZA

Going back to your original point about compressing the state, I assume you're doing all this in your application layer?

To me it seems reasonable there should be an option to compression / decompression the state transparently by the cosmosDb state store component, so that end-users such as yourself don't have to take on this responsibility. What do you think?

from docs.

Is there something inherent to actors that cause extra queries to be done here? I am thinking, if you were to build the same "workflow" without the actors and query the state you need from a database each time your long running transaction needs to continue, would that be cheaper than using actors?

I guess what I'm getting at here is, does the actor framework abuse cosmos or is this just by nature of what you are asking it to do? If the latter, I don't really see how a warning is relevant.

from docs.

Hey @joshuadmatthews

From my experience, the actor framework is extremely efficient at managing state interactions.

Given it only reads from state when the actor is hydrated, you're saving a read every time the actor is called and it's sitting alive in memory.

The only thing about actor state is that it's raw, formatted JSON. By nature, raw JSON uses up a lot of KBs, and therefore RU/s in CosmosDB. This is because of all the white space and line endings to make it formatted.

Building the same code without the actor pattern would be very hard to get right. Specifically working around the race conditions reading and writing state. Actors are good at that, by nature of their implementation. You'd likely build it worse if you had to do it yourself. Or at least I would ;)

Alls I am suggesting, instead of a warning, is just a little note block that informs the user that if they are using actors and have no intention to query the state through bindings or the SDK directly, then dapr is only going to use the state in a key-value fashion. And by virtue of that, users stand to gain a lot in terms of financial benefits if they store their actor state in a compressed format.

from docs.