Неверный запрос: нет индексированных столбцов в предложении по столбцам с оператором Equal: ошибка CQL?

У меня есть таблица ниже в CQL-

create table test (
    employee_id text,
    employee_name text,
    value text,
    last_modified_date timeuuid,
    primary key (employee_id)
   );

Я вставил пару записей в приведенную выше таблицу, как эта, которую я буду вставлять в наш реальный сценарий использования:

insert into test (employee_id, employee_name, value, last_modified_date) values ('1', 'e27',  'some_value', now());
insert into test (employee_id, employee_name, value, last_modified_date) values ('2', 'e27',  'some_new_value', now());
insert into test (employee_id, employee_name, value, last_modified_date) values ('3', 'e27',  'some_again_value', now());
insert into test (employee_id, employee_name, value, last_modified_date) values ('4', 'e28',  'some_values', now());
insert into test (employee_id, employee_name, value, last_modified_date) values ('5', 'e28',  'some_new_values', now());

Теперь я выполнял запрос на выборку — дайте мне весь employee_id для employee_name e27.

select employee_id from test where employee_name = 'e27';

И это ошибка, которую я получаю -

Bad Request: No indexed columns present in by-columns clause with Equal operator
Perhaps you meant to use CQL 2? Try using the -2 option when starting cqlsh.

Что-то не так, что я здесь делаю?

Мои варианты использования в целом -

  1. Дайте мне все для любого из employee_name?
  2. Дайте мне все, что изменилось за последние 5 минут?
  3. Дайте мне последний employee_id и значение для любого из employee_name?
  4. Дайте мне весь employee_id для любого из employee_name?

У меня Кассандра 1.2.11


person AKIWEB    schedule 03.11.2013    source источник


Ответы (2)


Общее правило простое: «вы можете запрашивать только те столбцы, которые являются частью ключа». В качестве объяснения все другие запросы потребуют полного сканирования таблиц, что может означать много просеивания данных.

Есть вещи, которые могут изменить это правило:

  1. использовать вторичные индексы для столбцов с низким количеством элементов (подробнее здесь)
  2. определить многостолбцовые ключи (например, PRIMARY KEY (col1, col2); что позволит выполнять запросы типа col1 = value1 и col1 = value1 and col2 COND)
  3. используйте ALLOW FILTERING в запросах. Это приведет к предупреждению, так как Cassandra придется просеивать много данных, и производительность не будет гарантирована. Дополнительные сведения см. в подробных сведениях о РАЗРЕШЕНИИ ФИЛЬТРАЦИИ в CQL и этот поток SO
person Alex Popescu    schedule 04.11.2013
comment
Для справки, вы можете создать вторичный ключ с помощью «СОЗДАТЬ ИНДЕКС НА тестах (employee_name);». - person chinglun; 03.09.2014
comment
Ссылка в 1 постоянно достигает 500 - person Squidly; 09.03.2015
comment
Затем он выдает еще одну ошибку о ключе Non PRIMARY. Примечание. В моем примере это столбец с фамилией. { [ResponseError: Фамилия не из PRIMARY KEY найдена в предложении where] имя: 'ResponseError', сообщение: 'Фамилия не из PRIMARY KEY найдена в предложении where', информация: 'Представляет сообщение об ошибке с сервера', код: 8704, запрос: 'UPDATE users SET age = 36 WHERE lastname = \'Jones\'' } - person Adam Mendoza; 10.04.2015

Cassandra нужно немного привыкнуть :) Некоторые из нас были избалованы некоторыми дополнительными вещами, которые RDBMS делает для вас, которые вы не получаете бесплатно от noSql.

Если вы вспомните обычную таблицу СУБД, если вы выберете SELECT для столбца, у которого нет индекса, БД должна выполнить полное сканирование таблицы, чтобы найти все совпадения, которые вы ищете. Это запрещено в Cassandra, и она будет жаловаться, если вы попытаетесь это сделать. Представьте, если бы вы нашли 10^32 соответствия этому запросу? Это не разумная просьба.

В вашей таблице вы закодировали *PRIMARY KEY(employee_id);* это первичный и уникальный ключ идентификации строки. Теперь вы можете ВЫБРАТЬ * из TEST, где employee_id='123'; это вполне разумно, и Cassandra с радостью вернет результат.

Однако ваш SELECT from TEST WHERE employee_name = 'e27'; говорит Cassandra идти и читать КАЖДУЮ запись, пока не будет найдено совпадение с 'e27'. Не имея индекса, на который можно было бы положиться, он вежливо просит вас «забыть об этом».

Если вы хотите отфильтровать столбец, убедитесь, что у вас есть индекс для этого столбца, чтобы Cassandra могла выполнять необходимую фильтрацию.

person hughj    schedule 04.11.2013