61–70 of 126 posts
I guess I'm old or just not hip (most likely both) but I had to google WAT (I know WTF but WAT ... never seen it). Even now I'm still not sure but I presume WAT = what!
It is a particular form of "what" that is used when dumbstruck.
Cassandra 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.
Some details besides ad-hominem might actually be helpful. When you make statements like this it just looks like trolling.
Anyone has experience around this on HBase, a CP database?
HBase is strictly CP (except for its geo-replication, and optional timeline-consistent region replicas).
It uses MVCC for row "transactions" to always keep rows consistent. HBase also has checkAndPut and checkAndDelete primitives, which are atomic, as well as Increment and Append, which are atomic and serializable.
http://hadoop-hbase.blogspot.com/2012/03/acid-in-hbase.html explains it fairly well.
Together with Apache Phoenix you have full multi-row transactions, but they come with a price obviously.
Earlier quoted context omitted.
Datastax seems to think that it is a good idea: http://www.datastax.com/dev/blog/consensus-on-cassandra
That 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.
This: 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)…
Earlier quoted context omitted.
To be fair, it's easy to suck at Cassandra and most folks that use it used to suck at it.
To be fair, some starups are being trendy and using Cassandra when a traditional SQL database would better fit their needs. One I worked at used a framework designed for SQL, wrote a Cassandra storage backend, didn't denormalize data at all (!) and then (badly) performed JOINs in software because the framework was built around the storage having relational operations (!!) topped off by their backend implementation no…
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…
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.
Earlier quoted context omitted.
Some details besides ad-hominem might actually be helpful. When you make statements like this it just looks like trolling.
Cassandra is not a person, so that was not ad hominem.
Cassandra developer here. Lots of comments here about how Cassandra is AP so of course you get inconsistent (non-serializable) results. This is true, to a point. I'm firmly convinced that AP is a better way to build distributed systems for fault tolerance, performance, and simplicity. But it's incredibly useful to be able to "opt in" to CP for pieces of the application as needed. That's what Cassandra's lightweight t…