14 ms·
As a long time Cassandra user its easy to forget that some of Cassandra's semantics will be surprising to new users. That being said, if you are considering ado
by helper 10y ago
As a long time Cassandra user its easy to forget that some of Cassandra's semantics will be surprising to new users. That being said, if you are considering adopting an AP database it really is important for you to know the details about how write conflicts get resolved. This is perhaps the biggest difference between Cassandra other databases like Riak and ought to be part of your decision making process instead of a surprise you run into later.
That being said, using Cassandra for distributed locks is a terrible idea. I can't think of any way in which Cassandra would be better than using {Zookeeper,etcd,consul}. Trying to force a database to do something it really isn't designed for will almost always lead to disappointment (and often resentment) of said database.
- chungtg 10y agoDatastax seems to think that it is a good idea: http://www.datastax.com/dev/blog/consensus-on-cassandra http://www.datastax.com/dev/blog/consensus-on-cassandra
- user5994461 10y agoThat piece was written in 2014, which was a different time ;) Plus, if we were to take the vendor words at face value, we'd all be using Docker and MongoDB in production.
- flurdy 10y ago:) My last client (very, very big client) for the past year ran nearly all their production systems with Docker and MongoDb... Never had any problems with Docker. MongoDB on the other hand... Suffice to say it is really fragile when spread across multiple datacentres, which is probably not a surprise to HN.
- djsumdog 10y agoI work for a large company that used docker in production. A lot of companies are. There are a lot of big names using Kubernetes, Mesos or some other container orchestration system.
- ddorian43 10y agoJust like many companies use mongodb and nanoservices.
- pkolaczk 10y agoDetails matter. All updates in the Datastax post are protected by LWT. That code is correct. The OP's code was wrong, because he was mixing non-LWT updates.
- convolvatron 10y agocassandra never claimed to be a consistent distributed database. its really quite sad that someone had to find that out the hard way.
- pkolaczk 10y agoIt is optionally consistent if you know how to use it and you know its limitations. Their use of Cassandra was obviously wrong. Mixing LWT and non-LWT is like having only half of your shared data protected by mutexes - this isn't going to work correctly.
- isoap 10y agoIn such a situation though, shouldn't it raise an error? At least that way, the user could have a chance to recover. Why should it make an arbitrary decision that unknowingly corrupts data for some users?
- hamax 10y agoThe only way for C* to know that it should raise an error is if it would implicitly protect all writes with LWT and this is not what most users want. Following the parent's example, if you don't protect memory access with a lock, you can't know that somebody else locked it.
- prodigal_erik 10y ago"Must be consistent" is a property of the data, not of a particular transaction. Data on which inconsistent transactions are ever allowed should be declared, preferably with big hazard signs.
- pkolaczk 10y agoThe data are not either conistent or inconsistent. The data are either correct or incorrect, and the definition of "correct" is determined by business requirements. Most of the time weak eventual consistency model provided by Cassandra is sufficient to keep data correct if you are using it right. E.g. you don't need ACID and serializable consistency to do financial stuff correctly - banks and accountants figured out how to do this a long time before computers were invented. That's why Cassandra has serializable consistency as an opt-in only (LWTs), but this comes at a price of latency and availability. By using strong consistency all the time, you'd lose most of the benefits of Cassandra, and you could probably just replace it with a single RDBMS node (and suffer scalability and availability problems then).
- AznHisoka 10y agowhat about using redis for distributed locks? (assuming you are not using redis cluster)
- helper 10y agoI personally wouldn't use redis for anything besides a cache.
- fgasparini 10y agoWhy not? It has a WAL persisted to disk at a desired interval. It provides the same durability levels of most databases. http://redis.io/topics/persistence http://redis.io/topics/persistence
- helper 10y agoLet me be clear, I think redis is a well engineered piece of software and I have been constantly impressed with the way antirez runs the project. Specifically for the question of a locking service, I need more availability than what a single node can offer. I'm not sure if you are advocating for using redis cluster as a locking service, but since it intentionally doesn't offer write safety during a partition that does not seem advisable.
- SEJeff 10y agohttps://aphyr.com/posts/283-jepsen-redis https://aphyr.com/posts/283-jepsen-redis
- craz 10y agoYou'll want to use a library that implements Redlock: http://redis.io/topics/distlock http://redis.io/topics/distlock
- SEJeff 10y agoYou really don't want to use redlock: http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html http://martin.kleppmann.com/2016/02/08/how-to-do-distributed... Antirez's rebuttle didn't really rebuke martin's overall theory that redlock is a very bad locking algorithm: http://antirez.com/news/101 http://antirez.com/news/101
- siculars 10y agoSeconded. Don't use an AP system for distributed lock management. As with most things, use the right tool for the right job. When I speak to developers about Riak I tell them the biggest difference between systems like Riak (including Cassandra) and traditional relational systems is not the data model, ie. relational vs non-relations (or structured vs unstructured) but rather the architecture, ie. distributed vs not distributed. As in a "C" system vs a "non-C" system, where "C" is consistency. Disclaimer, I work for Basho, makers of Riak.
- crypto5 10y agoI think you can make Cassandra "C" by using quorum reads and writes. Also they support some SERIAL consistency level, which uses PAXOS underneath, and supposedly achieves consistency as well.
- im_down_w_otp 10y agoQuorum won't solve consistency problems like this unless you can also guarantee a serialized reader/writer for any given piece of data. The best you can do by pinning queries to primary replicas and enforcing R + W > N is RYOW consistency, and that depends on the aforementioned serialization point.
- pkolaczk 10y agoQuorum reads + writes and applying non-destructive updates only are enough to get linearizabile consistency in Cassandra, even if clocks are not perfectly synchronized.
- im_down_w_otp 10y agoIf you're applying non-destructive updates then you don't even need quorum to achieve consistency. You're just writing immutable data.
- 10y ago
- MrBuddyCasino 10y ago> I can't think of any way in which Cassandra would be better than using {Zookeeper,etcd,consul} This is the correct answer. Zookeeper & Curator make it nearly foolproof to implement a distributed lock correctly, whereas with Cassandra, its the other way round.
- PDoyle 10y ago> Zookeeper & Curator make it nearly foolproof to implement a distributed lock correctly, whereas with Cassandra, its the other way round. Cassandra makes it nearly distributed to implement a foolproof lock correctly?
- MrBuddyCasino 10y agoYes, nearly! But not quite.