Referring to the state management facilities of Quix, storage types section states that there’s an option to use local file storage. What is this local file storage? Does it ensure that the state is preserved between deployment restarts and shared between replicas even if state is not enabled in deployment settings?
Hi Sadeep,
We currently support 2 implementations for storage.
In memory
This is mainly used for testing purposes or as an intermediate storage before flushing to a more permanent storage.
Local file storage
This is a storage type which uses the disk. By default it is located where the application runs, in a folder called state. This is a storage type we introduced some time ago, uses individual files for each state. It works for a lot of use-cases, but it is not supporting transactions, TTL and other things, so we’re moving away from it in upcoming versions.
What is next?
We’re introducing a new “local” storage type which will rely on RocksDb. We’ll be able to do quite a lot of out-of-box features with this and also supports TTL and transactions.
State share
As mentioned above, these states are local states. This means they’re stored next to your application, not at a 3rd party location. However in Quix we offer something called “State” which is a read-write-many attached volume. This is something you can enable for each deployment.
This is where your “state” is stored in a persistent manner. Without this enabled, each time your application creates a state, it creates it on an ephemeral storage which only lasts the duration of the deployment.
As I mentioned, this is multiple read-write volume and is shared with all your replicas, so your state therefore is shared, even while it is “local”. The current implementation (local file storage) can run into issues when you’re trying to modify the same state file - so important how you structure it -, but upcoming RocksDb implementation will fix this.
Let me know if you have further questions!
1 Like