MongoDB seems to have copied a lot of functionality from Riak. This may be because MongoDB hired a number of former Basho engineers when Basho went bankrupt. That said, the new functions added to Riak after it became open source have successfully differentiated itself from Mongo…
Every database has positives and negatives. Redis is very good at set operations, but not as good at executing fast queries. MongoDB is a much cheaper data store than Riak, but not as highly available and scalable. Searching Riak is also faster than searching MongoDB or Redis…
Because of the RESTful HTTP interface, the consistency model, and because of the catalog-driven data model, Riak was an easy win over Redis and Memcached.
At the time I worked on the project those were the three competing technologies I evaluated. Couchbase didn't have memcache integrated at the time. Riak was by far the easiest to set up, and it's linking capability struck the right balance of having just enough relational …
Riak is a key/value pair store which is great for certain use cases. For our use case, the ability to search is an extremely useful feature. Apache Cassandra can provide this while Riak cannot. Also again for our use case, the ability to delete is critical as we strive to …
Highly available: If nodes go offline for any reason, the system still operates.
Highly scalable: There is a minimum of 5 nodes, which can handle a lot by themselves. When scaling is required, it can be done easily, with minimal to no downtime on large scales.
Very fast searching: Riak has SOLR indexing built-into the core product, which makes querying for data very fast.
Deletes!!! We've seen on numerous occasions where Riak has "resurrected" deleted data. We've worked with Basho numerous times and tried multiple changes to the way we interact with Riak to prevent the problem but it still remains. The deletes seem to reappear weeks, even months, after the delete was issued. We've had to work around this issue by providing a "deleted" flag for all data objects stored in Riak. Thus, we do no delete but simply flip the flag. Excess baggage we would really like to not have to worry about.
Search. Currently there's no way to tell what data you have in Riak without already knowing a particular bucket/key. There is a way to list the keys for a given bucket but due to performance implications, this is not a viable method to lookup data. Especially when you have a large amount of keys in the bucket.
Right now, I'm on a project where we need databases that can run on embedded systems. Riak isn't necessarily the best fit for that scenario. But when we need a clustered database, that's where we'd start considering Riak.
Despite Basho going bankrupt and the project becoming fully open-source, community support is reasonably good, albeit a little slow at times. Paid enterprise-grade support is also available from former Basho engineers but the same company also contributes to the community support for free for basic questions or specific knowledge areas.
Because of the RESTful HTTP interface, the consistency model, and because of the catalog-driven data model, Riak was an easy win over Redis and Memcached.
Riak has been a key part of our company's build process for our client's search backend. It is valuable for is in that it provides a reliable way to view the current search index.