Разница между UPDATE и INSERT в Кассандре?

Ответ 1

Столбцы счетчиков в Cassandra не могут быть установлены на произвольное значение: их можно увеличивать или уменьшать только на любое произвольное значение.

По этой причине INSERT не поддерживает колонку счетчика, потому что вы не можете "вставить" значение в столбец-столбец. Вы можете только UPDATE их (увеличивать или уменьшать) на некоторое значение. Здесь вы можете обновить столбец Counter.

    UPDATE ... SET name1 = name1 + <value> 

Вы спросили:

Существует ли "предпочтительный" метод? Или есть случаи, когда нужно использовать друг друга?

Да. Если вы вставляете значения в базу данных, вы можете использовать INSERT. Если столбец не существует, он будет создан для вас. В противном случае эффект INSERT аналогичен UPDATE. INSERT полезен, если у вас нет предустановленной схемы (Dynamic Column Family, т.е. вставить что-нибудь в любое время). Если вы разрабатываете схему перед рукой (Static Column Family, аналогично RDMS) и знаете каждый столбец, вы можете использовать UPDATE.

Ответ 2

Существует тонкая разница. Вставляемые записи через INSERT сохраняются, если вы установите для всех неключевых полей значение null. Записи, вставленные через UPDATE, уходят, если вы установите для всех неключевых полей значение null.

Попробуйте следующее:

CREATE TABLE T (
  pk int,
  f1 int,
  PRIMARY KEY (pk)
);

INSERT INTO T (pk, f1) VALUES (1, 1);
UPDATE T SET f1=2 where pk=2;
SELECT * FROM T;

Возврат:

 pk | f1
----+----
  1 |  1
  2 |  2

Теперь обновите каждую настройку строки f1 до нуля.

UPDATE T SET f1 = null WHERE pk = 1;
UPDATE T SET f1 = null WHERE pk = 2;
SELECT * FROM T;

Обратите внимание, что строка 1 остается, а строка 2 удалена.

 pk | f1
----+------
  1 | null

Если вы посмотрите на них с помощью Cassandra-cli, вы увидите, как добавляются строки.

Я бы точно хотел знать, является ли это по дизайну или ошибке, и посмотрите, как это задокументировано.

Ответ 3

Относительно тонкой разницы, выделенной billbaird (я не могу прокомментировать эту запись напрямую), где строка, созданная операцией обновления, будет удалена, если все неключевые поля имеют значение null:

Это ожидаемое поведение, а не ошибка на основе отчета об ошибке в https://issues.apache.org/jira/browse/CASSANDRA-11805 (который был закрыт как "Не проблема", )

Я столкнулся с этим сам при использовании Spring Data в первый раз. Я использовал метод save(T entity) репозитория, но ни одна строка не создавалась. оказалось, что Spring Data использовал UPDATE, потому что он определил, что объект не был "новым" (не уверен, что тест для "isNew" здесь имеет смысл), и мне довелось тестировать объекты, которые имели заданные поля ключа.

Для этого случая Spring Data, интерфейсы репозитория, специфичные для Cassandra, предоставляют метод insert, который, как представляется, последовательно использует insert, если это поведение желательно вместо этого (хотя документация Spring не документирует эти детали достаточно).

Ответ 4

Еще одна тонкая разница (я начинаю верить, что cql - это ужасный интерфейс для cassandra, полный тонкостей и предостережений из-за использования аналогичного синтаксиса SQL, но немного отличающаяся семантика) заключается в установке TTL на существующие данные. С UPDATE вы не можете обновлять TTL ключей, даже если новые фактические значения равны старым значениям. Решение состоит в том, чтобы вместо INSERT использовать новую строку, а новый TTL уже установил