Chronicle Map
Oak
Chronicle Map | Oak | |
---|---|---|
4 | 2 | |
2,687 | 266 | |
0.5% | -0.4% | |
8.4 | 0.0 | |
5 days ago | 4 months ago | |
Java | Java | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Chronicle Map
-
GC, hands off my data!
I decided to start with an overview of what open-source options are currently available. When it comes to the implementation of the on-heap cache mechanism, the options are numerous – there is well known: guava, ehcache, caffeine and many other solutions. However, when I began researching cache mechanisms offering the possibility of storing data outside GC control, I found out that there are very few solutions left. Out of the popular ones, only Terracotta is supported. It seems that this is a very niche solution and we do not have many options to choose from. In terms of less-known projects, I came across Chronicle-Map, MapDB and OHC. I chose the last one because it was created as part of the Cassandra project, which I had some experience with and was curious about how this component worked:
-
Off-heap memory in Java
Chronicle-Map: Chronicle Map is an in-memory, key-value store, designed for low-latency, and/or multi-process applications.
-
Solution for hash-map with >100M values
I've wrangled data sets in the ~600gb range using nothing but plain old Java and a few beefy boxes. This can all be kept in memory, but you have to go off-heap. You can use Chronicle Map and Chronicle Values to model this data and work with it off-heap in a way that's still very clean and object oriented. 128gb of RAM is cheap these days, whether you're in the cloud or not.
Oak
-
JEP draft: 64 bit object headers
Another to add to your collection, https://github.com/yahoo/Oak
-
Solution for hash-map with >100M values
Consider using an database (e.g. H2 embedded, redis) with an on-heap cache (e.g. Caffeine). Since you say it is a Zipfian distribution, the cache should absorb most of the requests. For an off-heap hashtable, you might try Oak as it is likely a faster implementation.
What are some alternatives?
MapDB - MapDB provides concurrent Maps, Sets and Queues backed by disk storage or off-heap-memory. It is a fast and easy to use embedded Java database engine.
Redisson - Redisson - Easy Redis Java client and Real-Time Data Platform. Sync/Async/RxJava/Reactive API. Over 50 Redis based Java objects and services: Set, Multimap, SortedSet, Map, List, Queue, Deque, Semaphore, Lock, AtomicLong, Map Reduce, Bloom filter, Spring Cache, Tomcat, Scheduler, JCache API, Hibernate, RPC, local cache ...
lasher - Lasher is an embeddable key-value store written in Java.
JetBrains Xodus - Transactional schema-less embedded database used by JetBrains YouTrack and JetBrains Hub.
ohc - Java large off heap cache
H2 - H2 is an embeddable RDBMS written in Java.
java-concurrent-hash-trie-map - Java port of a concurrent trie hash map implementation from the Scala collections library
Jedis - Redis Java client
FST - FST: fast java serialization drop in-replacement
Speedment - Speedment is a Stream ORM Java Toolkit and Runtime
SmoothieMap - A gulp of low latency Java