Неверный запрос: индексированные столбцы, присутствующие в предложении by-columns, с помощью оператора 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());

Теперь я делал запрос select - дайте мне все 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.

Есть ли что-то неправильное, что я здесь делаю?

Мои варианты использования в общем случае -

  • Дайте мне все для любого из employee_name?
  • Дайте мне все, что изменилось за последние 5 минут?
  • Дайте мне последний employee_id и значение для любого из имени employee_?
  • Дайте мне все employee_id для любого имени employee_name?

Я запускаю Cassandra 1.2.11

Ответы

Ответ 1

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

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

  • используйте вторичные индексы для столбцов с низкой мощностью (подробнее здесь)
  • определить многоколоночные ключи (например, PRIMARY KEY (col1, col2), что позволит запрашивать такие запросы, как col1 = value1 и col1 = value1 and col2 COND)
  • используйте ALLOW FILTERING в запросах. Это приведет к предупреждению о том, что Cassandra придется просеять много данных и не будет никаких гарантий производительности. Для получения дополнительной информации см. детали ALLOW FILTERING в CQL и этот поток SO

Ответ 2

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

Если вы вернетесь к обычной таблице РСУБД, если вы ВЫБЕРИТЕ в столбце, который не имеет индекса, БД должна выполнить полноэкранное сканирование, чтобы найти все совпадения, которые вы ищете. Это не-нет в Кассандре, и он будет жаловаться, если вы попытаетесь это сделать. Представьте, если вы нашли 10 ^ 32 совпадений с этим запросом? Это не разумный вопрос.

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

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

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