differences with rocksdb
Opened this issue · 4 comments
I'm maintaining a binding of rocksdb-cloud in erlang. For now it's maintainned as a branch of the rocksdb binding but I'm considering to split it in its own repository. Do you think rocksdb-cloud will at some point completely difffers from rocksdb? does it makes sense to consider they are different project? I'm wondering if t wouldn't possible to have only the env differing. Thoughts?
What exactly do you have in the erlang binding that is not in core rocksdb?
Personally, I would like to see most of the rocksdb-cloud API be hidden and used internally. I want to be able to plug rocksdb-cloud into any environment that uses rocksdb without code changes (only configuration changes). This goal would allow rocksdb-cloud to run under Java or Erlang (as a DB) without any specific bindings. I am trying to head towards that goal via some Configurable and Customizable PRs in rocksdb proper (facebook#5361 and others).
In my mind, unless one needs to talk directly to the underlying cloud storage, there should not be a need for a rocksdb-cloud API.
@mrambacher I have 2 functions specific to rocksdb cloud:
- the creation of the environment
- open_cloud_db to allows you to pass the persistent cache path and cache size (shouldn't it be part of the env)
and I aims to add the last checkpoint feature you added. For now rocksdb_cloud is maintained in a branch. that point to rocksdb cloud source. If it was just the env, i could probably write something a little different to onnly make a cloud db a layer on top of normal db but passing a cloud env. The checkpoint could probably be a function of the env. Thoughts?
can we actually use rocksdb-cloud as as simple rocksdb instance if change is kept to default?
can we actually use rocksdb-cloud as as simple rocksdb instance if change is kept to default?
Yes, that seems right. It will be great to encapsulate all cloud specific functions in CloudEnv and not require any other changes to rocksdb api