I have a hard time keeping up with all the NoSQL engines out there. What can I do about it? I could easily evaluate, say, CouchDB in a side-project, but that's a) not necessarily going to tell me a lot about its characteristics at scale, and b) I can't do this even for the big NoSQL engines out there.<p>Is there a good overview? I realize that this is sort of an oxymoron -- a high level overview is doomed to fail because you can't compress the complex characteristics down to a few bulletpoints. Antirez put it this way [0]: <i>That said I think that picking the good database is something you can do only with a lot of work. Picking good technologies for your project is hard work, so there is to try one, and another and so forth, and even reconsidering after a few years (or months?) the state of the things again, given the evolution speed of the DB panorama in the recent years.</i><p>That was a comment to a pretty good overview[1], which despite being 3 years old is still useful. Apart from the purely technical characteristics, social characteristics such as rate of updates, adoption (and by whom?), openness are also interesting. You just "know" these things for the fields you're working in, but they're very hard to tell from outside and rarely discussed.<p>[0] <a href="https://news.ycombinator.com/item?id=2053594" rel="nofollow">https://news.ycombinator.com/item?id=2053594</a>
[1] <a href="http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis" rel="nofollow">http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis</a>
Ooo, theres some support for CRDTs in here:<p><a href="https://github.com/basho/riak/blob/2.0/RELEASE-NOTES.md#convergent-data-types" rel="nofollow">https://github.com/basho/riak/blob/2.0/RELEASE-NOTES.md#conv...</a>
This looks really nice. The lack of automatic merging was really the last hurdle preventing me from wanting to use Riak.<p>One issue: I'm surprised that the merge algorithm seems to generally pick the last write as the winner. For example about registers, the docs say: "The most chronologically recent value wins, based on timestamps". But that's not always correct: For example, if client A reads version 10 and writes version 11, and then some client B has version 9 and writes version 12, you have a conflict where node A's version should win even though it's older, since it's history is more correct.<p>Or is the documentation just ambiguously worded? It says the algorithm is _weighted_ towards last-write-wins, but also that it takes history into consideration.
As a RoR developer primarily, Jose Valim's new language, Elixir, which looks ruby-esque but runs on the Erlang VM, has piqued my interest in learning more about Erlang.<p>Erlang has always been on the outskirts of my awareness as something that might be worth looking into, but I can't quite determine what it's best used for. I know it's behind a lot of telecom stuff, and that it powers WhatsApp, but when you're not dealing with massive scale where you need distributed computing and fault tolerance, are there still benefits?<p>Does Erlang make sense for a side-project web app? Or is it mostly for enterprise-level applications?
Very interesting.<p>Riak is one of the core components in the new Spine2 data messaging and handling hub being built for the NHS here in the UK.<p>The NHS is one of the largest producers and consumers of data in Europe and the new hub is being evolved using FOSS software and agile methods.<p>More details:
<a href="http://www.ehi.co.uk/news/ehi/8534/spine2-built-in-house-on-open-source" rel="nofollow">http://www.ehi.co.uk/news/ehi/8534/spine2-built-in-house-on-...</a>
I'm most excited about the embedded Solr search engine in this release (Yokozuna), always felt that architecturally search and data should sit in the same place.