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 <j...@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.muel...@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 <ar...@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 <mogwa...@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 <jbel...@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 <jbel...@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 < >>> ar...@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 < >>> mogwa...@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-unsubscr...@cassandra.apache.org >>> > > >>> > > For additional commands, e-mail: >>> user-h...@cassandra.apache.org >>> > > >>> > > >>> > > >>> > >>> > > >>> > >>> --------------------------------------------------------------------- >>> > > >>> > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org >>> > > >>> > For additional commands, e-mail: >>> user-h...@cassandra.apache.org >>> > > >>> > >>> > > >>> >>> > > >>> >>> --------------------------------------------------------------------- >>> > > >>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org >>> > > >>> For additional commands, e-mail: user-h...@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-unsubscr...@cassandra.apache.org >>> > For additional commands, e-mail: user-h...@cassandra.apache.org >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: user-h...@cassandra.apache.org >>> >>> > > -- > Jon Haddad > http://www.rustyrazorblade.com > twitter: rustyrazorblade > -- Peter Corless Technical Marketing Manager pe...@scylladb.com 650-906-3134
