Относительно документации Кассандры (небрежной, все еще запутанной) по ключам, разделам

Question

У меня есть таблица с высокой записью, я переезжаю из Oracle в Кассандру.В Oracle PK является (int: clientId, id: UUID).Есть около 10 миллиардов строк.Я сразу же наткнулся на это бессмысленное предупреждение:

https://docs.datastax.com/en/cql/3.3/cql/cql_using/useWhenIndex.html: «Если вы создадите индекс для столбца с высокой степенью кардинальности, который имеет много различных значений, запрос между полями вызоветмногие ищут очень мало результатов. В таблице с миллиардом песен поиск песен по автору (значение, которое обычно уникально для каждой песни), а не по исполнителю, скорее всего, будет очень неэффективным. Возможно, он будет более эффективным.чтобы вручную поддерживать таблицу как форму индекса, а не использовать встроенный индекс Cassandra. "

Мало того, что это кажется неэффективным при поиске с помощью PK, он не может определить, что это значит для" запроса междуполя "и в чем разница между встроенным индексом, вторичным индексом и подфразами кластеризации primary_key + в команде создания таблицы.Описание барахла.Это 2019. Разве это не должно быть исправлено к настоящему времени?

AFAIK, в любом случае, это вводит в заблуждение:

CREATE TABLE dev.record (
clientid int,
id uuid,
version int,
payload text,
PRIMARY KEY (clientid, id, version)
) WITH CLUSTERING ORDER BY (id ASC, version DESC)

insert into record (id,version,clientid,payload) values
(d5ca94dd-1001-4c51-9854-554256a5b9f9,3,1001,'');
insert into record (id,version,clientid,payload) values
(d5ca94dd-1002-4c51-9854-554256a5b9e5,0,1002,'');

Маркер на клиенте действительно показывает, что они находятся в разных разделах, как и ожидалось.

Обращаясь к большой точке.Если кто-то искал одну строку с заданным clientId, и UUID --- AND --- Cassandra позволил вам пропустить указание clientId, чтобы он не знал, какой узел (ы) искать, то уверен, что поиск может быть медленным,Но это не так:

select * from record where id=
  d5ca94dd-1002-4c51-9854-554256a5b9e5;
InvalidRequest: ... despite the performance unpredictability,
use ALLOW FILTERING"

И то же самое с другими вариациями, которые исключают клиентуру.Так разве мы не должны прийти к выводу, что Кассандра обрабатывает таблицы с высокой кардинальностью, которые прекрасно выдают «очень мало результатов»?

Answer 1

Все, что требует считывания всего контекста базы данных, не будет работать, как в случае со сканированием на id, поскольку любой из ваших ключей clientid может содержать один.Просматривая потенциально тысячи sstables для каждого хоста и проходя каждый раздел каждого из них, чтобы проверить, не будет работать.Если вам трудно работать с моделью данных и не получить полностью различий между ключами разделов и ключами кластеризации, я бы рекомендовал вам пройти некоторые вводные классы (например, академию datastax), видеоролики или книги на youtube перед разработкой схемы.Это не реляционная база данных, и проектирование вокруг ваших данных вместо ваших запросов вызовет у вас проблемы.При переходе от Oracle вы должны , а не , просто скопируйте таблицы и переместите данные, иначе это не будет работать.

Ключ кластеризации - это порядок, в котором данные для разделаупорядочено на диске, что называется «встроенным индексом».У каждого sstable есть индексный компонент, который содержит расположение ключей раздела для этого sstable.Это также включает в себя индекс ключей кластеризации для каждого раздела каждые 64 КБ (по крайней мере по умолчанию), по которым можно искать.Ключи кластеризации, которые существуют между каждой из этих проиндексированных точек, неизвестны, поэтому все они должны быть проверены.Давным-давно был сохранен фильтр Блума для ключей кластеризации, но это был такой редкий случай использования, когда он помог по сравнению с накладными расходами, что он был удален в 2.0.

Вторичные индексы трудно хорошо масштабировать, чтовот откуда приходит предупреждение о количестве элементов, я настоятельно рекомендую просто денормализовать данные и не использовать индекс в какой-либо форме, так как при использовании больших запросов разброса в распределенной системе могут возникнуть проблемы с доступностью и производительностью.Если вам это действительно нужно, проверьте http://www.doanduyhai.com/blog/?p=13191, чтобы попытаться получить правильные данные (на мой взгляд, не стоит).