Перейти к основному содержимому

Кассандра замороженная ключевое слово

· 4 мин. чтения

1. Обзор​

В этом руководстве мы поговорим о ключевом слове « заморожено » в базе данных Apache Cassandra . Сначала мы покажем, как объявить замороженные коллекции или определяемые пользователем типы (UDT) . Далее мы обсудим примеры использования и то, как это влияет на основные операции постоянного хранилища.

2. Конфигурация базы данных Cassandra​

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

CREATE KEYSPACE mykeyspace WITH replication = {'class':'SimpleStrategy', 'replication_factor' : 1};

Для этого руководства мы создали пространство ключей только с одной копией данных. Теперь давайте подключим сеанс клиента к пространству ключей :

USE mykeyspace;

3. Замораживание типов коллекций​

Для столбца, тип которого является замороженной коллекцией ( set , map или list ), можно заменить только его значение целиком. Другими словами, мы не можем добавлять, обновлять или удалять отдельные элементы из коллекции, как это возможно в незамороженных типах коллекций. Таким образом, ключевое слово Frozen может быть полезно, например, когда мы хотим защитить коллекции от обновлений с одним значением.

Более того, благодаря заморозке мы можем использовать замороженную коллекцию в качестве первичного ключа в таблице . Мы можем объявлять столбцы коллекций, используя такие типы коллекций, как set , list или map . Затем мы добавляем тип коллекции.

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

CREATE TABLE mykeyspace.users
(
    id         uuid PRIMARY KEY,
    ip_numbers frozen<set<inet>>,
    addresses  frozen<map<text, tuple<text>>>,
    emails     frozen<list<varchar>>,
);

Подставим некоторые данные:

INSERT INTO mykeyspace.users (id, ip_numbers)
VALUES (6ab09bec-e68e-48d9-a5f8-97e6fb4c9b47, {'10.10.11.1', '10.10.10.1', '10.10.12.1'});

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

UPDATE mykeyspace.users
SET ip_numbers = ip_numbers + {'10.10.14.1'}
WHERE id = 6ab09bec-e68e-48d9-a5f8-97e6fb4c9b47;

После выполнения обновления мы получим ошибку:

InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid operation (ip_numbers = ip_numbers + {'10.10.14.1'}) for frozen collection column ip_numbers"

Если мы хотим обновить данные в нашей коллекции, нам нужно обновить всю коллекцию:

UPDATE mykeyspace.users
SET ip_numbers = {'11.10.11.1', '11.10.10.1', '11.10.12.1'}
WHERE id = 6ab09bec-e68e-48d9-a5f8-97e6fb4c9b47;

3.1. Вложенные коллекции​

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

CREATE TABLE mykeyspace.users_score
(
    id    uuid PRIMARY KEY,
    score set<frozen<set<int>>>
);

4. Замораживание пользовательского типа​

Определяемые пользователем типы (UDT) могут присоединять несколько полей данных, каждое из которых именовано и типизировано, к одному столбцу. Поля, используемые для создания определяемых пользователем типов, могут относиться к любому допустимому типу данных, включая коллекцию или другие UDT. Давайте создадим наш UDT:

CREATE TYPE mykeyspace.address (
    city text,
    street text,
    streetNo int,
    zipcode text
);

Давайте посмотрим на объявление замороженного пользовательского типа:

CREATE TABLE mykeyspace.building
(
    id      uuid PRIMARY KEY,
    address frozen<address>
);

Когда мы используем заморозку для определяемого пользователем типа, Cassandra обрабатывает значение как большой двоичный объект. Этот большой двоичный объект получается путем сериализации нашего определяемого пользователем типа в одно значение. Таким образом, мы не можем обновлять части значения пользовательского типа . Мы должны перезаписать все значение.

Во-первых, давайте вставим некоторые данные:

INSERT INTO mykeyspace.building (id, address)
VALUES (6ab09bec-e68e-48d9-a5f8-97e6fb4c9b48,
  {city: 'City', street: 'Street', streetNo: 2,zipcode: '02-212'});

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

UPDATE mykeyspace.building
SET address.city = 'City2'
WHERE id = 6ab09bec-e68e-48d9-a5f8-97e6fb4c9b48;

Мы снова получим ошибку:

InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid operation (address.city = 'City2') for frozen UDT column address"

Итак, давайте обновим все значение:

UPDATE mykeyspace.building
SET address = {city : 'City2', street : 'Street2'}
WHERE id = 6ab09bec-e68e-48d9-a5f8-97e6fb4c9b48;

На этот раз адрес будет обновлен. Поля, не включенные в запрос, заполняются нулевым значением.

5. Кортежи​

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

6. Заключение​

В этом кратком руководстве мы рассмотрели базовую концепцию замораживания компонентов в базе данных Cassandra. Затем мы создали замороженные коллекции и пользовательские типы. Затем мы проверили поведение этих структур данных. После этого мы поговорили о типе данных tuples. Как всегда, полный исходный код статьи доступен на GitHub .