Software Development

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.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Back to top button