Почему Кассандра рекомендует не создавать индекс по столбцам с большим количеством элементов?

Документация Кассандры гласит:

Не используйте индекс в следующих ситуациях:

• Для столбцов с большим количеством элементов, потому что вы запрашиваете огромный объем записей для небольшого числа результатов. См. Проблемы с использованием индекса столбца с большим количеством элементов ниже.

Это продолжается,

Если вы создадите индекс для столбца с высокой степенью кардинальности, который имеет много различных значений, запрос между полями повлечет за собой много поисков для очень немногих результатов. В таблице с миллиардом песен поиск песен по автору (значение, которое обычно уникально для каждой песни), а не по исполнителю, скорее всего, будет очень неэффективным. Вероятно, было бы более эффективно поддерживать таблицу как форму индекса вручную, а не использовать встроенный индекс Cassandra. Для столбцов, содержащих уникальные данные, иногда для удобства целесообразно использовать индекс, если объем запросов к таблице, содержащей индексированный столбец, является умеренным и не находится под постоянной нагрузкой.

Но на самом деле никогда не отвечает на вопрос: почему это неэффективно? Я понятия не имею, что означает «ручное ведение таблицы как формы индекса». Но тогда это несколько противоречит самому себе: «… иногда для удобства целесообразно использовать индекс, если объем запросов умеренный…»

Это просто пытается сказать мне, чтобы использовать ПК, когда и где я могу? В чем неэффективность? Насколько я понимаю, запрос, который будет попадать в индекс, должен будет запрашивать каждый узел в кластере, а затем каждый узел будет выполнять поиск в своем локальном индексе, а затем результаты будут агрегироваться. Это не обязательно дорого (каждый поиск индекса должен быть довольно дешевым), за исключением того, что мы платим с задержкой в ​​сети, так как мы должны ждать самого медленного узла в лоте. Я что-то здесь упускаю?

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

_{¹Every? IDK, если репликация означает, что это может поразить 1/3 кластера при коэффициенте репликации 3 или нет?}

С помощью индекса Cassandra ( то есть «вторичного индекса», в отличие от первичных ключей) каждый узел должен запрашивать свои собственные локальные данные для ответа на запрос (см. FAQ по вторичному индексу Cassandra ). Эти индексы также строятся с использованием фонового процесса . Этот фон означает, что индекс может возвращать ложные отрицания с точки зрения попаданий (или ложные срабатывания с точки зрения пропусков).

Это означает, что в столбце с большим количеством элементов скорость изменения ( т.е. добавления / удаления) из этого столбца может быть довольно высокой. И, таким образом, если скорость изменения выше скорости обновления индекса с помощью фонового процесса, то использование индекса «неэффективно» (индекс выполняет больше работы, чем требуется приложению, что часто может дать неправильный ответ) ,

Более эффективный подход с точки зрения точности запроса может состоять в поддержании второй таблицы , а не вторичного индекса. Таблицы, в отличие от индексов , обрабатываются так же, как и любые другие таблицы. Они более вероятно , чтобы дать вашему приложению результаты запроса он ожидает . Недостатком является то, что поддержание таблицы в качестве индекса , в отличие от «вторичного индекса» Cassandra, теперь является ограничением приложения ( т. Е. Код вашего приложения теперь должен знать, чтобы вставлять / удалять строки из этой таблицы «индекса», и синхронизировать две таблицы с помощью «сверки» на уровне приложения).

Надеюсь это поможет!

Некоторая терминология: Родительская таблица - это таблица, для которой создается индекс. Таблица вторичного индекса - это таблица, созданная для ведения индекса другой таблицы.

Данные таблицы вторичного индекса хранятся на том же узле, что и данные родительской таблицы. Разделитель Cassandra не разбивает и не распространяет данные таблицы индекса. Поэтому, если вы хотите выполнить поиск по столбцу индекса, запрашиваются все узлы, а не только узлы реплики, содержащие данные. (узел координатора не знает, где находятся данные) https://www.datastax.com/dev/blog/cassandra-native-secondary-index-deep-dive

Для столбцов с большим количеством элементов, таких как ssn или некоторых других уникальных идентификаторов, будет сопоставление один к одному с первичным ключом. Если вы создаете индекс для такого столбца, данные располагаются по числу факторов репликации узлов, но вызов поиска выполняется на всех узлах. В лучшем случае координатор напрямую обращается к узлам, которые содержат данные, и как только уровень согласованности достигнут, вы получите свой результат. В худшем случае, если искомые данные отсутствуют в индексе, вы ждете, пока все узлы ответят, чтобы обнаружить, что данных там нет. Таким образом, при каждом вызове поиска в таблице вторичного индекса все узлы получают удар. Сравните это только с числом факторов репликации, число узлов которого получено при каждом вызове поиска, если таблица является нормальной таблицей C *.