I'm not sure though for how much longer it will continue to make sense for the project as-is to continue to roll riak_ensemble forward as part of future releases. As there are no contributors who have direct direct experience or knowledge of using it in production, so it is hard to claim it as being a supported part of the product in any real sense.
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.
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.
The SOLR part has now been retired from the last few releases.
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.
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. 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.
Did you mean 'not remaining in metastable failure' ?
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 :)
What does metastability mean in this context? I've only seen it used to mean "appears stable but not actually stable", eg systems that resist small perturbations but never return to nominal after bigger disturbance (like cold boot).
I'm not aware of any definition of metastability that would be a desirable property of a system. Vaguely speaking, in my understanding metastability in physics, chemistry and electronics refers to a state that has not yet fully settled and the final state is therefore undeterminable / random.
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?
> 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.
The claim relates specifically to the spine 2 project, and is as measured over the 5 years since it went live. There are a lot of systems which depend on Spine 2 for their own availability, it is not the sort of thing that can go down at any time without a lot of people noticing.
I'm biased in that I've been heavily involved in the project, but I will stand by the five years of five nines availability claim.
The focus of the OpenRiak community for the moment is on Riak KV only.