cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Mueller <carl.muel...@smartthings.com.INVALID>
Subject Re: Released an ACID-compliant transaction library on top of Cassandra
Date Wed, 16 Jan 2019 20:51:06 GMT
"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
>
>

Mime
View raw message