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. Evolution of the product since basho has been slow but significant.
The project now has support from Erlang Ecosystem Foundation, and 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.
It is expected to remain a niche product though. However, it may still find a home for those demanding specific non-functional requirements, with an acceptance of some functional constraints.
I was under the impression that once you learned how to pet the cat forwards (the non-triviality of getting to that point being an oft cited adoption barrier, but still), Riak was really quite excellent at recovering from things going wrong, which would fit with that being what you were trying to say.
Or maybe my guess has gone completely wide, in which case please do break out the small words and crayon drawings and explain what you actually meant :)
Did you mean "stability"?
Could you elaborate your understanding of the term? I can see it related to concepts like eventual consistency, just unclear of how it would be considered a positive characteristic. I'd have thought that a deterministic outcome would be important in a database system?
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.
Nearly 10 years later and I still consider my time working on Riak at Basho the highlight of my career.
After leaving, my original plan was to found "Basho 2.0" after my non-compete expired. But, unexpected personal/family hardships in 2015-2018 made big-tech money the better choice for awhile, and Cloud/competitors continued to chip away at the market.
Often stil regret not taking that path.
But, happy to see technology I'm very fond of still living on and providing value to the world.
It was successful at first, but ultimately we traded one set of problems for another (how novel, I know).
In particular, I underestimated the pain of troubleshooting the database itself. Riak was a new product, we were a small team that had never run anything on BEAM, and ultimately we lost too many days debugging and trying to make sense of Erlang stacktraces.
The Basho folks were great, and to this day I appreciate how quickly they fixed a number of bugs for us. But ultimately it wasn't enough -- we found problems faster than they could be patched.
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.
In the end more and more data was offloaded to MariaDB, until one day the last remaining data couldn't justify the cost of the Riak cluster. I think we swapped out an eight node Riak cluster for two largish MariaDB database (one being a hot-standby).
For one of the other clients it was the exact same scenario, only we had been contracted in to help run the Riak cluster, which we didn't do well. Once they had migrate of it, to Oracle I think, the client left.
To me it always felt like it was just the wrong tool for that particular job. Someone really wanted to be able to jump on the NoSQL hype and sell something. They picked Riak, because it honestly looked really good, and probably was, compared to MongoDB, CouchDB or whatever else happened to float around at the time. It just wasn't the right tool for the problems it was applied to.
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.
Though it had a couple years head start when there really no other options for people wanting that kind of kit.
(I can't, of course, speak to the truth of this, only that over a couple decades of knowing the dude in question and working with him on and off he had sufficient Clue that I expect he did put in the effort before coming to that conclusion)
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.
The engineering exodus around that time sorta killed the project though, and we never were able to do the big follow-up work to make it really shine.
(Disclaimer: Former Basho Principal Engineer, primary author of strong consistency work, lead riak_core dev from 2011-2015)
I think another 18 months would have been enough too. But it just wasn't the right environment after the hostile take-over / leadership transition.
I apologise if we do eventually cut it. Having worked through the code when chasing unstable tests, I developed an appreciation for the quality of the work.
It does not matter what your technology is, or how theoretically superior it is. Getting it to actually work well "in production" is a whole separate thing than simply designing it and writing code. When it's a very small system, it will look like it's doing great. As it gets bigger, the seams will start to burst, and you will find out that promises and theory don't always match reality.
In the end, while its aims are great, it takes a whoooooole lot of work to smooth out the bumps in such a system. You need experts in that technology to address bugs in a timely manner. You need developers versed in the system to properly build apps utilizing it. You need competent operators to build, orchestrate, operate and maintain the whole thing.
All of that is made easier by using simple technology that everybody knows, that there's a huge support community for, professional services for, etc. A technology like MySQL or Postgres etc, has the corporate, development, support, etc to make it easy to work with at any scale. A little janky at times, limited, but dependable, predictable, controllable.
A small bespoke system with a small support community and virtually no corporate support is, comparatively, a hell of a lot more difficult/costly to support and harder to make work reliably.
Our code was in Clojure, and we just wrapped the Java client. The conflict resolution was a steep learning curve, but overall, it was kind of nice (coming from Mongo).
But man, Clojure stack traces wrapping Java stack traces wrapping Erlang stack traces in a Kafka consumer... I wish that hell on no one.
Also bourbon. Probably *lots* of bourbon.
I was part of a recent cloud migration. Part of on-prem (though unfortunately not migrated by my team) were this very first Riak Cluster I saw in production.
The engineering team used it as "kind of S3" for images, with 3 to 5 PHP scripts providing an interface to Riak and imageMagic. It seemed to me like a good abstraction and I think the migration to S3 was mostly painless.
Other than that I only had contact with Riak at university around 15 years ago, when we tested cluster setups of several NoSQL databases and tried to manually introduce faults to see if they could heal. Riak passed our test at that time, MongoDB didn't.
I fondly remember writing a Go driver for it. Was a good experience: https://github.com/riaken/riaken-core
Current development has been focused on improving the flexibility of secondary indexes. There was some funky stuff achieved by some users using overloaded 2i terms and distributed processing of regular expressions against those terms - the aim is now to make this more flexible to the modern developer using the language of projected attributes and filter expressions (ala DynamoDB). There's also some active work to both replicate-to and full-sync (i.e. reconcile with) external OpenSearch clusters.
The primary goal for OpenRiak is stability under load/failure as a K/V store - so the ultra-flexibility of in-built SOLR querying has been sacrificed in the move towards that aim. Anything that can do harm is to be offloaded or constrained.
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
There are systems I’ve built in the past with 20+ Cassandra nodes and tens of thousands of ops that were originally built on MySQL/Postgresql but migrated to Cassandra because the performance/cost of the SQL systems was just to high.
Now those performance requirements can be handled cheaply with 1 or 2 beefy PostgreSQL databases. The level of scale you need today to make put up with something like Cassandra is much higher while yesteryear it felt like every startup was falling over once they found pmf
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.
I think it stability was due to the fact of combining great technologies like LevelDB and Erlang. I wish it was a bit more popular.
I remember evaluating Riak back in 2011 or so for an analytics solution, but ended up going with a more traditional OLAP database that was a much better option.
It's hard for me to imagine where Riak would be a good option given how many choices we have today for various data stores.
For example, the UK NHS Spine messaging system which has been building on Riak for 10 years
https://riak.com/posts/press/nhs-launches-upgraded-it-backbo...
Here are a few off the top of my head:
- the biggest online betting company in the world
- one of Japan's largest e-commerce sites
- a large Hungarian bank
- one of China's largest electronic manufacturers
- arguably Asia's largest or second largest messaging platform
- a significant Indian online-documentation provider
- one of the largest US insurance providers
- an Australian app analytics provider
- a European telephone services provider
- one of the world's largest travel sites
- an Asian-based credit-card fraud detection service
- a number of start ups in various industries
- me - I do my crypto taxes using a 5 node Riak cluster running on Raspberry Pi's
In the Basho era (up to early 2017), Riak may have only been targetted to larger players but now, when it comes to areas such as in-house data sovereignty, compliance (e.g. GDPR), the flexibility, speed and reliability Riak now provides plus being free to run, people from individuals to corporates are starting to wake up and see the advantages.
(edited in an attempt to improve list formatting)
What are these options you are thinking of?
The only thing that comes to my mind is Aerospike and possibly ScyllaDB.
The focus of the OpenRiak community for the moment is on Riak KV only.
I am tempted to try playing with the entire stack, used to pine for it back in 2011 or so :)