Обеспечение уникальности с помощью облегченных транзакций в Cassandra

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

Мой конкретный вариант использования заключается в том, что я хочу обеспечить уникальность определенных полей в INSERT. В документации Cassandra есть следующий пример:

INSERT INTO customer_account (customerID, customer_email) 
VALUES (‘LauraS’, ‘[email protected]’)
IF NOT EXISTS;

В моем конкретном случае у меня есть следующая таблица:

CREATE TABLE IF NOT EXISTS plugins (
    id uuid PRIMARY KEY,
    user_id uuid,
    name text,
    slug text,
    major_version int,
    minor_version int,
    patch_version int
);

Ограничение, которое я хочу применить, заключается в том, что комбинация user_id, slug, major_version, minor_version и patch_version должна быть уникальной. Я не могу просто сделать:

INSERT INTO 
    plugins (
        user_id, 
        slug, 
        major_version, 
        minor_version, 
        patch_version
    ) VALUES (...) IF NOT EXISTS;

Это потому, что мне нужны name и id. Однако включение name и id по-прежнему приведет к тому, что что-то будет записано, потому что IF NOT EXISTS не удастся из-за того, что id будет другим (по крайней мере), и name также может быть другим.

Означает ли это, что мне нужно вести отдельную таблицу, в которой есть только user_id, slug, major_version, minor_version и patch_version? Затем я попытался бы написать в эту таблицу и посмотреть на результат операции. Если запись завершится успешно, я продолжу и заполню все остальные связанные таблицы.

Я знаю, что денормализация — это факт жизни с Кассандрой; Я просто хочу убедиться, что здесь имеет смысл создать эту таблицу только для обработки случая уникальности. Если этот подход не имеет смысла, пожалуйста, предложите другой. Спасибо!


cassandra transactions unique-constraint
person Vivin Paliath    schedule 20.02.2015    source источник

Ответы (1)


arrow_upward
3
arrow_downward

INSERT ... IF NOT EXISTS создает новую строку, если строки с указанным ключом не существует. Он не сравнивает столбец за столбцом, а только ключ. Если вы хотите обеспечить уникальность user_id, slug, major_version, minor_version и patch_version, эти столбцы должны формировать первичный ключ.

person Roman Tumaykin    schedule 21.02.2015
comment
Я понимаю. Значит ли это, что мне понадобится отдельная таблица, которая поддерживает эти поля в качестве первичного ключа? В моей исходной таблице id есть первичный ключ, потому что я часто выполняю поиск по идентификатору. - person Vivin Paliath; 21.02.2015
comment
Прохладно! Это то, что я искал. Я просто хотел знать, имеет ли смысл создавать еще одну таблицу только для обеспечения соблюдения этого ограничения. - person Vivin Paliath; 22.02.2015
comment
Если подумать, все индексы и уникальные ограничения в традиционных реляционных базах данных имеют почти ту же структуру, что и таблицы, и ведут себя почти как таблицы. Они просто используются внутри - person Roman Tumaykin; 22.02.2015