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
