Я проектирую схему для следующего варианта использования:
- Объект, который мы хотим сохранить в БД, содержит 3 атрибута (тип, имя, идентификатор).
- Убедитесь, что комбинация (тип, имя) уникальна.
- Убедитесь, что идентификатор уникален.
- Найдите строку по (типу, имени).
- Найти строку по идентификатору.
- Вывести список всех строк данного типа.
- удалить строку по ее (типу, имени).
- Обновить имя строки.После обновления тип и идентификатор не должны изменяться, а имя должно оставаться уникальным, т. Е. Тип и имя не могут быть обновлены.
- Создать строку по типу, имени и идентификатору.
- Все запросы на создание / получение / список / обновление / удаление могут приходить с разных узлов.В пределах одного и того же узла запрос может поступать от другого сервиса.Количество узлов меньше 1000.
- Количество строк относительно невелико (наихудший случай 12000, обычно намного меньше 1000), и большинство операций - get / list.Производительность чтения не важна.
Я пробовал:
- Мы пробовали PRIMARY KEY (тип, имя).В этом случае функция 8 невозможна, так как имя является частью первичного ключа и, следовательно, не может быть обновлено.
Мы использовали только PRIMARY KEY (тип, ID) или (ID).Кассандра не позволяет накладывать уникальные ограничения на столбцы.
i.Если я читаю, а затем пишу, между двумя операциями могут возникнуть потенциальные проблемы.Функция 10 не выполняется.
ii.Я также смотрел на BATCH-операции, так как он называется атомарным и изолированным на одном разделе.https://docs.datastax.com/en/cql/3.3/cql/cql_using/useBatch.html Однако описание для изоляции «Изоляция гарантирует, что частичная вставка или обновления не будут доступны, пока все операции не будут завершены».отличается от определения изоляции для традиционных БД.Если Cassandra DB блокирует все другие операции чтения / записи, то это хорошо для варианта использования.Если это не так, суть в том, что операция BATCH блокирует все другие операции записи.Может кто-нибудь объяснить фактический уровень изоляции пакетной операции на одном разделе?
Я обнаружил, что поток говорит, что использование MATERIALIZED VIEW может использоваться для обеспечения уникальности вторичного индекса. Можно ли создать уникальный вторичный индекс в Кассандре? .Чтобы убедиться в уникальности (тип, имя), первичным ключом для материализованного представления должен быть (тип, имя), а идентификатор не должен быть его частью.Тогда, если не может быть частью первичного ключа таблицы в соответствии с ограничением: материализованное представление должно «включать все первичные ключи исходной таблицы в первичный ключ материализованного представления».https://docs.datastax.com/en/cql/3.3/cql/cql_using/useCreateMV.html. Однако, если мы хотим поддерживать функцию 8, имя не может быть частью первичного ключа таблицы.Тогда для этого нет решения.
Я хочу найти решение для всех этих функций, но ни один из моих PoC не отвечает всем требованиям.Если у вас есть идеи по обеспечению уникальности, обеспечению изоляции при записи и / или более эффективные решения и мысли, пожалуйста, оставьте это в комментариях.