выбрать ключи составного типа в cassandra

Итак, я определил семейство столбцов, в котором для ключей строк используются составные идентификаторы. Итак, скажем, составной ключ CompositeType(LongType,LongType). Итак, я протестировал хранение элементов с этим типом, и он отлично работает, и SELECT тоже работает, как и ожидалось, когда я знаю полный ключ. Но скажем, мне нужны все ключи, у которых 0 в качестве первого элемента и что-нибудь в качестве второго. Пока единственный способ, который я вижу для выполнения этого запроса, заключается в следующем:

если бы все ключи были 0:*, то я бы выполнил CQL-запрос для key >= 0:0 AND key < 1:0, который работает до тех пор, пока существует разделитель, сохраняющий порядок.

Мои вопросы:

1) этот странный синтаксис только потому, что я использую драйвер CQL (единственный вариант для nodejs, кроме бережливости)

2) есть ли неэффективность с этим типом запроса? по сути, я использую составной ключ вместо суперстолбцов, поскольку они не поддерживаются в CQL. У меня нет проблем с этой логикой в ​​коде, если нет ограничений на ее использование таким образом.


node.js cassandra cql composite-types
person user1084563    schedule 30.07.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я бы посоветовал вам изменить модель данных. Используйте RandomPartitioner и просто используйте первый компонент в качестве ключа строки. Вставьте второй компонент в имена столбцов, то есть сделайте ваши имена столбцов составными.

Так как имена столбцов всегда отсортированы, вы можете легко выполнять операции нарезки. Например,

а) Когда вы знаете оба компонента, сделайте срез для ключа строки (первый компонент) и первый компонент композита.

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

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

person Mohit    schedule 31.07.2012
comment
Вы правы в том, что это будет работать с точки зрения использования столбцов вместо ключей строк в качестве композитов, хотя есть ли какая-то причина не использовать ключи строк? Я знаю, что сортировка может вызвать проблемы с дисбалансом нагрузки, даже если данные равномерно распределены. но все мои ключи начинаются как минимум с 8 байтов sha1, что должно устранить эту проблему. - person user1084563; 03.08.2012
comment
теперь я помню свои рассуждения здесь. Итак, из того, что вы говорите, я знаю, что могу сделать ключ как LongType, и теперь столбцы могут быть CompositeType (LongType, UTF8Type). Но не теряю ли я теперь возможность объявлять тип значения, если они не все одинаковые? Например, если бы один столбец был длинным значением, а другой был значением utf8, мне теперь нужно просто сказать, что все столбцы являются BytesType, поскольку у меня больше нет статических имен столбцов? и тогда я теряю функциональность кассандры, выполняющей мои преобразования типов для меня, верно? Я что-то упустил здесь? - person user1084563; 03.08.2012
comment
Насколько я понимаю, у вас будет два варианта: хранить как байты, как вы говорите, другой - использовать динамические композиты для хранения значения. DC позволяет вам иметь один компонент с разными типами данных. - person Mohit; 04.08.2012

arrow_upward
0
arrow_downward

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

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

person the paul    schedule 30.07.2012