seeking recommendations for simple in-memory DB *server* (no persistence needed) [closed]

Question

Should support multiple connections, preferably via ODBC. The clients will be running as separate processes on the same machine. No need for persistence, as the the clients will handle the persistence elsewhere. The clients are written in C++ if it matters.

The data is quite simple, it is a set of unrelated bi-directional maps. The access is either directly by a value or by a range (between X and Y), no updates. We don't actually need SQL here, so non-SQL solutions can also be considered.

The client application is multi-process and can run on several machines. Each machine should have a local copy of such DB, which is updated against the central store by its local clients.

Multiple Edits:

1. the platform is Linux
2. RAM disk is not an option for security reasons - we don't want that anyone with access to the machine would be able to view the data
3. the data should may be persisted only in encrypted form, so the solution should either not persist the data at all or allow a user-defined filter/plugin for persistence.

Answer 1

Just because of my familiarity with it, I would go with mysql. To use it as an in memory database use memory as the table type. Redis is an in memory NoSql Database that would probably be a perfect fit for this(It runs in memory, with disc writing for persistence only which can be disabled).

Answer 2

Any particular reason for not using SQLite with a RAM db opened?

Answer 3

RAM disk is not an option for security reasons - we don't want that anyone with access to the machine would be able to view the data

You're out of luck. Anyone with access to the machine can view the data out of /proc/$PID/mem anyway.

If you're talking nonroot access than use the /tmp/$directory/ method with chmod 700.

Answer 4

Here is a trick you can use under Linux, it is called "Lazy unmount".

1. Mount a tmpfs somewhere
2. Start up some process(es) to use it, which chdir() into that directory. You can use a mysql instance; mysql always does a chdir to its data directory.
3. After the process has started up successfully, umount the tmpfs with the -l (lazy) option.

Now the tmpfs still exists and will continue to exist as long as process(es) are accessing it, but it cannot be accessed by unrelated processes any more as it is no longer present in its mount-point.

Note that this in no way stops root from obtaining the data in the tmpfs, just makes it a little harder.

Also note that it may be swapped, so you should disable swap (or use encrypted swap) if you absolutely need it to be non-persistent.

Answer 5

Try Boost.MultiIndex. Not an obvious choice but it's based on relational DB concepts.

The concept of multi-indexing over the same collection of elements is borrowed from relational database terminology and allows for the specification of complex data structures in the spirit of multiply indexed relational tables where simple sets and maps are not enough. A wide selection of indices is provided, modeled after analogous STL containers like std::set, std::list and hashed sets.

Answer 6

Use mysql with datadir= a tmpfs you've mounted for the purpose. You'll need to cook up some startup script which installs the database (using mysql_install_db or something) at boot-time, of course, as you'll lose all the data.

Answer 7

memcached can be a viable solution. It is a key-value store that can be set to hold values for a certain amount of time, is scalable and is simple to set up and start using. It is also run in all sorts of environments. Here's the wiki site for more information, especially since the main page isn't nearly has helpful.