opendal
opendal copied to clipboard
Alternative implementation for memory backend.
Memory
backend is a critical one, as it can be used for simple unit tests, and others. As such, it is critical to have proper support for it, for it to act as a representative backend.
Currently, as inmem backend is implemented using a KV backend adapter, it imposes many limitations peculiar to only real kv stores on inmem backend too.
For example, we can persist an orbitrary data structure in inmem backend as a value, so persisting with metadata is not a problem. And range requests need not be simulated by returning entire copy of data and indexing at kv adapter level. Instead we can directly index.
As such, we need not impose limitations of kv stores on inmem backend.
It appears that we can categorize the kv adapter into two distinct types: "structural_kv" and "bytes_kv" (apologies for the unrefined names).
- structural_kv has the ability to store the value as a structure and doesn't necessarily require storage in bytes.
- bytes_kv bears a resemblance to the current iteration.
structural_kv can also be used to improve current moka, dashmap services.
CC @PsiACE because he has some ideas about this as well.
Fixed by https://github.com/apache/incubator-opendal/pull/2222