Yugabyte YCQL проверяет, содержит ли набор значение?

Есть ли способ запросить тип SET (или MAP/LIST), чтобы найти, содержит ли он значение или нет?

Что-то вроде этого:

CREATE TABLE test.table_name(
    id text,
    ckk SET<INT>,
    PRIMARY KEY((id))
);

Select * FROM table_name WHERE id = 1 AND ckk CONTAINS 4;

Есть ли способ выполнить этот запрос с помощью API YCQL?

И можем ли мы использовать тип SET во SECONDRY INDEX?


person Ali Zeinali    schedule 09.02.2020    source источник


Ответы (2)


Есть ли способ выполнить этот запрос с помощью API YCQL?

YCQL пока не поддерживает ключевое слово CONTAINS (не стесняйтесь открывать для этого вопрос на YugabyteDB GitHub< /а>). Одним из обходных путей может быть использование MAP<INT, BOOLEAN> вместо SET<INT> и оператора []. Например:

CREATE TABLE test.table_name(
    id text,
    ckk MAP<int, boolean>,
    PRIMARY KEY((id))
);
SELECT * FROM table_name WHERE id = 'foo' AND ckk[4] = true;

И можем ли мы использовать тип SET во SECONDRY INDEX?

Как правило, типы коллекций не могут быть частью первичного ключа или ключа индекса. Однако «замороженные» коллекции (т. е. коллекции, сериализованные в одно значение внутри) могут фактически быть частью либо первичного ключа, либо ключа индекса.

Например:

CREATE TABLE table2(
    id TEXT,
    ckk FROZEN<SET<INT>>,
    PRIMARY KEY((id))
) WITH transactions = {'enabled' : true};
CREATE INDEX table2_idx on table2(ckk);
person Mihnea Iancu    schedule 10.02.2020
comment
кажется, использование Map<int, boolean> может решить мою проблему. но могу ли я использовать выражение с подпиской на замороженной карте? - person Ali Zeinali; 10.02.2020
comment
Допустим, у меня есть таблица для хранения моих сообщений, и каждое сообщение может иметь некоторый тег (количество тегов ограничено), тогда я хочу искать сообщения, содержащие некоторые теги. Этот запрос наиболее быстрый, поэтому мне нужно создать вторичный индекс для тегов (по тому же ключу раздела, что и post pk) - person Ali Zeinali; 11.02.2020

Другой вариант — использовать составной первичный ключ и определить ckk как ключ кластеризации:

cqlsh> CREATE TABLE ybdemo.tt(id TEXT, ckk INT, PRIMARY KEY ((id), ckk)) WITH CLUSTERING ORDER BY (ckk DESC);
cqlsh> SELECT * FROM ybdemo.tt WHERE id='foo' AND ckk=4;
person dorian YB    schedule 11.02.2020
comment
Это не то, что я ищу. ckk самая большая коллекция. И повторение строки с другим ckk повлияет на производительность записи, чего я действительно не хочу :). - person Ali Zeinali; 11.02.2020
comment
Сколько значений вы собираетесь сохранить в 1 столбце коллекции? - person dorian YB; 12.02.2020
comment
От 1 до 10 - person Ali Zeinali; 13.02.2020
comment
Есть ли в таблице другие столбцы? - person dorian YB; 13.02.2020
comment
Да, это таблица, в которой хранятся сообщения экземпляра приложения для обмена сообщениями. Так что есть и другие столбцы, вероятно, с большими данными, такими как JSONB, TEXT, BLOB и другие. - person Ali Zeinali; 13.02.2020
comment
Я предлагаю создать еще одну таблицу только со столбцом кластеризации (pk, ckk), который также можно индексировать и объединять данные на стороне приложения (во время запроса). Я не думаю, что производительность записи будет сильно отличаться. Это все ключи-значения под docs.yugabyte.com. /latest/architecture/docdb/persistence/ . - person dorian YB; 13.02.2020
comment
Ой! Я этого не знал. Удивительно, как я не видел эту страницу раньше. - person Ali Zeinali; 13.02.2020
comment
Если вы хотите сделать его более сложным: в исходной таблице используйте замороженный набор, выберите весь набор и поддерживайте вторичный индекс вручную. При вставке также поднимите строки ‹cck,id›. То же самое с обновлением + удалением. Это может работать с транзакциями. Это помогает, так что вам не нужно выполнять соединение на стороне приложения при выборе сообщений. - person dorian YB; 15.02.2020