Предположим, что у меня есть семейство столбцов:
CREATE TABLE update_audit (
scopeid bigint,
formid bigint,
time timestamp,
record_link_id bigint,
ipaddress text,
user_zuid bigint,
value text,
PRIMARY KEY ((scopeid, formid), time)
) WITH CLUSTERING ORDER BY (time DESC)
С двумя вторичными индексами, где record_link_id - столбец с высокой производительностью:
CREATE INDEX update_audit_id_idx ON update_audit (record_link_id);
CREATE INDEX update_audit_user_zuid_idx ON update_audit (user_zuid);
Согласно моим знаниям, Cassandra создаст две скрытые семейства столбцов, например:
CREATE TABLE update_audit_id_idx(
record_link_id bigint,
scopeid bigint,
formid bigint,
time timestamp
PRIMARY KEY ((record_link_id), scopeid, formid, time)
);
CREATE TABLE update_audit_user_zuid_idx(
user_zuid bigint,
scopeid bigint,
formid bigint,
time timestamp
PRIMARY KEY ((user_zuid), scopeid, formid, time)
);
Вторичные индексы Cassandra реализуются как локальные индексы, а не распределяются как обычные таблицы. Каждый node хранит только индекс для хранящихся в нем данных.
Рассмотрим следующий запрос:
select * from update_audit where scopeid=35 and formid=78005 and record_link_id=9897;
- Как этот запрос выполнит "под капотом" в Кассандре?
- Как будет влиять на показатель производительности столбца с высокой мощностью (
record_link_id)? - Будет ли Cassandra касаться всех узлов для вышеуказанного запроса? Почему?
- Какие критерии будут выполняться сначала, base table partition_key или вторичный индекс partition_key? Как Кассандра пересечет эти два результата?
