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.
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.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}