Кассандра: выбор ключа раздела

Я не уверен, что лучше, по эффективности, использовать очень частое значение общего столбца (например, Country) в качестве ключа раздела для составного первичного ключа или довольно уникального значения столбца (например, Last_Name).

Глядя на Документация Cassandra 1.2 об индексах Я получаю это:

" Когда использовать индекс: Встроенные индексы Cassandra лучше всего на столе имеющих много строк, которые содержат индексированное значение. Чем уникальнее значения, которые существуют в конкретном столбце, тем больше в среднем, запрашивать и поддерживать индекс. Например, предположим, что у вас была пользовательская таблица с миллиардом пользователей и хотела посмотреть в которых они жили. Многие пользователи будут делиться одним и тем же значение столбца для состояния (например, CA, NY, TX и т.д.). Это было бы хороший кандидат на индекс."

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

Посмотрите на примеры из CQL SELECT для

"Запрос основных первичных ключей и результатов сортировки", я вижу что-то вроде UUID, используемого в качестве ключа раздела... , который указывает, что предпочтительнее использовать что-то уникальное?

Ответ 1

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

ПЕРВИЧНЫЙ КЛЮЧ (ключ разделения, кластеризация key_1... кластеризация key_n)

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

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

cql docs имеют хорошее объяснение того, что происходит.

Ответ 2

если вы используете cql3, учитывая семейство столбцов:

CREATE TABLE table1 (
  a1 text,
  a2 text,
  b1 text,
  b2 text,
  c1 text,
  c2 text,
  PRIMARY KEY ( (a1, a2), b1, b2) )
);

путем определения первичный ключ ((a1, a2,...), b1, b2,...)

Это означает, что:

a1, a2,... - это поля, используемые для создания ключа строки, чтобы:

определить, как данные разбиты на разделы
определить, что физически хранится в одной строке
называется ключом строки или ключом раздела

b1, b2,... представляют собой поля семейства столбцов, используемые для кластеризации ключа строки, чтобы:

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

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

Если вы хотите использовать запросы диапазона, вы можете использовать вторичные индексы или (начиная с cql3), вы можете объявить эти поля как ключи кластеризации. С точки зрения скорости их использования в качестве ключа кластеризации будет создан один широкий ряд. Это влияет на скорость, так как вы получите несколько значений ключа кластеризации, например:

select * from accounts where Country>'Italy' and Country<'Spain'

Ответ 3

Я уверен, что вы получили бы ответ, но все же это может помочь вам лучше понять.

CREATE TABLE table1 (
  a1 text,
  a2 text,
  b1 text,
  b2 text,
  c1 text,
  c2 text,
  PRIMARY KEY ( (a1, a2), b1, b2) )
);

здесь ключи раздела (a1, a2), а строки - b1, b2.

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

указанный выше первичный ключ можно определить следующим образом.

Node< key, value>

Node<(a1a2), Map< b1b2, otherColumnValues>>

поскольку мы знаем, что Разделительный ключ отвечает за распределение данных по вашим узлам.

Итак, если вы вставляете 100 записей в таблицу1 с теми же ключами разделов и разными клавишами строк. он будет хранить данные в том же node, но в разных столбцах.

логически мы можем представить как это.

Node<(a1a2), Map< string1, otherColumnValues>, Map< string2, otherColumnValues> .... Map< string100, otherColumnValues>>

Таким образом, запись будет храниться последовательно в памяти.