cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Corless <pe...@scylladb.com>
Subject Re: Released an ACID-compliant transaction library on top of Cassandra
Date Wed, 16 Jan 2019 22:35:32 GMT
Yes, though as your link points out, "The RAMP family is not designed to
provide ACID guarantees - it’s for situations where atomic reads are good
enough. Concurrent writes will typically be handled with last write wins or
CRDTs."

On Wed, Jan 16, 2019 at 1:04 PM Jonathan Haddad <jon@jonhaddad.com> wrote:

> Sounds a bit like RAMP:
> http://rustyrazorblade.com/post/2015/ramp-made-easy/
>
> On Wed, Jan 16, 2019 at 12:51 PM Carl Mueller
> <carl.mueller@smartthings.com.invalid> wrote:
>
>> "2) Overview: In essence, the protocol calls for each data item to
>> maintain the last committed and perhaps also the currently active version,
>> for the data and relevant metadata. Each version is tagged with meta-data
>> pertaining to the transaction that created it. This includes the
>> transaction commit time and transaction identifier that created it,
>> pointing to a globally visible transaction status record (TSR) using a
>> Universal Resource Identifier (URI). The TSR is used by the client to
>> determine which version of the data item to use when reading it, and so
>> that transaction commit can happen just by updating (in one step) the TSR.
>> The transaction identifier, stored in the form of a URI, allows any client
>> regardless of its location to inspect it the TSR in order to determine the
>> transaction commitment state. Using the status of the TSR, any failure can
>> be either rolled forward to the later version, or rolled back to the
>> previous version. The test-andset capability on each item is used to
>> determine a consistent winner when multiple transactions attempt concurrent
>> activity on a conflicting set of items. A global order is put on the
>> records, through a consistent hash of the record identifiers, and used when
>> updating in order to prevent deadlocks. This approach is optimized to
>> permit parallel processing of the commit activity."
>>
>> It seems to be a sort of log-structure/append/change tracking storage
>> where multiple versions of the data to be updated are tracked as
>> transactions are applied to them, and therefore can be rolled back.
>>
>> Probably all active versions are read and then reduced to the final
>> product once all transactions are accounted for.
>>
>> Of course you can't have perpetual transaction changes stored so they
>> must be ... compacted ... at some point?
>>
>> .... which is basically what cassandra does at the node level in the
>> read/write path with LSM, bloom filters, and merging data across disparate
>> sstables...?
>>
>> The devil is in the details of these things of course. Is that about
>> right?
>>
>> On Tue, Nov 13, 2018 at 9:54 AM Ariel Weisberg <ariel@weisberg.ws> wrote:
>>
>>> Hi,
>>>
>>> Fanastic news!
>>>
>>> Ariel
>>>
>>> On Tue, Nov 13, 2018, at 10:36 AM, Hiroyuki Yamada wrote:
>>> > Hi all,
>>> >
>>> > I am happy to release it under Apache 2 license now.
>>> > https://github.com/scalar-labs/scalardb
>>> >
>>> > It passes not only jepsen but also our-built destructive testing.
>>> > For jepsen tests, please check the following.
>>> > https://github.com/scalar-labs/scalardb/tree/master/jepsen/scalardb
>>> >
>>> > Also, as Yuji mentioned the other day, we also fixed/updated jepsen
>>> > tests for C* to make it work with the latest C* version properly and
>>> > follow the new style.
>>> > https://github.com/scalar-labs/jepsen/tree/cassandra
>>> >
>>> > In addition to that, we fixed/updated cassaforte used in the jepsen
>>> > tests for C* to make it work with the latest java driver since
>>> > cassaforte is not really maintained any more.
>>> > https://github.com/scalar-labs/cassaforte/tree/driver-3.0-for-jepsen
>>> >
>>> > We are pleased to be able to contribute to the community by the above
>>> updates.
>>> > Please give us any feedbacks or questions.
>>> >
>>> > Thanks,
>>> > Hiro
>>> >
>>> >
>>> > On Wed, Oct 17, 2018 at 8:52 AM Hiroyuki Yamada <mogwaing@gmail.com>
>>> wrote:
>>> > >
>>> > > Hi all,
>>> > >
>>> > > Thank you for the comments and feedbacks.
>>> > >
>>> > > As Jonathan pointed out, it relies on LWT and uses the protocol
>>> > > proposed in the paper.
>>> > > Please read the design document for more detail.
>>> > > https://github.com/scalar-labs/scalardb/blob/master/docs/design.md
>>> > >
>>> > > Regarding the licensing, we are thinking of releasing it with Apache
>>> 2
>>> > > if lots of developers are interested in it.
>>> > >
>>> > > Best regards,
>>> > > Hiroyuki
>>> > > On Wed, Oct 17, 2018 at 3:13 AM Jonathan Ellis <jbellis@gmail.com>
>>> wrote:
>>> > > >
>>> > > > Which was followed up by
>>> https://www.researchgate.net/profile/Akon_Dey/publication/282156834_Scalable_Distributed_Transactions_across_Heterogeneous_Stores/links/56058b9608ae5e8e3f32b98d.pdf
>>> > > >
>>> > > > On Tue, Oct 16, 2018 at 1:02 PM Jonathan Ellis <jbellis@gmail.com>
>>> wrote:
>>> > > >>
>>> > > >> It looks like it's based on this:
>>> http://www.vldb.org/pvldb/vol6/p1434-dey.pdf
>>> > > >>
>>> > > >> On Tue, Oct 16, 2018 at 11:37 AM Ariel Weisberg <
>>> ariel@weisberg.ws> wrote:
>>> > > >>>
>>> > > >>> Hi,
>>> > > >>>
>>> > > >>> Yes this does sound great. Does this rely on Cassandra's
>>> internal SERIAL consistency and CAS functionality or is that implemented at
>>> a higher level?
>>> > > >>>
>>> > > >>> Regards,
>>> > > >>> Ariel
>>> > > >>>
>>> > > >>> On Tue, Oct 16, 2018, at 12:31 PM, Jeff Jirsa wrote:
>>> > > >>> > This is great!
>>> > > >>> >
>>> > > >>> > --
>>> > > >>> > Jeff Jirsa
>>> > > >>> >
>>> > > >>> >
>>> > > >>> > > On Oct 16, 2018, at 5:47 PM, Hiroyuki Yamada
<
>>> mogwaing@gmail.com> wrote:
>>> > > >>> > >
>>> > > >>> > > Hi all,
>>> > > >>> > >
>>> > > >>> > > # Sorry, I accidentally emailed the following
to dev@, so
>>> re-sending to here.
>>> > > >>> > >
>>> > > >>> > > We have been working on ACID-compliant transaction
library
>>> on top of
>>> > > >>> > > Cassandra called Scalar DB,
>>> > > >>> > > and are pleased to announce the release of v.1.0
RC version
>>> in open source.
>>> > > >>> > >
>>> > > >>> > > https://github.com/scalar-labs/scalardb/
>>> > > >>> > >
>>> > > >>> > > Scalar DB is a library that provides a distributed
storage
>>> abstraction
>>> > > >>> > > and client-coordinated distributed transaction
on the
>>> storage,
>>> > > >>> > > and makes non-ACID distributed database/storage
>>> ACID-compliant.
>>> > > >>> > > And Cassandra is the first supported database
implementation.
>>> > > >>> > >
>>> > > >>> > > It's been internally tested intensively and
is jepsen-passed.
>>> > > >>> > > (see jepsen directory for more detail)
>>> > > >>> > > If you are looking for ACID transaction capability
on top of
>>> cassandra,
>>> > > >>> > > Please take a look and give us a feedback or
contribution.
>>> > > >>> > >
>>> > > >>> > > Best regards,
>>> > > >>> > > Hiroyuki Yamada
>>> > > >>> > >
>>> > > >>> > >
>>> ---------------------------------------------------------------------
>>> > > >>> > > To unsubscribe, e-mail:
>>> user-unsubscribe@cassandra.apache.org
>>> > > >>> > > For additional commands, e-mail:
>>> user-help@cassandra.apache.org
>>> > > >>> > >
>>> > > >>> >
>>> > > >>> >
>>> ---------------------------------------------------------------------
>>> > > >>> > To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
>>> > > >>> > For additional commands, e-mail:
>>> user-help@cassandra.apache.org
>>> > > >>> >
>>> > > >>>
>>> > > >>>
>>> ---------------------------------------------------------------------
>>> > > >>> To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
>>> > > >>> For additional commands, e-mail: user-help@cassandra.apache.org
>>> > > >>>
>>> > > >>
>>> > > >>
>>> > > >> --
>>> > > >> Jonathan Ellis
>>> > > >> co-founder, http://www.datastax.com
>>> > > >> @spyced
>>> > > >
>>> > > >
>>> > > >
>>> > > > --
>>> > > > Jonathan Ellis
>>> > > > co-founder, http://www.datastax.com
>>> > > > @spyced
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
>>> > For additional commands, e-mail: user-help@cassandra.apache.org
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: user-help@cassandra.apache.org
>>>
>>>
>
> --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade
>


-- 
Peter Corless
Technical Marketing Manager
peter@scylladb.com
650-906-3134

Mime
View raw message