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 <f...@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 <amirou...@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@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
