better way to use slice of rocksdb

Question

I'm trying to put binary data of image into RocksDB using Slice. But comparing to BerkeleyDB, result of RocksDB is too slow(almost 5 times). I wonder there's any mistake in my code using slice.

RocksDB code

FILE* file_in;
DB* db;
//default setting
Options options;
options.IncreaseParallelism();
options.OptimizeLevelStyleCompaction();
options.create_if_missing = true;

//open db
Status s = DB::Open(options, kDBPath, &db);
assert(s.ok());

//open file
int fopen_err = fopen_s(&file_in, "test.jpg", "rb");
if (fopen_err != 0) {
    printf("File path is not valid\n");;
}
//check file size
fseek(file_in, 0, SEEK_END);
long int file_size = ftell(file_in);
rewind(file_in);

//allocate memory and read file
char* buffer = (char*)calloc(1,file_size);
fread(buffer, file_size, 1, file_in);

//declare slice
std::Slice slice(buffer, file_size);

//insert into db
s = db->Put(WriteOptions(), "10", slice);
assert(s.ok());

//close and clear
fclose(file_in);
free(buffer);
slice.clear();
rocksdb::Status s2 = db -> Close();
if(s2.ok()) delete db;

BerkeleyDB

FILE* file_in;
Dbt file_key, file_value;
int flag;
//open db
DB db(0,0);
db.open(NULL, "database", NULL, DB_BTREE, DB_CREATE, 0664);

//set file key 10
file_key.set_size(sizeof(int) + 1);
file_key.set_data("10");

//open file
fopen_s(&file_in, "test.jpg", "rb");

//check file size
fseek(file_in, 0, SEEK_END);
long int file_size = ftell(file_in);
rewind(file_in);

//read file
char* buffer = (char*)malloc(file_size);
fread(buffer, size, 1, file_in);

//set file value
file_value.set_size(file_size + 1);
file_value.set_data(buffer);

//insert
db.put(0,&file_key, &file_value, 0);

//close
fclose(file_in);
free(buffer);
db.close(flag);

I wonder the performance between BerkeleyDB and RocksDB of default setting are natural or there're better ways to improve performance!

Answer 1

BlobDB would be a great fit for your usecase: https://rocksdb.org/blog/2021/05/26/integrated-blob-db.html

(on the other hand, storing large image binary in a key-value DB might not be the best solution. If possible, storing image in a blob storage system like S3 and store the metadata information in key-value store.)