>
> 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.
Do you think that in a first version it would be acceptable to penalize the
>
> 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].
>
Thanks!
>
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
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
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].
Consis
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
