Why Riak

[martinsumner]

A draft proposal of how I would answer the "Why Riak" question:

Why Riak

Riak is a distributed key-value store, designed to provide high-availability with predictable response times in the presence of complex failure scenarios. It can provide reliable guarantees against data loss, even where individual nodes have ephemeral storage, and groups of nodes can be concurrently impacted by failure events. It is a reliable system whilst running on simple, low-cost, commodity components - remaining highly available without the need for urgent operator intervention.

Riak is commonly used as a schema-free database for the storage and indexing of records, documents, objects or binaries with minimal constraints imposed by the database. In functional terms, Riak can be considered to be a hybrid combination of some of the features available within S3 and DynamoDB.

Riak is targeted at multi-cluster environments, where open replication is possible not just between Riak clusters, but between Riak clusters and other database services. With Riak, reconciliation is considered as important as replication. Clusters may come in different shapes and sizes - but it is important that as well as replicating data between clusters, it is possible to do rapid and continuous verification that clusters remain synchronised.

Riak users have been running large-scale production databases in safety-critical environments on commodity hardware with more than a decade of continuous uptime. These environments are noted not just for their high availability, but for their low operator-intervention rates. Riak is often preferred in organisations where technology choices need to be long-lasting, and ongoing operational costs are a more important consideration than up-front developer costs.

Riak is built almost entirely using BEAM technology, a platform designed from the start to support the next generation of reliable systems. Over the past few years Riak has been evolved to make better use of the BEAM platform, and is now supported on an ongoing basis by a Working Group of the Erlang Ecosystem Foundation.

[Bob-The-Marauder]

Riak is targeted a multi-cluster environments do you mean Riak is targeted at multi-cluster environments?
Also, do we want to continue referring to this as Riak or should we be using OpenRiak instead? For historical references, Riak makes sense. However, going forwards, where do we want to go with this? Use OpenRiak to differentiate the break or merely have OpenRiak as an external nametag whilst continuing to refer to everything as Riak for practical purposes?

[martinsumner]

Corrected a/at.

Don't know on the other question. Obviously in this case I referred to Riak without thinking. Documentation, console commands, logs etc will all refer to Riak. Is OpenRiak an organisation/collaboration producing a version of Riak, rather than a new product in itself?

[tburghart]

An interesting question. I view OpenRiak as a fork of Basho Riak, analogous to the *BSD projects - the same core functionality and commands, but with different implementation priorities and features.
I think we draw the distinction between Riak and OpenRiak in documentation, but continue referring to it as "Riak" since I don't expect to see much if any ongoing development of Basho Riak, with OpenRiak effectively becoming its successor.

[pjaclark]

I'd say use OpenRiak everywhere. We very specifically do not want people to put "Riak" into a search engine as that will point at out-of-date information for a considerable amount of time.

[tburghart]

I think a model like that of OpenJDK makes sense.
Packages are named "OpenRiak," but when installed provide both openriak and riak components, while commands and the runtime service are riak.
The product is referred to as "OpenRiak" throughout, while the service it provides is consistently referred to as "Riak".

[pjaclark]

The current revision is very good from a technical user point of view (and much better than the first draft!).

From a marketing point of view, I think it will be a good source for writing content but this is something I am bad at, so we should probably ask Pau from EEF (their marketing and PR person) for her opinion.

[tburghart]

A couple of points on the text:

• "It can provide reliable guarantees against data loss" should be something like "It provides predictable assurances against data loss" - yes, it's deterministic, but "guarantee" is too strong a term here.

• I think "Riak is targeted at multi-cluster environments" should be toned down to "Riak fully supports multi-cluster environments (within and across physical locations)?" - we don't want people to think you need replication for the system to be useable, or reliable.

• "safety-critical" should be "mission-critical" - the term "safety-critical" has specific meaning in some contexts, and we don't (and don't want to) meet those criteria.

[martinsumner]

I prefer to use "It may be configured to provide deterministic assurance against data loss" - in part to avoid repetition of "predictable", but I think it is the better description, as the assurance against data loss is very dependent on the configuration you use.