search

facebook / rocksdb

A library that provides an embeddable, persistent key-value store for fast storage.
http://rocksdb.org
GNU General Public License v2.0
28.26k stars 6.27k forks source link

Feature Request: Live configuration changes #11898

Open JamesA212 opened 11 months ago

JamesA212 commented 11 months ago

speedb allows for live configuration changes without having to restart rocksdb: https://www.speedb.io/blog-posts/rocksdb-no-more-restarts-live-configuration-changes-with-speedb . This is very very handy as it allows us to make changes without restarting rocksdb/suffering downtime in the process. It would be great if rocksdb can support this feature too.

jowlyzhang commented 11 months ago

RocksDB's SetOptions API and SetDBOptions API support changing some options dynamically. Is this sufficient for what you are looking for?https://github.com/facebook/rocksdb/blob/fce04587b80db3d51d422ed8b1c52bd6291c9efc/include/rocksdb/db.h#L1380-L1398

JamesA212 commented 11 months ago

so currently as you said, rocksdb has apis that allows changing immutable options. However, the main issue is the way rocksdb does it. Rocksdb requires a code change and a redeploy/restart which hurts availability or we need to create an api endpoint that is called to modify the db at runtime. But even if we create an api endpoint, it's not scalable in a distributed environment like my case as I wouldn't want to hit every single machines that is running rocksdb (500+) to update the configuration globally. speedb allows you to specify a configuration file that is read every few x seconds and applies the changes dynamically without code changes, restarts, etc.. so in a distributed environment, all we need to do is to deploy a new version of the configuration file globally

jowlyzhang commented 11 months ago

so currently as you said, only some options are supported while speedb exposed way more functionality. The other issue is the way rocksdb does it requires a code change and a redeploy/restart which hurts availability (especially when running rocksdb on multiple machines so exposing an api endpoint that is called to update the setting dynamically without creating a new binary and deploying it is not an option). speedb allows you to specify a configuration file that is read every few x seconds and applies the changes dynamically without code changes, restarts, etc..

Thank you for the feedback. For the first one about limited set of options supported in this API. When this happens, more often it's because dynamically updating that option is not safe or doesn't make sense. For the second one, it's true at the RocksDB layer, updating an option is another function call. But it doesn't have to be a binary redeployment for the upper layer application, otherwise, it defies the purpose of these APIs to support dynamically changing. It needs to be used in combination with some config deployment mechanism. The application needs to periodically reading the config file and apply a SetOptions call when it sees a difference. I believe this is what some of our internal users are doing. There may be some existing framework to support this. RocksDB doesn't have plans to have this layer of support.

JamesA212 commented 11 months ago

understood, thank you. As a side note, is there any plans to pull in any improvements/features from speedb? For example https://docs.speedb.io/speedb-features/write-flow ?

jowlyzhang commented 11 months ago

understood, thank you. As a side note, is there any plans to pull in any improvements/features from speedb? For example https://docs.speedb.io/speedb-features/write-flow ?

They are doing a lot of cool work. I'm not aware of a pull in effort. But if SpeedDB wants to propose to merge some related improvements to RocksDB, I think we will be happy to check that.