cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Haddad <...@jonhaddad.com>
Subject Re: Released an ACID-compliant transaction library on top of Cassandra
Date Wed, 16 Jan 2019 20:54:58 GMT
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

Mime
View raw message