Eviction Rules with Flash

is an entire list always either in memory or on flash, or can part of it be in memory? and for hash fields?

and if I implement a custom type with https://redis.io/topics/modules-native-types will that be written to flash / handled with any native type?

*like any native type?

have some more questions RE Flash + formalized the original ones…

  1. How does Flash handle Lists and HashTables? Are they serialized then passed to RocksDB as binary strings? And thus the entire binary string has to be brought into memory and deserialized just to append / remove / or access a single value?

  2. I assume the “BLOB mode” decision of whether to make a value Flash only, is only made at the top level key hierarchy correct? So for example, either the entire HashTable is a BLOB or not. Not just the enormous value written to one of it’s sub fields.

  3. RocksDB has a no maximum input value, but they say the below quote. Similarly HSE has a ceiling on values of 1MiB. How does KeyDB deal with values of such size? Still store them singularly, or break them up?

“Inserting megabyte values should work, but it will not be optimal use of RocksDB.”

RE custom types

  1. I assume right now KeyDB doesn’t have the ability to persist custom types? At the most basic level there is no way for it to know the size of a custom type, since we simply store a pointer to the value at the corresponding key, not the value itself. Can we add handlers to take care of this? I’ll write all the code if need be.

  2. Could a RocksDB interface be exposed so I can write to and read from it’s table? For example, I could implement a custom HashTable where I only keep some values in memory and the rest on disk.