You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the time of writing, 4 engines are officially supported: LevelDB, RocksDB, UDisk, and UMem. Only the latter is in-memory, but it is constrained to the local memory available on the machine. Due to the increased popularity of Redis-like tools, we are considering integrating a Redis client to connect distributed in-memory key-value stores like:
All of them have somewhat different functionality, but all support the essential SET and GET verbs of the Redis protocol. Preliminary research suggests that Redis's primary maintained client SDK is hiredis, implemented in C. The C++ client is also built on it.
Briefly looking at the sources, the primary issue I see in both - is no ability to supply different allocators or arenas on a per-call basis. You can only override the allocator for the whole application. It is a standard limitation across almost all software packages. One ugly way of solving it would be to have thread_local variables with pointers to our arenas, but it only works if the underlying SDK continues working on the same thread.
Anyways, some form of integration would immediately extend newer projects like DragonFlyDB to support alternative modalities, like Graphs, Docs, and Search, with even broader functionality, than RedisGraph, RedisJSON, and RediSearch. If you want to take on this duty, here is a guideline for implementing a new engine/backend.
At the time of writing, 4 engines are officially supported: LevelDB, RocksDB, UDisk, and UMem. Only the latter is in-memory, but it is constrained to the local memory available on the machine. Due to the increased popularity of Redis-like tools, we are considering integrating a Redis client to connect distributed in-memory key-value stores like:
All of them have somewhat different functionality, but all support the essential
SET
andGET
verbs of the Redis protocol. Preliminary research suggests that Redis's primary maintained client SDK is hiredis, implemented in C. The C++ client is also built on it.Briefly looking at the sources, the primary issue I see in both - is no ability to supply different allocators or arenas on a per-call basis. You can only override the allocator for the whole application. It is a standard limitation across almost all software packages. One ugly way of solving it would be to have
thread_local
variables with pointers to our arenas, but it only works if the underlying SDK continues working on the same thread.Anyways, some form of integration would immediately extend newer projects like DragonFlyDB to support alternative modalities, like Graphs, Docs, and Search, with even broader functionality, than RedisGraph, RedisJSON, and RediSearch. If you want to take on this duty, here is a guideline for implementing a new engine/backend.
The text was updated successfully, but these errors were encountered: