MapDB
lasher
Our great sponsors
MapDB | lasher | |
---|---|---|
5 | 1 | |
4,829 | 4 | |
- | - | |
0.0 | 0.0 | |
3 months ago | over 1 year 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.
MapDB
-
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:
-
Permazen: Language-natural persistence to KV stores
So, it's an object database, like Zope's ZODB on Python?
I like the idea, but I'd like to learn about use cases for it.
Otherwise, in Java, MapDB is about as far as I'd be willing to go: https://github.com/jankotek/mapdb/
-
what is the best persistent collection library?
Anyway, without further ado, I found MapDB (https://github.com/jankotek/mapdb) which does exactly that. Of course, they also provide their own Java collection implementations as well, so I suspect using it with Vavr would be a poor idea, but it is very cool in its own right anyway. Of course, there is also Apache Derby and HSQLDB, and those great options with a long history as well. I haven't played with these in a while though, so I might give them a try again soon for some personal stuff.
-
Ask HN: What are the best key-value self-hosted storage engines?
In Java I like
It is more feature rich than you want but in Python I'd probably just use sqlite3 since it is in the standard library.
-
Solution for hash-map with >100M values
I have had good results with mapdb
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.
What are some alternatives?
Chronicle Map - Replicate your Key Value Store across your network, with consistency, persistance and performance.
Oak - A Scalable Concurrent Key-Value Map for Big Data Analytics
H2 - H2 is an embeddable RDBMS written in Java.
SmoothieMap - A gulp of low latency Java
JetBrains Xodus - Transactional schema-less embedded database used by JetBrains YouTrack and JetBrains Hub.
PalDB - An embeddable key-value store written in Java
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 ...
Jedis - Redis Java client
time-series-concurrency-example - Time Series Data and CompletableFuture example in Java
Exposed - Kotlin SQL Framework
java-concurrent-hash-trie-map - Java port of a concurrent trie hash map implementation from the Scala collections library