It sounds like you're conflating strong consistency with ACID transactions. The strong consistency guarantee with QUORUM writes with Cassandra is only if the write is acknowledged as successful. If you write something successfully, you'll be able to read it. When a write fails the end state is undefined.
The definition of strong consistency does not require a rollback, nor does it define the behavior of the system during a write failure. Strong consistency makes no assertions regarding atomicity (all or nothing) or isolation.
Hi. Presenter here. Honestly the goal wasn't to sound fancy. If you're going to work in the GraphDB world, you're going to come across this terminology.
If your concern around my intro is the complexity described of the relational world, well, that's kind of the point. Anyone with at least a few years experience in the RDBMS world has probably come across a project that's spiraled completely out of control with a outrageous number of many to many relationships that are almost impossible to work with. The role of the DBA just to manage your queries and tables is a reflection of that difficulty.
GUN looks like a cool project. Good intro, & thanks for the feedback.
I didn't think it was overly fancy or confusing at all. I'm not even a particularly techie person and I found the presentation and material to be very palatable. I came away from the video wanting to learn some more about graph databases which I'd say was probably your goal. Very nice job with this!
Sorry for the abrasiveness, I actually liked your overview of table outrage (I should have been positive and mentioned this). What I didn't like is that the article starts right away with mentioning Gremlin - which is very popular within the academic community but difficult for most developers. Honestly anything outside of SQL and MongoDB's query spec can be frightening for devs. Because you are genuinely talking about another language you have to learn. This complexity makes graphs themselves look like they are hard and difficult and for serious people, like machine learning. So I think it is dangerous to introduce people to complicated new query languages in a 101 article because people will feel discouraged that if they can't get past Gremlin then they'll never be able to use graphs at all (despite the fact that they use them all the time, especially on the frontend, without even realizing it). Elsewise I thought you did a good job explaining the problem and even talking about the basics of semantics. Just going down the Gremlin route either scares people off or appeals to the more academic elite.
Gremlin is a practical query language designed for developers and has very little (maybe zero) usage in academia. SparQL is the more established option which does get some academic (and production) usage, particularly as a lot of research on graph databases has a cross over with semantic web research.
This isn't the first time I've seen you criticise the "academic elite". You seem to use it as a crutch, an excuse for sloppy thinking and poor quality software.
I built out a connection pool for the Python redis client for these types of setups where you'd want master / slave failover. It's meant to be paired with something like sentinel or custom failover scripts. https://github.com/StartTheShift/jondis
We just started using Titan in production last week for shift.com, on a 3 node cassandra cluster. We open sourced our Object Graph Mapper library for Python here:
There's a few caveats that come with working with distributed databases, so it's important to know what you're getting into. Neo4j might be easier out of the box (since more people are using it), but if you want a robust solution that'll work for 50 or 50,000 users, Titan feels like the way to go.
The definition of strong consistency does not require a rollback, nor does it define the behavior of the system during a write failure. Strong consistency makes no assertions regarding atomicity (all or nothing) or isolation.