ошибка Кассандры при использовании выбора и где в cql

У меня есть таблица cassandra, определенная следующим образом:

CREATE TABLE test.test(
id text,
time bigint,
tag text,
mstatus boolean,
lonumb  int,
PRIMARY KEY (id, time, tag)
)

И я хочу выбрать один столбец, используя select. Я старался:

select * from test where lonumb = 4231;

Это дает:

code=2200 [Invalid query] message="No indexed columns present in by-columns clause with Equal operator"

Также я не могу сделать

select * from test where mstatus = true;

Разве cassandra не поддерживает where как часть CQL? Как это исправить?


cassandra cqlsh cql
person chrisTina    schedule 04.03.2015    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Jny прав в том, что WHERE действителен только для столбцов в PRIMARY KEY или для тех, для которых был создан вторичный индекс. Один из способов решить эту проблему — создать специальную таблицу запросов для lonumb запросов.

CREATE TABLE test.testbylonumb(
  id text,
  time bigint,
  tag text,
  mstatus boolean,
  lonumb  int,
  PRIMARY KEY (lonumb, time, id)
)

Теперь этот запрос будет работать:

select * from testbylonumb where lonumb = 4231;

Он вернет все строки CQL, где lonumb = 4231, отсортированные по time. Я поставил id на ПЕРВИЧНЫЙ КЛЮЧ, чтобы обеспечить уникальность.

select * from test where mstatus = true;

Этот хитрее. Индексы и ключи для маломощных столбцов (например, логических) обычно считаются плохой идеей. Посмотрите, есть ли другой способ смоделировать это. В противном случае вы можете поэкспериментировать со вторичным индексом для mstatus, но использовать его только при указании ключа раздела (в данном случае lonumb), например:

select * from testbylonumb where lonumb = 4231 AND mstatus = true;

Возможно, это будет не так уж плохо, поскольку вы ограничиваете его определенным разделом. Но я бы точно никогда не стал делать SELECT * на mstatus.

person Aaron    schedule 04.03.2015

arrow_upward
3
arrow_downward

Вы можете использовать WHERE только для индексированных или первичных ключевых столбцов. Чтобы исправить вашу проблему, вам нужно создать файл index.

CREATE INDEX iname 
ON keyspacename.tablename(columname)

Дополнительную информацию можно найти здесь.

Но вы должны иметь в виду, что этот запрос должен будет выполняться для всех узлов в кластере.

В качестве альтернативы вы можете переосмыслить структуру своей таблицы, если lonumb — это то, на что вы будете делать больше всего запросов.

person jny    schedule 04.03.2015
comment
Обычно я не фанат вторичных индексов. Но было бы неплохо, если бы в запросе использовался индекс, в котором также были бы указаны ключ(и) секции. +1 - person Aaron; 04.03.2015