Home » Software Development » SharedHashMap vs Redis

About Peter Lawrey

SharedHashMap vs Redis

Overview

This is a comparison between OpenHFT’s SharedHashMap and a popular key-value store Redis.

Any vendor will tell you how great their product is, so I will start by outlining why you wouldn’t use SharedHashMap, before I tell you why it is a “must have” for performant applications.
 
 
 

Why you would use Redis?

Redis is a more mature database, relatively widely used and it includes;

  • Support for multiple languages.
  • Access over TCP to remote clients.
  • A command line management tool.
  • It out performs many other key-value stores.

Why you would use OpenHFT’s SharedHashMap?

You need to maximise performance in Java. It outperforms Redis, and many other popular key-value stores by more than an order of magnitude in Java.

Why does SharedHashMap out perform Redis?

It is designed for performance from the start, by being as lightweight as possible.
  • It acts as an embedded data store, even across multiple processes. You don’t pay the price of TCP messaging via the kernel.
  • It was designed to be used in Java in a pause less, garbage free manner.
  • It is written in Java, for Java.

But C is faster than Java?

It is only faster when you compare like for like, and even then, not always.  However if you compare an embedded data store written in Java to one which must pass over TCP and translate between languages, the embedded data store is much faster.

How much difference does it make?

Benchmarks can be bend to suit any argument.  Vendor benchmarks tend to give you the most optimistic numbers because they know what their product will do best.  The simplest benchmarks for key-value stores are the same, and one of them is to start with an empty data store and setting lots of small key-values, and that at least gives you an ideal of the best you can hope for.  Your use case is likely to be slower, with more complex requirements.

Setting millions of key-values on a 16 core server with 128 GB of memory.

 Redis  SharedHashMap
Single threaded     ~10K updates/sec    ~3M updates/sec
Multi-threaded   ~100K updates/sec  ~30M updates/sec

 
The numbers are approximate, but they were performed on the same machine for the same operations in Java (using Jedis to connect to Redis)  YMMWV

Conclusion

Accurate and impartial benchmarks are a myth, but they do accurately serve you in giving a vendors view of a product.  OpenHFT’s view of SharedHashMap is that it is designed for Java and is performed in a way that many popular key-values stores cannot match.  If you need to maximise the efficiency of your Java system, you should be considering OpenHFT’s data management products.

Reference: SharedHashMap vs Redis from our JCG partner Peter Lawrey at the Vanilla Java blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*


Want to take your Java Skills to the next level?
Grab our programming books for FREE!
  • Save time by leveraging our field-tested solutions to common problems.
  • The books cover a wide range of topics, from JPA and JUnit, to JMeter and Android.
  • Each book comes as a standalone guide (with source code provided), so that you use it as reference.
Last Step ...

Where should we send the free eBooks?

Good Work!
To download the books, please verify your email address by following the instructions found on the email we just sent you.