←back to thread

Open Riak – open, modern Riak fork

(github.com)
219 points amarsahinovic | 3 comments | 19 Nov 24 20:29 UTC | HN request time: 0.632s | source
Show context
chadd ◴[19 Nov 24 21:00 UTC] No.42188033[source]▶
I used Riak for a project back in 2012, the app that became the Whisper App, and as a huge Erlang fanboy, I was so excited about it.

But it was incredibly unreliable at scale, and my colleague and I spent a week of sleepless nights under incredible personal and business pressure - as the servers got busier and busier - ripping it out.

Still love vector clocks, though, and have fond memories of the Basho team presenting at Erlang Factory

replies(1): >>42188124 #
1. amanj41 ◴[19 Nov 24 21:10 UTC] No.42188124[source]▶
Vector clocks are very cool. Having read through how they were initially used in Riak, I was blown away that such an implementation could scale. I guess this is why Cassandra took a different approach?
replies(1): >>42188147 #
2. tibbar ◴[19 Nov 24 21:13 UTC] No.42188147[source]▶
Vector clocks are certainly cool but fundamentally premised on the idea of having multiple 'live' versions of a value at once. Amazon's original Dynamo paper required conflict resolution at the application level, which is a very strange framework to build applications on. (Notably DynamoDB has moved away from this, I believe to Last Write Wins.) Cassandra takes the latter approach by default as well, I believe.
replies(1): >>42188759 #
3. amanj41 ◴[19 Nov 24 22:24 UTC] No.42188759[source]▶
yes there's that idiosyncrasy, as well as client ideally needing to read the previous clock from the DB before writing an update for that key unless it's ok with the write being viewed as concurrent. Plus the extra memory overhead to store the clocks in the client.