У Cassandra вставки, отличные только от ключа кластера, создают надгробные плиты

Как Cassandra взаимодействует с обновлениями и ключами кластера?

  • Cassandra никогда не обновляет записи после того, как они были записаны, она помечает старую версию как удаленную с помощью надгробной плиты и записывает как старую, так и новую версию до тех пор, пока старая версия в конечном итоге не будет удалена служебным процессом: форма мусора коллекция.
  • Ключи кластера реализуются с использованием некоторой магии, которая записывает данные в «настоящую» запись, имеющую только ключ раздела.

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

Рассмотрим эту схему:

 CREATE TABLE t (
    p int,
    c int,
    d string,
    PRIMARY KEY ((p), c),
 );

После выполнения следующих прошивок:

 INSERT INTO t (p, c, d) VALUE (1, 1, "text-1");
 INSERT INTO t (p, c, d) VALUE (1, 2, "text-2");

есть ли запись с пометкой-надгробием, содержащая данные (1, 1, "text-1"), и новая запись, содержащая как данные (1, 1, "text-1"), так и (1, 2, "text-2")? То есть была ли вторая вставка реализована как обновление «реальной» записи, имеющей ключ раздела (p), равный 1?


cassandra tombstone
person Raedwald    schedule 30.10.2015    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Ваше предположение неверно. В вашей схеме p - это ключ раздела (или «строки»), а c - столбец кластеризации. Cassandra - это столбчатое хранилище, поэтому записи по сути представляют собой набор разреженных упорядоченных столбцов, прикрепленных к разделу. Можно добиться дополнительной вложенности, создав составные ключи строк и имена столбцов, что в вашем случае преобразуется в модель хранения, которая выглядит следующим образом:

Row Key: 1 =>
  1:d => "text-1"
  2:d => "text-2"

Если бы вы вставили другой ключ раздела, например:

INSERT INTO t (p, c, d) VALUE (2, 1, "text-1");

ваша модель хранилища будет выглядеть так:

Row Key: 1 =>
  1:d => "text-1"
  2:d => "text-2" 
Row Key: 2 =>
  1:d => "text-1"

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

DELETE FROM t WHERE p = 1 AND c = 1;

ваш результат будет:

Row Key: 1 =>
  1:d => "text-1" + [tombstone]
  2:d => "text-2" 
Row Key: 2 =>
  1:d => "text-1"

где надгробие будет иметь большую временную метку и, следовательно, "закрывать" исходное значение, пока уплотнение не очистит это. Когда именно это произойдет, зависит от ряда факторов (значение gc_grace_seconds, стратегия уплотнения, рабочая нагрузка и т. Д.).

person rs_atl    schedule 30.10.2015

arrow_upward
0
arrow_downward

Насколько я понимаю, Cassandra не удаляет записи при вставке / обновлении (upsert), она просто записывает новую информацию как запись и не создает надгробие. Когда информация считана, она будет использовать метку времени, чтобы определить, какие данные являются наиболее актуальными. Старые записи удаляются во время сжатия, в то время как надгробия будут существовать до истечения льготного периода (по умолчанию 10 дней), чтобы поддерживать согласованность при удалении и не восстанавливать их.

person Brett Williams    schedule 30.10.2015
comment
Значит, это не надгробие как таковое, но оно все равно приводит к новой и старой версии реальной записи с p = 1? - person Raedwald; 30.10.2015