Fog Creek Software
Discussion Board

Database in-memory


I am running an application that uses the database a fair bit - our database size is around 1 meg and not too complex.

At the moment the database is the single point of failure in the application - so we are trying to come up with ways to spread the risk :)

The application and the database are on seperate servers.

Would it be a good way to go by having the database in-memory? I think this would involve caching the database in the appication server.

The above  sound pretty complex and I am not sure it is the best way to go with our simple database and transaction rates.

Tuesday, June 22, 2004

Not sure what OS, Programming Language, etc. you are interested in, but Berkeley DB ( ) works across a range of solutions.

Tuesday, June 22, 2004

Thanks for your post.

Our specs:

Programming language : Java

Database: Oracle

OS: Unix

Tuesday, June 22, 2004

Buy an expensive server and run the whole thing on RAM DISK

Tuesday, June 22, 2004

You're not very specific.
Do you use a SGBD ?
1 Mb is a really small database for business apps. I wonder how you can have big troubles in such a configuration.

Tuesday, June 22, 2004

You must mean 1 Gb ?
1 Mb <-> Oracle is not very likely.

Tuesday, June 22, 2004

Even in circumstances where the database doesn't have mush in it, loading the entire thing into memory is more often a bad idea than not.

Writing and locking issues become more pronounced as the amount of data you have to deal with grows.

van pelt
Tuesday, June 22, 2004

I'm sure Oracle would cache it in memory anyway - and like everyone else has said 1 meg is peanuts.

Tuesday, June 22, 2004

> Even in circumstances where the database doesn't
> have mush in it

Yeah, been there, done that. The mush tends to gum up the works doesn't it?

Tuesday, June 22, 2004

make that "much"

van pelt
Tuesday, June 22, 2004

uses the data a fair bit,
1 Mb,

Not likely. I have built addressbooks with Access that are bigger than that.

Why would you want to cache the database on the application server? Whoever spec'ed the system decided to run a seperate database server. There must be a reason.  Why would putting it on the app server improve anything? IMO it would just make it worse.

Oracle has some pretty nifty cacheing options. Tune the hell out of your database. Use the correct indexes (not too many though).

What do you mean the DBMS is your single point of failure? Is it too slow? Does it keep crashing? There are so many potential solutions depending on what the exact problem is.

Tuesday, June 22, 2004

  You can check Prevayler

  It's an open source in-memory database made in Java.

  I never used it, just heard from a friend that they will be using it at his company, for a use similar to yours:  having an small in-memory database on a server for their app.

Ricardo Antunes da Costa
Tuesday, June 22, 2004

"Single Point Of Failure" (SPOF) means merely that you have ONE of a particular component, and IF that component fails the system fails.

In redundant systems, having an SPOF is a-priori a no-no.  Typically you get around this with a database by having replication to a hot-backup, which then goes on-line should the primary system hang.

Note your Oracle database could go down because of reasons as trivial as somebody kicked the cable out of the wall, to full virus infection leading to denial of service to the TCP/IP connections.

Note also one solution to the SPOF problem is to have a really-really reliable component.  Most SPOF solutions have a switch routing signal through one component or its redundant twin.  The switch is not usually thought of as a failure component, usually because it is a dumb switch with lots of reliability.

Tuesday, June 22, 2004

If your DB is really only 1 MB or even 1 gig, I think your oracle solution is to expensive.

However if you have an oracle server hanging around already then why not.

But should should consider using the multi tier approach. That is use something like sqlite or Prevayler ( as mentioned by someone else) to store user generated data and for fast lookups. Then at idle times synchronize your local db with oracle.

Tuesday, June 22, 2004

Idle times is when the user is typing something or anything that doesn't require db access.

Tuesday, June 22, 2004

I second the Prevaylor recommendation.  Unless you need SQL for some reason.

Tuesday, June 22, 2004

You mentioned an application server. Are you using Oracle's application server?

They have lots of options included in their distribution - have a look at those.

Walter Rumsby
Tuesday, June 22, 2004

How does holding the DB in RAM eliminate the single point of failure?  Doesn't it just move to the machine that has the in-RAM database?

John Rusk
Tuesday, June 22, 2004

If you're really attached to Oracle, you could consider a logical or physical standby database (now called DataGuard) where you send the archive logs across to the standby, then have to do some magic to make it come up.

Wednesday, June 23, 2004

*  Recent Topics

*  Fog Creek Home