Кассандра действительно имеет вторичные индексы. Но вторичное использование индекса плохо работает с распределенными базами данных, и это потому, что каждый узел содержит только подмножество всего набора данных.
Ранее я писал ответ, в котором обсуждались основные детали запросов вторичного индекса:
Как работают вторичные индексы в Кассандре?
Хотя это и должно помочь вам понять, что происходит, этот ответ написан из контекста первого запроса по ключу раздела. Это важное различие, поскольку использование вторичного индекса в пределах раздела должно работать хорошо.
Проблема заключается в том, что при запросе только по вторичному индексу Cassandra не может гарантировать, что все ваши данные смогут обслуживаться одним узлом. Когда это происходит, Кассандра назначает узел как координатор , который, в свою очередь, запрашивает все другие узлы на предмет указанных индексированных значений.
По сути, вместо выполнения последовательных чтений с одного узла вторичное использование индекса вынуждает Cassandra выполнять случайные чтения со всех узлов. Теперь у вас есть не только время поиска диска, но и сетевое время, усложняющее ситуацию.
Рекомендация для моделирования Cassandra заключается в дублировании ваших данных в новые таблицы для поддержки желаемого запроса. Это добавляет некоторые другие сложности с синхронизацией данных. Но (если все сделано правильно) это гарантирует, что ваши запросы действительно могут обслуживаться одним узлом. Это компромисс, который вы должны сделать при построении вашей модели. Вы можете иметь удобство или производительность, но не оба.