OrientDB consistency characteristics

[Donald Gay]

This is indeed a question about Orient, but first a bit of background...

We have several microservices utilizing Cassandra for persistence. Until now, our use cases have been pretty tolerant of eventual consistency and the BigTable model. However, now we need to model simple relationships between users and userGroups in hierarchies, and certain correctness checks like cycle detection come into play. We can make it work on Cassandra with a few cheats: 

• Store entire graph under a single Cassandra row and use Paxos to force lineralizable consistency
  
• Skip correctness checks on writes, only write mutations, resolve the final state on reads and somehow resolve or handle invalid mutations on read as well.
• Slap Titan in front of Cassandra and be ready to handle invalid states on reads

Essentially, this all fits in well with CAP as I can either kill availability for consistency or vice-versa. If my team were the only one that needed to do this, then we would just deal with it, but we are also tasked with establishing patterns for other teams in the org to use - "figure out the hard stuff first and streamline it for the others".

So I find OrientDB, with multi-master replication AND acid? I've done a little bit of reading on Hazelcast and Orient, but I'm having difficulty sorting out the marketing from the reality.

The question...

Can someone provide a comparison between the consistency characteristics of Cassandra and OrientDB. I have a good grasp on the pitfalls and limitations of Cassandra, but I would like to understand the same for Orient.

Thanks!

[Eric24]

+1

[Luca Garulli]

Hi Donald,

You're right, we'd need more docs about our distributed architecture. Well, talking about Cassandra similarities, we also have a writeQuorum, so if it's the majority (default in v2.2), you always are consistent.

The main difference is that we have the concept of Transaction, in both local and distributed modes. When running distributed, the transactions use a 2 phase lock like protocol, with the cool thing that everything is optimistic, so no locks between the begin and the commit, but everything is executed at commit time only.

During the commit time, OrientDB acquires locks on the touched records and check the version of records (optimistic MVCC approach). At this point this could happen:

1. All the record can be locked and nobody touched the records since the beginning of the tx, so the transaction is committed. Cool.
2. If somebody modified any of the records that are part of the transaction, the transaction fails and the client can retry it
   
3. If at commit time, another transaction locked any of the same records, the transaction fails, but the retry in this case is automatic and configurable
   

If you have 5 servers, and writeQuorum is the majority (N/2+1 = 3), this could happen:

1. All the 5 servers commit the TX: cool
2. 1 or 2 servers report any error, the TX is still committed (quorum passes) and the 1 or 2 servers will be forced to have the same result as the others
3. 3 servers or more have different results/errors, so the tx is rollbacked on all the servers to the initial state

I hope now it's more clear ;-)

Best Regards,

Luca Garulli

Founder & CEO

OrientDB

On 7 May 2016 at 17:31, Eric24 <er...@24x8.com> wrote:

+1

--

---
You received this message because you are subscribed to the Google Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.