←back to thread

219 points amarsahinovic | 3 comments | | HN request time: 0.001s | 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 #
macintux ◴[] No.42188238[source]
Speaking as a former tech evangelist/engineer at Basho, there were a few significant challenges.

Riak is horribly unfriendly as a database: no SQL, it exposes eventual consistency directly to the developer, it’s relatively slow, and Erlang is a fairly unusual language.

While you can run Riak on a single server, you’d have to really want to.

Its strength is the ability to scale massively, but not many projects need that scale, and by the time you do, you’re probably already using some friendlier database and you’d rather make that one work.

replies(5): >>42188533 #>>42188580 #>>42188614 #>>42188779 #>>42191772 #
1. anotherjesse ◴[] No.42188779[source]
https://howfuckedismydatabase.com/nosql/ this infamous comic is about riak
replies(1): >>42189635 #
2. rubiquity ◴[] No.42189635[source]
That could also very well be about CouchDB which implemented indexes/views as MapReduce functions.
replies(1): >>42190321 #
3. senderista ◴[] No.42190321[source]
Back in the day we had a CouchDB MapReduce view (on Cloudant) which took a full month to rebuild (while an angry customer was waiting). The I/O inefficiency was absolutely off the charts.