Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Riak – open, modern Riak fork

github.com

Post reply on HN
Print view View original

31–40 of 76 posts

Re: Open Riak – open, modern Riak fork

#31

Post by p_l »

btilly wrote: post #18
macintux wrote: post #13

Earlier quoted context omitted.

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 th…

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.

> 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.

Re: Open Riak – open, modern Riak fork

#32

Post by tptacek »

As someone who has used Riak in anger once in his career and who has a blossoming interest in FoundationDB I'd love someone to contrast the two systems. My knee-jerk reaction --- which I'm calling out as such! --- is that FDB has decreased the relevance of systems like Riak.

Re: Open Riak – open, modern Riak fork

#33

Post by masleeds »

tptacek wrote: post #32

As someone who has used Riak in anger once in his career and who has a blossoming interest in FoundationDB I'd love someone to contrast the two systems. My knee-jerk reaction --- which I'm calling out as such! --- is that FDB has decreased the relevance of systems like Riak.

I would tend to agree, perhaps a decade ago it was easier to define the uniqueness of Riak, and now there are alternatives that offer similar guarantees. So the relevance of Riak is not as obvious.

Also as we focus on stability on OpenRiak going forward, that means reducing some of the capability that may have made Riak stand-out in the scale-out space. The preference going forward is to do fewer things, but do those things predictably well.

There will be differences between Riak and FoundationDB, and I hope those differences are sufficient to make Riak interesting, and allow it to continue to occupy a small niche in the world of databases.

Re: Open Riak – open, modern Riak fork

#34

Post by pton_xd »

masleeds wrote: post #20

Riak has been maintained through the post-basho years by engineers at some of its larger customers (disclaimer - including myself). The focus has been on trying to improve the stability of the database when subject to complex failure scenarios under stressful load, with minimal need for urgent operator intervention. The focus has been on keeping those existing operators happy rather than seeking out new users. Evolut…

> we're looking to invest some effort over the next few months explaining what we've done, and to start to articulate what we see as the future for Riak. So if you're interested watch this space.

Where's that going to be posted? I'm not a Riak user but I am interested in hearing what others are doing in regards to improving failure scenarios in distributed systems.

Re: Open Riak – open, modern Riak fork

#35

Post by macintux »

binary132 wrote: post #15
macintux wrote: post #13

Earlier quoted context omitted.

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 th…

I wonder if some of these issues could be addressed sanely in an extension to the functionality

We were working on ways of making it easier (such as CRDTs to reduce the amount of work developers had to do to leverage eventual consistency), but these were pretty challenging problems to solve.

One of our biggest disappointments: we had plans to add a way to enforce strong consistency leveraging (IIRC) something akin to multi-paxos, but couldn't get it to work.

Re: Open Riak – open, modern Riak fork

#36

Post by masleeds »

pton_xd wrote: post #34
masleeds wrote: post #20

Riak has been maintained through the post-basho years by engineers at some of its larger customers (disclaimer - including myself). The focus has been on trying to improve the stability of the database when subject to complex failure scenarios under stressful load, with minimal need for urgent operator intervention. The focus has been on keeping those existing operators happy rather than seeking out new users. Evolut…

> we're looking to invest some effort over the next few months explaining what we've done, and to start to articulate what we see as the future for Riak. So if you're interested watch this space. Where's that going to be posted? I'm not a Riak user but I am interested in hearing what others are doing in regards to improving failure scenarios in distributed systems.

When we get stuff together there will be a link from our discussions page - https://github.com/orgs/OpenRiak/discussions.

Re: Open Riak – open, modern Riak fork

#37

Post by rubiquity »

anotherjesse wrote: post #29
macintux wrote: post #13

Earlier quoted context omitted.

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 th…

https://howfuckedismydatabase.com/nosql/ this infamous comic is about riak

That could also very well be about CouchDB which implemented indexes/views as MapReduce functions.

Re: Open Riak – open, modern Riak fork

#38

Post by SexyKitty17 »

masleeds wrote: post #36
pton_xd wrote: post #34

Earlier quoted context omitted.

> we're looking to invest some effort over the next few months explaining what we've done, and to start to articulate what we see as the future for Riak. So if you're interested watch this space. Where's that going to be posted? I'm not a Riak user but I am interested in hearing what others are doing in regards to improving failure scenarios in distributed systems.

When we get stuff together there will be a link from our discussions page - https://github.com/orgs/OpenRiak/discussions .

[flagged]

Re: Open Riak – open, modern Riak fork

#39

Post by SexxxyKitty17 »

masleeds wrote: post #36
pton_xd wrote: post #34

Earlier quoted context omitted.

> we're looking to invest some effort over the next few months explaining what we've done, and to start to articulate what we see as the future for Riak. So if you're interested watch this space. Where's that going to be posted? I'm not a Riak user but I am interested in hearing what others are doing in regards to improving failure scenarios in distributed systems.

When we get stuff together there will be a link from our discussions page - https://github.com/orgs/OpenRiak/discussions .

[flagged]

Re: Open Riak – open, modern Riak fork

#40

Post by senderista »

rubiquity wrote: post #37
anotherjesse wrote: post #29

Earlier quoted context omitted.

https://howfuckedismydatabase.com/nosql/ this infamous comic is about riak

That could also very well be about CouchDB which implemented indexes/views as MapReduce functions.

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.
Post reply on HN