Hi Juanjo, For Cassandra to work as a DocumentStore for Oak it needs to be configured with a Quorum high enough to ensure that all writes are sequentially eventually consistent. That might kill Cassandras write performance. RDB backends have this behaviour because they are single instance. MongoDB also as the primary of a shard is a write singleton. I am not 100% certain what will happen if the backend isnt sequentially eventually consistent, but I think individual cluster instances will see a partial sparse view of the current head state, which could feedback when that instance writes back causing an unpredictable final state. Eg, property A gets changed on instance B, instance C sees the same head revision as instance B, but is missing the changes to property A. Instance C writes data based on no changes to A..... or not... depending on the current state of A on C. moments later A would have a different state when its change gets filled in by the non sequentially eventually consistent behaviour of Cassandra.
There might be a way of encoding the revision into the document ID, which could avoid this, but I think that would lead to billions of documents in Cassandra prematurely. I would be interested to hear if you get it to work. HTH Best Regards Ian On 29 March 2017 at 09:48, Chetan Mehrotra <[email protected]> wrote: > Adding to that below are few features I think any new store would have > to support > > 1. Sorted primary key access - For now required to find children of > any parent path > 2. secondary indexes apart from _id field > 3. compare-and-set (CAS) operations for sub fields > > Chetan Mehrotra > > > On Wed, Mar 29, 2017 at 1:59 PM, Marcel Reutegger <[email protected]> > wrote: > > Hi Juanjo, > > > > I don't know Cassandra that well, but I'd say this is feasible. Though, > you > > would probably not implement a NodeStore but a backend for the > > DocumentNodeStore. That is, you need to implement a DocumentStore [0]. > There > > are currently implementations for MongoDB [1] and RDB [2]. > > > > Consistency is indeed important and Oak requires rater strict guarantees. > > > > Regards > > Marcel > > > > [0] > > http://svn.apache.org/repos/asf/jackrabbit/oak/tags/ > jackrabbit-oak-1.6.0/oak-core/src/main/java/org/apache/ > jackrabbit/oak/plugins/document/DocumentStore.java > > [1] > > http://svn.apache.org/repos/asf/jackrabbit/oak/tags/ > jackrabbit-oak-1.6.0/oak-core/src/main/java/org/apache/ > jackrabbit/oak/plugins/document/mongo/MongoDocumentStore.java > > [2] > > http://svn.apache.org/repos/asf/jackrabbit/oak/tags/ > jackrabbit-oak-1.6.0/oak-core/src/main/java/org/apache/ > jackrabbit/oak/plugins/document/rdb/RDBDocumentStore.java > > > > > > On 28/03/17 19:34, Juan José Vázquez Delgado wrote: > >> > >> Hello guys, I'm currently assessing Oak as an alternative for content > >> management on my cloud product. However, I already have a Cassandra > >> cluster > >> as the main persistence technology and to go additionally with Mongo > would > >> turn out in more complexity in terms of manteinance and support. > >> > >> So, have you ever consider Cassandra as an alternative to Mongo for node > >> storing?. I'd be willing to tackle the implementation of such a plugin > but > >> I'd like to know if you find any drawbacks in advance. Perhaps you've > >> already tried it and stumbled across with blocking issues. For instance, > >> I'd be concern with Cassandra's eventual consistency. > >> > >> Thanks in adance for considering this. > >> > >> Regards, > >> > >> Juanjo > >> > > >
