←back to thread

222 points amarsahinovic | 1 comments | | HN request time: 0.2s | 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 #
btilly ◴[] No.42188614[source]
Back in 2011 I was working on a project that involved Riak. The difficulty and slowness for doing stuff corresponding to basic SQL operations was certainly a giant strike against it, and helped sink that project before it was released.
replies(1): >>42189099 #
1. p_l ◴[] No.42189099[source]
> corresponding to basic SQL operations

Ohhh, this brings memories of developers hitting the wall... Between different SQL databases!

Back in 2016 I was delegated at work to do ops on a project that had big data ambitions in Threat Intelligence space.

Part of how they intended to support that was Apache Phoenix, an SQL database backed by HBase, running on top of Hadoop that also provided object storage (annoyingly through WebHDFS gateway).

Constant problems with hung Phoenix queries and instability of Hadoop in entirety led me to propose moving over to PostgreSQL, which generally went quite well... Except several cases of "basic SQL operations" that turned to have wildly different performance compared to Phoenix and most importantly, to MySQL in MyISAM mode, like doing SELECT (*) on huge tables.

Fun times, got to meet a postgres core team member thanks to it.