Model design and atomic transactions

Christopher Meiklejohn christopher.meiklejohn at gmail.com
Thu Jul 6 19:21:26 EDT 2017


Referring to ACID: ACID is a property of transactions.

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.)

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.

Thanks,
Christopher

On Wed, Jul 5, 2017 at 2:55 PM, Fred Dushin <fred at dushin.net> wrote:
> Okay, I'll bite, but I don't know if anything I say will be satisfying.
>
> 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]
>
> 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), as well a "enterprise-level"
> features, mostly focused around multi-datacenter replication.  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.
>
> 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.
>
> 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] https://github.com/basho/riak_kv/pull/1634 and
> https://github.com/basho/riak_kv/compare/jv-optimize_list_buckets...develop
>
> On Jul 4, 2017, at 1:49 PM, Amirouche <amirouche at hypermove.net> 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 ~ http://hyperdev.fr
>
>
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
>
>
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>




More information about the riak-users mailing list