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
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 al
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
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?
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?
