Кассандра - поиск по кластерному ключу - PullRequest
Новая
       6

Кассандра - поиск по кластерному ключу

0 голосов
/ 08 октября 2018

Это мое определение таблицы diseases: 

id text,
drugid text,
name
PRIMARY KEY (drugid, id)

Теперь я хочу выполнить поиск только по столбцу drugid (все значения в этом столбце уникальны).Этот первичный ключ был создан из-за быстрого поиска лекарств.

Теперь - что будет лучшим решением для фильтрации этой таблицы, используя id?Создание новой таблицы?Передать дополнительное значение (drugid) SELECT?Это вариант только с id?

Спасибо за помощь :)

1 Ответ

0 голосов
/ 08 октября 2018

Глядя на определение вашей таблицы, ключ раздела является drugid.Это означает, что ваши запросы должны включать лекарственное средство.Но так как id также является частью первичного ключа, вы можете сделать что-то вроде:

select * from diseases where drugid = ? and id = ?

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

Итак, решения:

  • укажите ключ раздела (если возможно), в данном случае drugid
  • создайте новую таблицу, в которой идентификатор будет использоваться в качестве ключа раздела;в этом случае вам нужно будет поддерживать обе таблицы;

Полагаю, решение, которое вы выберете, зависит от вашего набора данных.Вы должны проверить, как каждое решение ведет себя.

Следует ли использовать вторичный индекс?

При указании ключа раздела Cassandra будет считывать точные данные из раздела.и только с одного узла.

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

В вышеприведенной статье есть интересный комментарий @doanduyhai:

"Существует только 1 случай, когда вторичный индекс может работать очень хорошо и НЕ страдает от проблемы масштабируемости: при использовании вместе с ключом PARTITION. Если вы гарантируете, что все ваши запросы, использующие вторичный индекс, будут иметь форму: 

SELECT ... FROM ... WHERE partitionKey=xxx AND my_secondary_index=yyy

тогда вы в безопасности. Лучше в этом случае вы можете смешивать множество вторичных индексов. С точки зрения производительности, так как все чтения индекса будут локальными для узла,все должно быть в порядке "

Я бы держался подальше от вторичных индексов.

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

Кроме того, если id является столбцом кластеризации, данные будут храниться вПо порядку.Столбцы кластеризации определяют порядок сортировки данных на диске только внутри ключа раздела.По умолчанию используется ASC.

. Я бы посоветовал еще кое-что прочитать - Когда не использовать индекс и Использование вторичного индекса

...