Почему у Cassandra нет вторичного индекса?

Cassandra позиционируется как масштабируемая и быстрая база данных. Почему, я имею в виду технические детали, вышеуказанные цели не могут быть достигнуты с помощью вторичных индексов?

Установка Apache Cassandra на Mac OS
Установка Apache Cassandra на Mac OS
Это краткое руководство по установке Apache Cassandra.
1
0
131
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

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

Ранее я написал ответ, в котором обсуждались основные детали запросов вторичного индекса:

Как работают вторичные индексы в Cassandra?

Хотя это должно помочь вам понять, что происходит, этот ответ написан из контекста запроса первый с помощью ключа раздела. Это важное различие, так как при использовании вторичного индекса в пределах раздел должен работать хорошо.

Проблема в том, что при запросе Только по вторичному индексу Cassandra не может гарантировать, что все ваши данные смогут обслуживаться одним узлом. Когда это происходит, Cassandra назначает узел как координатор, который, в свою очередь, запрашивает все остальные узлы для указанных индексированных значений.

По сути, вместо выполнения последовательного чтения с одного узла использование вторичного индекса заставляет Cassandra выполнять произвольное чтение со всех узлов. Теперь у вас есть не только время поиска на диске, но и сетевое время, что усложняет ситуацию.

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

Спасибо за обстоятельный ответ! почему случайные чтения в каждой строке? Мы могли бы иметь вторичный индекс, подобный rdbms, на каждом узле (для каждого раздела). Тогда это будет прямой поиск по вторичному индексу. Не так ли?

voipp 22.05.2019 15:48

Ему не нужно просматривать каждую строку, но необходимо просматривать хранилище индексов на каждом узле. В игру вступает случайность, потому что механизм индексации не уверен, найдет ли он одно, несколько или Любые значений на конкретном узле. Но чтобы быть доскональным, надо смотреть. Основная проблема заключается в неопределенности, связанной с этим. При запросе по ключу раздела Cassandra знает, на каком узле находятся данные, но просто не может отличить их от вторичного индекса.

Aaron 22.05.2019 15:57

Хотел уточнить одну вещь о cassandra: предположим, что у нас есть фактор репликации, равный 2 . Таким образом, некоторый ключ «key1» будет скопирован с первичного узла на вторичный узел (реплика-узел для ключа). Во время операции чтения будут ли запросы балансировки нагрузки cassandra и извлечения key1 как с основного узла, так и с вторичного?

voipp 23.05.2019 16:46

Это зависит от вашего уровня согласованности и доступности узла. Если вы читаете в ONE и все ваши узлы работают, он перейдет к узлу, отвечающему за основной диапазон. Если этот узел не работает, он найдет вторичный. Если вы читаете в QUORUM, он будет читать из обоих, так как QUORUM из 2 равно 2.

Aaron 23.05.2019 16:54

Но он не может выполнять циклические запросы к основному узлу и вторичному узлу.

voipp 23.05.2019 16:56

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

Aaron 23.05.2019 16:58

Так что да, у cassandra есть вторичные индексы, и объяснение Аарона отлично объясняет, почему.

Вы видите, что многие люди пытаются решить эту проблему, записывая свои данные в несколько таблиц. Это делается для того, чтобы они могли быть уверены, что данные, необходимые им для ответа на запрос, который традиционно полагался бы на вторичный индекс, находятся на том же узле.

Некоторые из недавних итераций cassandra имеют это «встроенное» через материализованные представления. Я не использовал их с версии 3.0.11, но они многообещающие. Проблемы, которые у меня были в то время, в основном заключались в добавлении их в таблицы с существующими данными, и они имели удивительно большие накладные расходы на запись (увеличенная задержка).

Другие вопросы по теме