looking for a stand-alone, in-memory data server with sequential access [closed]

Question

We need an in-memory data structure / DB server with following characteristics:

1. stand-alone server: will run on the same machine as the clients, so any kind of IPC is ok
2. sequential access: get next/previous key
3. two keys (string) per record: kind of a bi-directional map, actually
4. in-memory only: should have option for no persistence at all
5. RAM disk/tmpfs solution is not desirable
6. SQL/ODBC is an option, although not required
7. commercial product ok, if the OEM license price is reasonable

So far we have considered the following options, but no satisfactory solution yet:

• mysql: answers all requirements, but now answer yet as to how much an OEM license will cost
• memcached, cassandra: no sequential access, according to online docs
• Redis: seems as a nice tool, but again, I don't see get get nex/prev in the spec
• Postgres: couldn't make it work well on Linux/ODBC

Seems that all nosql in-memory DBs provide only direct access by key, hash-table style. Have not checked Apache Derby yet.

We run on Linux, the client is in C++.

Will be glad to have your suggestions. Thanks!

EDIT: It seems that we will be pursuing the mysql option, we've got a reasonable price offer, and it will also be useful as our main (persistent) DB. Thanks for all answers, it is as usual difficult to select just one.

Answer 1

I'd suggest Kyoto Cabinet, it has an in memory function and sequential access.

edit: what's wrong with stl map?

Answer 2

I'd have a look at SQLite, with the database file name set to ":memory:" this will create an in memory database that will no longer exist when your application closes.

It is public domain so that there is no issue with licensing

Answer 3

FastDB should work just fine. It supports in-memory configuration and shared access.

Answer 4

Redis doesn't sort keys, but it does have lists/sets which allow you to retrieve items in order. It's hard to know for sure if that would work without knowing why you want sequential access, but with NoSQL you often need to think a little differently about the data structures you use.