DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > SharedHashMap vs Redis

SharedHashMap vs Redis

Peter Lawrey user avatar by
Peter Lawrey
·
May. 28, 14 · Java Zone · Interview
Like (1)
Save
Tweet
9.53K Views

Join the DZone community and get the full member experience.

Join For Free

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-values 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 process. 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 muchfaster.

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 the 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 performant 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.
Redis (company)

Published at DZone with permission of Peter Lawrey, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • 11 Reasons To Use Selenium for Automation Testing
  • Maven Tutorial: Nice and Easy [Video]
  • The Right Way to Hybridize Your Product Development Technique
  • Top Six Kubernetes Best Practices for Fleet Management

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo