RFC: Add `CONFIG` control command

To support Terabyte-scale batch ingestions, we need a way to pause RocksDB compactions for some time (and a way to trigger compactions manually, but that’s just a new TRIGGER variant).

To avoid adding a new ingestion command for the sole purpose of batch ingestion, I propose we add a general-purpose dynamic configuration command.

Proposed syntax

• CONFIG <collection> SET key[=value]... → Overrides a configuration key. No =value is interpreted as =true
  • Example: CONFIG articles SET rocksdb.disable_auto_compactions rocksdb.disable_wal rocksdb.min_level_to_compress=1
  • Keys would map 1:1 with the rocksdb crate
  • Note that SET has to be stateful, as we are limited by Sonic’s line buffer size and one might want to override more configurations. We’d still close and reopen the database connection for each CONFIG command, though (but it’s fine and nobody will ever do it anyway).
• CONFIG <collection> RESET key... → Removes an override, which means Sonic will use the static configuration again for this key. Not specifying a key means “reset all”.
  • Example: CONFIG articles RESET rocksdb.min_level_to_compress

Questions

Arguments order

1. CONFIG <collection> SET key[=value]...
2. CONFIG SET <collection> key[=value]...

Personally I prefer option 1. as it looks SQL-like, has a clear positional argument separation and reads better but option 2. is also nice because it keeps the command as a prefix (easier parsing and documentation, plus is similar to TRIGGER syntax).

Arguments casing

1. CONFIG <collection> SET key[=value]...
2. CONFIG <collection> set key[=value]...

Option 1. is SQL-like (although SQL is case-insensitive); option 2. is like TRIGGER consolidate, etc.

Side question: Do we want to be case-insensitive? If so, we still have to choose a casing for documentation purposes.

Implicit boolean

In CONFIG <collection> SET key[=value]..., do you agree that =value should be interpreted as =true (flag style) or should we keep it explicit?

RESET or UNSET

1. CONFIG <collection> RESET key...
2. CONFIG <collection> UNSET key...

I like RESET as CONFIG <collection> RESET could clearly mean “reset all keys”, compared to CONFIG <collection> UNSET which is unclear. Also, RESET implies that the static configuration will be used again, while UNSET might be interpretable as “use RocksDB defaults”, which would be wrong.

CONFIG, or something else?

I find CONFIG to be a good fit, but we could use PRAGMA, OVERRIDE or something else. You choose.

Copy-paste answer form

### Arguments order

Preference: <!-- 1 (`CONFIG <collection> SET`) or 2 (`CONFIG SET <collection>`) -->

<!-- Comments -->

### Arguments casing

Preference: <!-- 1 (`CONFIG <collection> SET`) or 2 (`CONFIG <collection> set`) -->

<!-- Comments -->

### Implicit boolean

Preference: <!-- yes or no -->

<!-- Comments -->

### `RESET` or `UNSET`

Preference: <!-- 1 (`RESET`) or 2 (`UNSET`) or other -->

<!-- Comments -->

### `CONFIG`, or something else?

Preference: <!-- OK (`CONFIG`) or other -->

<!-- Comments -->