Using Cassandra as a lock is a terrible, terrible idea.
Cassandra is not row level consistent
31–40 of 126 posts
Re: Cassandra is not row level consistent
#32Earlier quoted context omitted.
what about using redis for distributed locks? (assuming you are not using redis cluster)
I personally wouldn't use redis for anything besides a cache.
Why not?
It has a WAL persisted to disk at a desired interval. It provides the same durability levels of most databases.
Re: Cassandra is not row level consistent
#33Cassandra is a piece of shit. Negative that comment how you wants, this never change the initial info. I used that BS on a startup on data science on the crawling info level and was on the worst experiences with db I had. CASSANDRA IS JUST PAIN.
Maybe your startup just sucked at Cassandra?
Re: Cassandra is not row level consistent
#34Earlier quoted context omitted.
I personally wouldn't use redis for anything besides a cache.
Why 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
Let 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.
Re: Cassandra is not row level consistent
#35Earlier quoted context omitted.
what about using redis for distributed locks? (assuming you are not using redis cluster)
You'll want to use a library that implements Redlock: http://redis.io/topics/distlock
You really don't want to use redlock: 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
Re: Cassandra is not row level consistent
#36Earlier quoted context omitted.
I personally wouldn't use redis for anything besides a cache.
Why 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
Re: Cassandra is not row level consistent
#37As 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…
Seconded. 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…
I 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.
Re: Cassandra is not row level consistent
#38Cassandra is a piece of shit. Negative that comment how you wants, this never change the initial info. I used that BS on a startup on data science on the crawling info level and was on the worst experiences with db I had. CASSANDRA IS JUST PAIN.
Maybe your startup just sucked at Cassandra?
To be fair, it's easy to suck at Cassandra and most folks that use it used to suck at it.
Re: Cassandra is not row level consistent
#39This:
INSERT INTO locks (id, lock, revision)
VALUES ('Tom', true, 1)
IF NOT EXISTS USING TTL 20;
BEGIN TRANSACTION
SELECT FROM locks WHERE id = "Tom" AND lock = true AND revision = 1;
-- if no records returned
INSERT INTO LOCKS locks (id, lock, revision) VALUES ('Tom', true, 1)
COMMIT
The usual solution in SQL is to use UNIQUE indices which will cause an INSERT to fail if the record about to be inserted already exists.
I ran into this reassembling SMS message fragments, where I wanted to detect that all the parts had come in. The right answer was to do an INSERT for each new fragment, then COMMIT, then do a SELECT to see if all the fragments of a message were in. Doing the SELECT first produced a race condition.
Re: Cassandra is not row level consistent
#40This: INSERT INTO locks (id, lock, revision) VALUES ('Tom', true, 1) IF NOT EXISTS USING TTL 20; looks like a race condition. The same problem comes up in SQL databases - you can't lock a row that doesn't exist yet. If you write, in SQL: BEGIN TRANSACTION SELECT FROM locks WHERE id = "Tom" AND lock = true AND revision = 1; -- if no records returned INSERT INTO LOCKS locks (id, lock, revision) VALUES ('Tom', true, 1)…
Some SQL databases (e.g., SQL Server and PostgreSQL) offer key-range locking which, along with a serializable isolation level, will prevent this race condition.