←back to thread

222 points amarsahinovic | 2 comments | | HN request time: 0.403s | source
Show context
tibbar ◴[] No.42188120[source]
I've never met an engineering team that used Riak, but it is used heavily as an example technology in Kleppmann's 'Designing Data Intensive Applications'. (I would say, informally, it's usually the example of the "other way" as opposed to other more well-known databases.) This does make me wonder what became of it, why it didn't take off.
replies(8): >>42188162 #>>42188238 #>>42188584 #>>42188647 #>>42188675 #>>42188741 #>>42191594 #>>42191757 #
1. veyh ◴[] No.42188647[source]
We used Riak at $dayjob at around 2014-2017 (iirc). I don't exactly remember it fondly. It was slow and unreliable. You could make it freeze/crash with the wrong SOLR query. (I was pretty good at that...)
replies(1): >>42188760 #
2. masleeds ◴[] No.42188760[source]
The SOLR part has now been retired from the last few releases.

Current development has been focused on improving the flexibility of secondary indexes. There was some funky stuff achieved by some users using overloaded 2i terms and distributed processing of regular expressions against those terms - the aim is now to make this more flexible to the modern developer using the language of projected attributes and filter expressions (ala DynamoDB). There's also some active work to both replicate-to and full-sync (i.e. reconcile with) external OpenSearch clusters.

The primary goal for OpenRiak is stability under load/failure as a K/V store - so the ultra-flexibility of in-built SOLR querying has been sacrificed in the move towards that aim. Anything that can do harm is to be offloaded or constrained.