←back to thread

219 points amarsahinovic | 1 comments | | HN request time: 0.216s | source
Show context
chadd ◴[] 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 #
amanj41 ◴[] 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 #
tibbar ◴[] 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 #
1. amanj41 ◴[] 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.