“I've never got it when it comes to SQL databases. It's like, why? Just give me a hash table and a sh*tload of RAM and I'm happy.”
-James Gosling, BasementCoders Interview
That particular quote, which came from an interview James Gosling did with the basementcoders during JavaOne, seemed to capture more than a few people’s attention. The quote itself was heavily re-tweeted, while the assertion got many IT architects pondering the viability of loading everything into memory and removing the database servers from the enterprise landscape.
The initial assumption might be that this type of scenario is most feasible when talking about data that is largely read only, or where concurrency and consistency aren't huge issues. However, James Gosling was pontificating on the subject again at TheServerSide Java Symposium in Las Vegas in March, talking up the benefits of in-memory data storage; but this time 'The Father of Java' was extolling the virtues of this approach on highly transactional systems.
“When I talk to people that have high performance, highly transactional systems, there’s often this embarrassed pause when I ask how they are doing these many, many, many thousands of transactions per second. And all too often the answer is that it’s a hash table with a lot of RAM and a log file. And people tend to not think of RAM and Hash Tables as a database; but it is, and it works really, really well. And it’s not embarrassing.”
With half a terabyte of RAM, it's possible to clean up your enterprise architecture, Gosling said. Apparently, putting entire databases into RAM is one of his favorite tactics for consolidating databases. (You can hear Gosling's thoughts on the topic by listening to the media clip that accompanies this piece.)
According to Java Champion Jeff Genender, this approach to application design and scalability isn't necessarily a novel idea. "I have often seen it done. In fact, this is the primary basis for many of the NoSQL databases. If you have high volume loads of name-value pairs, such as a Facebook style implementation, then this approach makes sense. But if you have significant reporting needs, the relational approach is tried and true. Pick the right tech for the right problem."
So, we're still a long way away from declaring the death of the database. While the "hash table and a sh*tload of RAM" approach has its definite applications, it's not going to replace relational systems any time soon. Quoting Jeff Genender once again, "There is a time and place for this technology versus normal SQL. But there is no hammer for every nail. It's all a matter of picking the right technology for the problem."
Read the full transcript from this video below:
James Gosling Extols the Virtues of Hash Tables and RAM
James Gosling: One of the tricks that I find fun, is when I talk to people that have transaction
servers, really high performance transaction systems, often there is embarrassed pause,
and its like well, 'How are you doing these many, many, many thousands of transactions
per second?' All too often the answer ends up being, it is a hash table with a lot of RAM
and a log file. People tend to not think of RAM and hash tables as a database, but it is,
and it works really well and it's not embarrassing.
It is amazing how many big machines you can get rid of if you just put the whole
database in RAM. If you are lucky enough to have a system, where the database
will fit in under half a terabyte, because getting half a terabyte of RAM on a modern
server is actually not hard. For the last several years of Sun’s life, selling machines
with half a terabyte of RAM, was something we did way more often than I would have
ever expected. People will put a wiring diagram of Great Britain into RAM. It is not
stylish; it does not use any of the rocket science technologies. It just works, it works
really well, and it is one of my favorite ways to build stuff.