4

I am looking for a C/C++ based distributed key/value store which has a clean enough design so I can plug in my own in-memory storage engine. It is OK even if I have to do code changes to be able to do that.

Does anyone have a recommendation? Or a similar experience in doing this? The Java based project Voldemort (http://www.project-voldemort.com/voldemort/) is a good example except it's written in JAVA and I am looking for something in C++ or C .

All Workers Are Essential
  • 15,826
  • 38
  • 96
  • 129
user1461001
  • 613
  • 1
  • 6
  • 16
  • Would redis work for you ? It is a key/value store, can be distributed and is written in C or c++ IIRC. It has a C++ API. – Félix Cantournet Jan 28 '14 at 15:56
  • @FélixCantournet is it possible to replace the storage engine in redis? Even if it is not allowed off the bat, if the design is modular enough, it should be doable with minimum code changes i suppose. Also Voldemort and other similar databases using a consitent hashing based data distribution, which is prefered. – user1461001 Jan 28 '14 at 16:07
  • I'm not sure I understand what you mean. Redis is intended to be an in-memory Datastore (as opposed to on-disk). You should check the FAQ, I'm not really familiar with the implementation, and how modular/extensible it is. – Félix Cantournet Jan 28 '14 at 21:24

1 Answers1

0

Berkeley DB is a key value store with a C (kinda C++) api. I'm not sure what you mean by 'pluggable storage' other than writing your own tuple management on top of the key value store.

But I'm not sure if that is efficient. I started out with Berkeley DB, but realized my queries were getting complicated, and I was writing too much overhead code.

I ended up migrating to SQLite. It is a C/C++, full SQL capable, but a very low, in-process, memory foot print. Then use an ORM tool on top of that to manage data structures.

The ORM tool from Wt works quite well in that regard.

The combination of the two may then allow you to get up to speed with your own code, rather than messing around with the access layer code.

Raymond Burkholder
  • 486
  • 3
  • 11