Model design and atomic transactions

Amirouche amirouche at
Sat Jul 8 16:38:55 EDT 2017

Thanks for your replies.

Le 07/07/2017 à 01:21, Christopher Meiklejohn a écrit :
> Referring to ACID: ACID is a property of transactions.

You are right.
> Riak doesn't provide any transactional facilities: there's no notion
> of isolation (the 'I' in ACID; a concurrency control mechanism, such
> as serializability), nor the ability to perform multiple updates
> atomically against the database in an all-or-nothing fashion (the 'A'
> in ACID.)
Ok. My application has very low writes number, with low chances
of concurrent writes against the same keys.

That said, there is a backup restore feature, that loads the configuration
of the whole application in one go. I guess that when backup restore is
running the whole database must be locked via REDIS or something. WDYT?
> The closest you can get to having something with similar, but weaker,
> guarantees in Riak, is to use the strong consistency mechanism that
> provides an atomic compare-and-swap for a single register: by reading
> and supplying your read context with your write you can ensure a form
> of isolation (or, concurrency control) by failing write operations
> that have been invalidated by a concurrent writer operating on the
> same register.  These operations are CP, not AP, and will not be
> available if a majority of the cluster is not reachable by the node
> performing the operation.
Are you refering to

> Thanks,
> Christopher
> On Wed, Jul 5, 2017 at 2:55 PM, Fred Dushin <fred at> wrote:
>> Okay, I'll bite, but I don't know if anything I say will be satisfying.

You describe well my understanding of Riak.

>> In general Riak doesn't make any assumptions about ordering of data,
>> particularly around back ends.  While Riak does support levelDB as a back
>> end, and does order keys (and other data, such as secondary indices), until
>> very recently not much leveraged this ordering.  We did a little work in
>> Riak/KV to leverage ordering to optimize bucket and key listing, but that
>> work was never released.  If you are interested, the work is on a few PRs
>> and branches [1]
Actually I don't think I need ordered keys. I understand that this is 
using the Secondary Indices, but AFAIU that feature is deprecated in 
favor of search

>> Riak data is generally schema-less.  Eventually-consistent Key, value, get,
>> put, delete, with some more advanced features around the edges (secondary
>> indexing, CRDTs, semi-structured search),
Another question, when I don't use CDRTs (aka. Riak data types) how does
the application handle reconciliation? Otherwise said, how one does 
it's own data types?

>> as well a "enterprise-level" features, mostly focused around multi-datacenter replication.

I have a question regarding multi datacenter replication. Do all nodes 
must know
each other?

>>    I am sure I
>> am butchering the feature set of Riak, the product.  But at it's core,
>> that's the way I look at it.
That what I understand about Riak without being able to say it.
>> Re: writes during network partitions, yes, of course, this part of the
>> motivation of DynamoDB (not necessarily the product), and Riak faithfully
>> implements the architecture, along with what guarantees can be provided for
>> write availability in the presence of machine|network|software failure.
>> I can't really speak to ACID properties, except to say there is no
>> transactional integrity in Riak, other than some tunable guarantees around
>> reads and writes.
Somehow you must "work around" eventual consistency somehow. I will read 
dynamodb documentation to know more.
>> Can't say much about mnesia, except that Riak can store 100s of terabytes of
>> data across a cluster (if not more).
>> Hope that helps.


>> -Fred
>> [1] and
>> On Jul 4, 2017, at 1:49 PM, Amirouche <amirouche at> wrote:
>> Héllo,
>> At work, we are studying the offering in the distributed database
>> space and my eyes stumbled upon riak (via erlang).
>> I am wondering how does riak compare to leveldb (bsddb, wiredtiger
>> and the like) when it comes down to schema design.
>> Does riak support orderred records based on the key?
>> If the records are ordered, is it possible to change the 'order'
>> function/procedure?
>> Regarding CAP I understand, that Riak is AP which means that some
>> time, some node can see old version the database. During a partition,
>> is it possible to do writes at this point?
>> I don't understand what ACID guarantees riak does provide. What's
>> the position of riak regarding ACID?
>> How do you compare riak and mnesia?
>> Thanks!
>> Amirouche ~
>> _______________________________________________
>> riak-users mailing list
>> riak-users at
>> _______________________________________________
>> riak-users mailing list
>> riak-users at
> _______________________________________________
> riak-users mailing list
> riak-users at

More information about the riak-users mailing list