opendal icon indicating copy to clipboard operation
opendal copied to clipboard

Alternative implementation for memory backend.

Open damooo opened this issue 1 year ago • 2 comments

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.

damooo avatar Mar 09 '23 06:03 damooo

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.

Xuanwo avatar Mar 09 '23 06:03 Xuanwo

CC @PsiACE because he has some ideas about this as well.

Xuanwo avatar Mar 09 '23 06:03 Xuanwo

Fixed by https://github.com/apache/incubator-opendal/pull/2222

Xuanwo avatar May 07 '23 13:05 Xuanwo