3 ms·

CQL is not SQL. CQL does not even have SQL SELECT. There is no support for arbitrary WHERE clauses, for example. You need to either slice an ordered column, or

CQL is not SQL. CQL does not even have SQL SELECT. There is no support for arbitrary WHERE clauses, for example. You need to either slice an ordered column, or select a row by primary key -- and nothing else! They have an ALLOW FILTERING option which lets you "do it anyway", but this reduces down to paging the whole dataset without the WHERE applied, and then doing client-side filtering. I always felt that CQL did more harm than good for Cassandra. It's not like Redshift -- which implemented a full mostly-Postgres compatibility layer. Cassandra's CQL "looks like" SQL in the same way JavaScript "looks like" Java. Similarity by superficial appearance only; under the hood, totally different.

ma2rten 9y ago
It's not just a subset, but there are also incompatibilities like limit limits the number of rows scanned not the number of rows returned.
stubish 9y ago
I think the opposite, and that CQL is the only reason people still adopt Cassandra today. Remember Thrift, which started by using terms like columns and rows for completely different concepts and went downhill from there? I felt it was a very interesting choice to have CQL only capable of expressing queries that Cassandra could perform quickly. It forced people to adjust their data models immediately, rather than defer the problem until the performance issues got too deep to ignore. Its a different mindset to relational databases, for different sorts of problems. If only they had used the same sort of restraint on other features attempting to make Cassandra do things it is unsuitable for, such as 'transactions' and counters, which are just an embarrassment of problems.
tomnipotent 9y ago
You missed the point - both SQL & CQL are declarative languages. >> CQL does not even have SQL SELECT. https://docs.datastax.com/en/cql/3.1/cql/cql_reference/select_r.html https://docs.datastax.com/en/cql/3.1/cql/cql_reference/selec... This sure looks a lot like SQL SELECT. It returns a projection of data. Beyond that it's just pedantry.
- pixelmonkey 9y ago
  Not supporting WHERE, GROUP BY, all aggregate functions, almost all other "standard" functions, most forms of DISTINCT, ORDER BY (except one order defined at table create time), all forms of sub-select/CTEs, etc. is pedantry? OK. :)

ma2rten 9y ago

It's not just a subset, but there are also incompatibilities like limit limits the number of rows scanned not the number of rows returned.

stubish 9y ago

I think the opposite, and that CQL is the only reason people still adopt Cassandra today. Remember Thrift, which started by using terms like columns and rows for completely different concepts and went downhill from there? I felt it was a very interesting choice to have CQL only capable of expressing queries that Cassandra could perform quickly. It forced people to adjust their data models immediately, rather than defer the problem until the performance issues got too deep to ignore. Its a different mindset to relational databases, for different sorts of problems. If only they had used the same sort of restraint on other features attempting to make Cassandra do things it is unsuitable for, such as 'transactions' and counters, which are just an embarrassment of problems.

tomnipotent 9y ago

You missed the point - both SQL & CQL are declarative languages. >> CQL does not even have SQL SELECT. https://docs.datastax.com/en/cql/3.1/cql/cql_reference/select_r.html https://docs.datastax.com/en/cql/3.1/cql/cql_reference/selec... This sure looks a lot like SQL SELECT. It returns a projection of data. Beyond that it's just pedantry.

pixelmonkey 9y ago
Not supporting WHERE, GROUP BY, all aggregate functions, almost all other "standard" functions, most forms of DISTINCT, ORDER BY (except one order defined at table create time), all forms of sub-select/CTEs, etc. is pedantry? OK. :)