You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when the application recovers from the changelog topic, it writes every state update to the rocksdb.
It's not very efficient and can lead to longer recovery times.
What?
Batch updates to RocksDB during recovery by a number of updates or total bytes in the batch.
Things to keep in mind:
Batches should not be too large, otherwise they will take too much memory.
Multiple batches can be accumulated simultaneously, one batch per recoverable state partition.
The text was updated successfully, but these errors were encountered:
Here you can try few things during the implementation of efficient batch updates to RockDB during the recovery process, by considering the above constraints:
Set limits on the number of updates and total bytes per batch to ensure batches are not too large.
Accumulate state updates in memory until the batch size limit is reached, then write the batch to RockDB.
Maintain separate batches for each partition to handle parallel recovery efficiently.
Once a batch reaches its size limit or the recovery is complete for a partition, write the batch to RockDB.
Why?
Currently, when the application recovers from the changelog topic, it writes every state update to the rocksdb.
It's not very efficient and can lead to longer recovery times.
What?
Batch updates to RocksDB during recovery by a number of updates or total bytes in the batch.
Things to keep in mind:
The text was updated successfully, but these errors were encountered: