Thanks for the link, will investigate further. On the outset though, it looks as though it's not what we want to be going towards. Also note that it's not open-sourced (other than Solandra which hasn't been updated in aaaages https://github.com/tjake/Solandra).
Rather than build on top of Cassandra, the new NRT + transaction log Solr features really make it more of a possibility to make Solr into a NoSQL-like system and possibly with better transactional guarantees than NoSQL! Speaking to yonik has given me more information on this. Currently, there is an optimistic lock-free mechanism on a per-document basis only as for most, documents only live on a single logical shard. It essentially checks the _version_ you send in for a document against the latest version for the document it has. I propose an additional feature to this for those who want to have such guarantees spanning over multiple documents living on various shards. In my use-case, I have shards holding documents that point to other shards. In this case, an update would need to be an atomic transaction spanning over various documents on various shards. Would anyone object to having this functionality added to Solr if I were to contribute it? Many thanks, Nicholas On Thu, 24 May 2012 08:16:25 -0700, Walter Underwood <wun...@wunderwood.org> wrote: > You should take a look at what DataStax has already done with Solr and > Cassandra. > > http://www.datastax.com/dev/blog/cassandra-with-solr-integration-details > > wunder > > On May 24, 2012, at 7:50 AM, Nicholas Ball wrote: > >> >> Hey all, >> >> I've been working on a SOLR set up with some heavy customization (using >> the adminHandler as a way into the system) for a research project @ >> Imperial College London, however I now see there has been a substantial >> push towards a NoSQL. For this, there needs to be some kind of >> optimistic >> fine-grained concurrency control on updates. As we have document >> versioning >> in-built into Lucene (and therefore Solr) this shouldn't be too >> difficult, >> however the push has been more of a focus on single core optimistic >> LOCKING. >> >> I would like to take this toward a multi-core (and multi-node) >> distributed >> optimistic lock-free mechanism. This is gives us the ability to provide >> stronger guarantees than NoSQL wrt distributed transaction isolation and >> as >> we can now do soft-commits, we can also provide specific version >> rollbacks >> (http://java.dzone.com/articles/exploring-transactional-0). Some more >> interesting reading on this topic: (read-)snapshot isolation >> (http://pages.cs.wisc.edu/~cs764-1/critique.pdf) and even stronger >> guarantees with a slight performance hit with write-snapshot isolation >> (http://www.fever.ch/usbkey_eurosys12/papers/p155-yabandehA.pdf). People >> are starting to realize that we don't have to sacrifice guarantees for >> better performance and scalability (like NoSQL) but rather relax them >> very >> minimally. >> >> What I need is for someone to shed some light on this feature and the >> future plans of Solr wrt this is? Am I correct in thinking that a >> multiversion concurrency control (MVCC) locking mechanism now exist for a >> single core or is it lock-free and multi-core? >> >> Many thanks, >> Nicholas Ball (aka incunix) > > -- > Walter Underwood > wun...@wunderwood.org
