lasher
Chronicle Map
Our great sponsors
lasher | Chronicle Map | |
---|---|---|
1 | 4 | |
4 | 2,673 | |
- | 0.7% | |
0.0 | 8.5 | |
over 1 year ago | 1 day 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.
lasher
-
Solution for hash-map with >100M values
Do you need to update the data after initial load? If not, then I would suggest using my Paldb fork , otherwise you could try my lasher library. It's in early stage but first results are very promising, I was testing it with 10-100M elements and the performance was similar to java hashmap.
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
https://github.com/OpenHFT/Chronicle-Map - Maybe a better offheap map
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.
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 with features of In-Memory Data Grid. 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 ...
JetBrains Xodus - Transactional schema-less embedded database used by JetBrains YouTrack and JetBrains Hub.
H2 - H2 is an embeddable RDBMS written in Java.
Jedis - Redis Java client
Speedment - Speedment is a Stream ORM Java Toolkit and Runtime
HikariCP - 光 HikariCP・A solid, high-performance, JDBC connection pool at last.
Realm - Realm is a mobile database: a replacement for SQLite & ORMs
Crate - CrateDB is a distributed and scalable SQL database for storing and analyzing massive amounts of data in near real-time, even with complex queries. It is PostgreSQL-compatible, and based on Lucene.
jOOQ - jOOQ is the best way to write SQL in Java
jetcd - Java binding for etcd
EVCache - A distributed in-memory data store for the cloud