Relational DB in-memory?

Question

I have a simpleton question on Redis. If the key to it's performance is that it's in-memory, whey can't that be done on a regular SQL db?

Warthman

Answer 1

Any DBMS can be run "in memory". Consider the use of a ramdisk. However, most DBMSs (those with SQL) are not designed to run entirely in memory and put alot of effort to minimize disk IO and paging: a DBMS works very hard to keep the "relevant data" hot (in memory and in cache) -- IO is slow, slow slow.

This is because database data is often [and has historically been] significantly larger than main memory. That and main-memory is volatile :-) [ACID DBMSs do lots of works with write-ahead logging -- to a non-volatile store -- and other techniques to ensure data is never corrupted, even in case of a unexpected shutdown.]

Some databases, like SQLite use the same format for the disk and memory stores even though they explicitly support an in-memory store. Support for other [in-memory] back-ends and memory usage tuning vary by provider.

Happy coding.

Latashialatch

Answer 2

You may be interested in VoltDB

Malaya

*note: paid software – Earthshaking

Answer 3

The key is not only is it in memory, but it also has simpler operations than a SQL DB. Redis has simple operations such as GET, SET (and so on) using hash tables, and other optimized data structures.

SQL Databases generally take longer to compute, however they are a ton more flexible and in most cases more powerful (in terms of what type of queries). You most certainly cannot run JOIN queries in Redis, for example

Coffeepot

Sorry, was told by other developers that in-memory was the key and this wiki (subsection: Performance)> en.wikipedia.org/wiki/Redis_%28data_store%29 – Warthman

Answer 4

You may be interested in TimesTen (which is now Oracle).

In 11g its SQL has improved significantly, though still is not as powerful as that of Oracle.

Slavonic

Answer 5

You can do that natively with some SQL database management systems. But there are risks.

You stand to lose data if the server fails, for example. I don't think you can get ACID compliant transactions; any log file would have to be written to disk to survive a server failure. (I imagine it's possible for an in-memory SQL dbms to still write log files to disk, but I've never run across that myself. Not that I've looked much.)

Wellfixed

How about Flash memory then? Supposedly, Moore's law is faster than human transactional activity so the difference in speed of electronic byte movement is reduced. – Warthman

Solid-state drives (SSD) are relatively expensive. Today, a 256 Gb SSD from Crucial is almost $200. A 2 terabyte WD Caviar hard drive is less than $90. I think you'd need some additional engineering to guarantee data survives--a hard disk usually degrades before failure, but an SSD usually dies a flaming death. Your dbms would need to gracefully handle the utter destruction of the drive. – Citarella

Answer 6

On DB's in RAM: Traditional databases will eventually wind up in RAM:

Traditional database data — records of human transactional activity [...] — will not grow as fast as Moore’s Law makes computer chips cheaper.

And that point has a straightforward corollary, namely:

It will become ever more affordable to put traditional database data entirely into RAM.

Anaxagoras

When that day comes that will be great, but I need petabytes and beyond today. – Abyssinia

Do you believe the performance advantage of noSql will be diminished enough then to lose most of appeal? – Warthman