Hacker News new | ask | show | jobs
by tylerhobbs 4304 days ago
Cassandra isn't designed to replace relational databases for all use cases. There are certain use cases where Cassandra excels, certain use cases where an RDBMS excels, and plenty of ground in between where you're making tradeoffs.

CQL was designed to resemble SQL in order to present an API that is reasonably familiar for most developers. It's quite limited when compared to SQL because it focuses on the areas where Cassandra excels.

(Disclosure: I'm a Cassandra committer.)

2 comments

What was very interesting was bullshitting with somebody who knew a good chunk from DataStax, and realizing that the use cases for Cassandra actually do edge out pretty far into traditional business territory. It's something that you could actually envision replacing mainframes and whatnot in many cases, even for relatively mundane line-of-business applications.
I think they can do it, but I dont think the ROI would cover the investment to change hardware and software for a system that currently works. Unless you are up against an hard EOL for your 'traditional' install I think it would be a large gamble to change. Im speaking for 'traditional' enterprisey install bases only though.
This is true. Most companies either start using Cassandra when their existing database infrastructure is struggling with a particular workload or they're planning a new feature that would be prohibitively difficult or expensive with an RDBMS.

The one exception to this might be a need for higher availability, especially if expanding to multiple datacenters is part of the plan.

Can you elaborate on some specific use cases?
Why are update statements actually inserts? Am I missing something ( besides eventually consistency by design ) or are they trying to trick me?
Because they don't do a read before insert/update/delete, so random inserts don't do random reads/io, but create new versions.

They aren't trying to trick you. Bigtable,hypertable,hbase (i think even tokudb/mx) work the same.