[erlang-questions] JFDB / Erlang Database

[Jared Flatow]

Hi all,

A few months ago, I was once again thinking about some of the problems I hit with every new Erlang project. Here’s how it usually goes:

 - I want to store data from Erlang, persisted on disk
 - I want to be able to search the data using arbitrary indices
 - DETS can work, but:
   - there’s the size limit
   - you have to do a lot of work to cache in memory, and even then it’s all or nothing
   - the keys can often take up a lot of (redundant) space, especially for ‘nested’ data
   - it doesn’t support any kind of range searches
   - writing the data and then the indices is not atomic, so you have to do a lot of work to make sure it’s always consistent
 - KV stores have the same problem about managing updating of data / indices
 - Relational databases do not let you store / index complex Erlang terms easily
 - Sophisticated searching (i.e. logical combinations of keys) is almost non-existent
 - Nothing *just works*, persisting and querying data from Erlang requires a ton of thought

I decided (finally) to do something about it - my solution is called JFDB (https://github.com/jflatow/jfdb <https://github.com/jflatow/jfdb>). I’ve been using it for a few months with great success. I thought others here might find it useful, especially with all the recent discussion about new mnesia backends and other Erlang data structures. The implementation is pretty wild - I don’t really know of anything similar - I think the best way to describe it is as a log-structured merge trie.

If you try it, I apologize in advance for a lack of documentation, tests, and the inevitable bugs you will hit. I think it’s in pretty good shape now, there are no known bugs, but it of course comes with a big disclaimer about being new and experimental. I’m actively working to improve all these things. If you have any feedback, I would love to hear it!

Best,
jared
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160722/d3812f1d/attachment.htm>