Need a distributed key-value lookup system

Question

I need a way to do key-value lookups across (potentially) hundreds of GB of data. Ideally something based on a distributed hashtable, that works nicely with Java. It should be fault-tolerant, and open source.

The store should be persistent, but would ideally cache data in memory to speed things up.

It should be able to support concurrent reads and writes from multiple machines (reads will be 100X more common though). Basically the purpose is to do a quick initial lookup of user metadata for a web-service.

Can anyone recommend anything?

Chary

What are you optimizing for? For example, read throughput (concurrent reads from multiple machines), fault tolerance in the face of machines becoming not available, low number of machines... Do you also need writes? – Ticket

Thanks, I've edited the question with this information. – Chary

How do you want your data distributed? Should all of the data be available to/on/from every node or not? In the first case the next question is "why the distributed lookup?". – Ticket

Answer 1

You might want to check out Hazelcast. It is distributed/partitioned, super lite, easy and free.

java.util.Map map = Hazelcast.getMap ("mymap");
map.put ("key1", "value1");

Regards,

-talip

Sweitzer

Answer 2

Open Chord is an implementation of the CHORD protocol in Java. It is a distributed hash table protocol that should fit your needs perfectly.

Derouen

Answer 3

Depending on the use case, Terracotta may be just what you need.

Hoogh

Answer 4

You should probably specify if it needs to be persistent or not, in memory or not, etc. You could try: http://www.danga.com/memcached/

Cram

Thanks, I've added a note that it needs to be persistent, which I think rules out memcached. – Chary

memcached was also my first thought, but "hundredths of GBs" is a bit too much for RAM – Condyloma

Answer 5

Distributed hash tables include Tapestry, Chord, and Pastry. One of these should suit your needs.

Allowable

Answer 6

OpenChord sounds promising; but i'd also consider BDB, or any other non-SQL hashtable, making it distributed can be dead-easy (if the number of storage nodes is (almost) constant, at least), just hash the key on the client to get the appropriate server.

Condyloma

Answer 7

Open Source Cache Solutions in Java

Oracle Coherence (used to be Tangosol)

JCache JSR

Munafo

Answer 8

nmdb sounds like its exactly what you need. Distributed, in memory cache, with a persistent on-disk storage. Current back-ends include qdbm, berkeley db, and (recently added after a quick email to the developer) tokyo cabinet. key/value size is limited though, but I believe that can be lifted if you don't need TICP support.

Diaspore

Answer 9

Try distributed Map structure from Redisson, it based on Redis server. Using Redis cluster configuration you may split data across 1000 servers.

Usage example:

Redisson redisson = Redisson.create();

ConcurrentMap<String, SomeObject> map = redisson.getMap("anyMap");
map.put("123", new SomeObject());
map.putIfAbsent("323", new SomeObject());
map.remove("123");

...

redisson.shutdown();

Booklover

Answer 10

DNS has the capability to do this, I don't know how large each one of your records is (8GB of tons of small data?), but it may work.

Oleaster

DNS assumes a hierarchical data structure, I'm afraid it won't do what I need. – Chary