I'm having some issues wrapping my brain around CQL. I've been attempting to work with column slices (I think that's the right terminology) in CQL3 but all documentation about it seems to refer to CQL2.

For example I have the following table:

CREATE TABLE eventindex (
  key uuid,
  column1 int,
  value uuid,
  PRIMARY KEY (key, column1)
) WITH COMPACT STORAGE

Now, in CQL2 I can do the following:

select '1234567890'..'1234567895' from eventindex;

Which returns all the columns in the range across all rows

Now, in CQL3 I can't do that (at least, not on cqlsh) but I can do:

select value from eventindex WHERE column1 > 1234567890 AND column1 <= 1234567895 allow filtering;

Which gets me essentially the same information but in a slightly different format.

The question is - are these equivalent? The fact that cqlsh warns me about performance issues if I don't add allow filtering says to me that the CQL2 version is more efficient and that my CQL3 query is operating differently, but I've not really been able to find a straight answer confirming my intuition here.

EDIT: The specific thing that makes me concerned is that running the CQL2 query raises no complaints from cqlsh, but running the CQL3 query without "allow filtering" makes cqlsh refuse to execute the query due to concerns about unpredictable performance.

有帮助吗?

解决方案

I think they are essentially the same, although Ive never come across the "allow filtering" command. Im surprised you can actually run that cql at all, without specifying a key. Should it not be something like:

select value from eventindex WHERE key = '<key>' 
AND column1 > 1234567890 AND column1 <= 1234567895

I found this post quite useful for understanding what CQL3 is doing under the hood:

http://www.datastax.com/dev/blog/thrift-to-cql3

其他提示

The allow filtering command is there because your query may result in a large (or at least undetermined) amount of data being read that will not be used in your query.

select value from eventindex WHERE column1 > 1234567890 AND column1 <= 1234567895;

This query will need to read every row - as there is no way to know if a particular row has column1 values in that range without looking at the row. Rows that don't satisfy the WHERE predicate are then filtered out.

Considering how many rows there may be in a large data store, this is understandably not allowed by default. However, in some cases you may know enough about your data to say "this is reasonable, and I want to do it". In that case, you can allow it by using ALLOW FILTERING.

When you use a predicate that specifies the partition key value (e.g. WHERE key = .....), then you wont' get this message, because only the row(s) that satisfy this part of the predicate need to be looked at.

See the following for more details: http://cassandra.apache.org/doc/cql3/CQL.html#selectStmt

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top