1

I am looking for a RAM/memory based database, and these two seem to be interesting:

Do you have any other suggestions?

I need more than one executable to be able to access the DB concurrently.

Thank you.

More details:

I want to use a database as a high level communication channel among executables, instead of using the file system or shared memory.

File system pros: persistent storage (I do not care about it in this project).
File system cons: slow; hardware stress (both for hard disk and SSD).

Shared memory pros: speed.
Shared memory cons: data size; non persistent storage; low level access.

RAM Database pros: speed; high level, query-like access.
RAM Database cons: data size; non persistent storage (not a problem in my case).

Improve this question
4
  • 2
    What are your parameters? This is a very vague question.
    – user1240
    Commented Jan 3, 2012 at 3:14
  • 2
    What do you mean with "RAM/memory based database"? Do you want the DBMS to not be writing to disks at all so any OS failure or shutdown will result in total loss of data?
    – ypercubeᵀᴹ
    Commented Jan 3, 2012 at 16:06
  • @RandolphWest: I still do not have a clear plan. I want to use a DB (instead of the file system and shared memory) to let executables communicate with each other.
    – Pietro
    Commented Jan 3, 2012 at 22:53
  • @ypercube: I want a DB that stores data in memory, and can optionally make periodic backups on hard disk. Data losses are not critical. It is used "just" as a high level communication channel among executables running on the same machine.
    – Pietro
    Commented Jan 3, 2012 at 23:01

4 Answers 4

Reset to default
3

I see two competing/conflicting requirements:

RAM/memory based database

and

more than one executable to be able to access the DB concurrently

They are competing/conflicting because modern operating systems normally enforce strict segregation for RAM allocated to specific processes (there are exceptions, but in the main this holds).

One option here is to copy your database to a RAM disk. That would allow separate apps to treat the database as if it were a file. The downside here is that the contents of a RAM disk won't survive a reboot of the host machine, and so you need a very robust system to keep your database saved to a real hard disk as well.

But really, if you want multiple apps sharing the same db, you're much better off using a database server. Enforcing safe, concurrent access is one of two main reasons databases exist as distinct entities from flat file stores (the other is efficient joins).

Improve this answer
2
  • 1
    Well, shared memory allows more than one process to access the same memory area. But even without that, the DB could communicate with the other processes through memory. E.g., the data could be in the DB private memory segment, and the results of the queries could be sent through message queues.
    – Pietro
    Commented Jan 3, 2012 at 23:42
  • I used a RAM disk. It seems to be the most transparent and portable solution; the OS is in charge of everything...
    – Pietro
    Commented Sep 27, 2012 at 9:27
2

SQLLite is single user (in practice) and embedded. That fails the "more than one executable to be able to access the DB concurrently" requirement.

Otherwise, all RDBMS are in memory once the data is loaded from disk so you can use any you want (SQL Server (not CE), MySQL, PostgreSQL, whatever).

Improve this answer
3
  • I would like the hard disk not to be touched at all.
    – Pietro
    Commented Jan 3, 2012 at 23:27
  • The fact that SQLite is single user could still allow it to interface with multiple processes owned by the same user, couldn't it?
    – Pietro
    Commented Jan 3, 2012 at 23:29
  • I checked (link), and yes, multiple processes can concurrently access the same SQLite database.
    – Pietro
    Commented Jan 5, 2012 at 23:36
1

Apache Derby or JavaDB may be worth a look too.

SQLite is pretty awesome provided you can live with the fact that only one user/process can write to the database at a time. Many processes/users can in fact read data and access the DB at the same time however (as mentioned by the SQLite FAQs).

Improve this answer
0

Not sure what exactly you mean with "RAM/memory based database" but you can have a look at the Memory storage engine in MySQL.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.