Как default_time_to_live удаляет строки без надгробий в Кассандре? - PullRequest
Новая
       31

Как default_time_to_live удаляет строки без надгробий в Кассандре?

0 голосов
/ 11 сентября 2018

С Как удаляются данные?

Cassandra позволяет вам установить свойство default_time_to_live для всей таблицы. Столбцы и строки, помеченные обычными TTL, обрабатываются, как описано выше; но когда запись превышает TTL на уровне таблицы, Cassandra удаляет ее немедленно, без захоронения или уплотнения .

Это также ответ здесь

Если в таблице есть default_time_to_live, то строки, превышающие этот временной предел, удаляются немедленно, без надписей надгробий .

И прокомментировал в посте LastPickle Об удалениях и надгробиях

Еще один ключ к исследованию - использовать TTL в качестве значения по умолчанию, если это хорошо подходит. TTL, установленные на уровне таблицы с параметром default_time_to_live , вообще не должны создавать никаких надгробий в C * 3.0 + . Не проверял на моей руке, но я читал об этом.

Я сделал самый простой тест, который я мог себе представить, используя LeveledCompactionStrategy: 

CREATE KEYSPACE IF NOT EXISTS temp WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'};

CREATE TABLE IF NOT EXISTS temp.test_ttl (
    key text,
    value text,
    PRIMARY KEY (key)
) WITH  compaction = { 'class': 'LeveledCompactionStrategy'}
  AND default_time_to_live = 180;
  1. INSERT INTO temp.test_ttl (key,value) VALUES ('k1','v1');
  2. nodetool flush temp
  3. sstabledump mc-1-big-Data.db enter image description here
  4. ждать 180 секунд (default_time_to_live)
  5. sstabledump mc-1-big-Data.db enter image description here Надгробная плита еще не создана
  6. nodetool compact temp
  7. sstabledump mc-2-big-Data.db enter image description here Надгробная плита создается (и не удаляется при сжатии из-за gc_grace_seconds)

Тест проводился с использованием Apache Cassandra 3.0.13

.

Из примера я заключаю, что неверно, что default_time_to_live не требуют надгробий, по крайней мере для версии 3.0.13. Однако это очень простой тест, и я заставляю его выполнять сжатие nodetool compact, поэтому я, возможно, не буду воссоздавать сценарий, когда в игру вступает магия default_time_to_live.

Но как бы C * удалить без надгробий? Почему это должно отличаться от сценария использования TTL для каждой вставки?

Ответы [ 2 ]

0 голосов
/ 01 октября 2018

Я был одурачен частью документации, которую вы упомянули, отвечая на этот вопрос в нашем блоге ( The Last Pickle Blog ).Я, вероятно, ответил на это слишком быстро, хотя я написал эту вещь «для изучения», даже говоря, что я не пробовал это явно.

Еще один ключ к исследованию будет использовать TTL в качествезначение по умолчанию, если это хорошо подходит.TTL, установленные на уровне таблицы с параметром default_time_to_live , вообще не должны создавать никаких надгробий в C * 3.0 + .Не проверял на моей руке, но я читал об этом.

Так что мое предложение выше неверно.По сути, значение по умолчанию может быть перезаписано TTL на уровне запросов, и я не вижу, как Cassandra могла бы справиться с этим без надгробий.

Из примера, который я прихожу к выводу, неверно, что default_time_to_live не требуют надгробий, по крайней мере, для версии 3.0.13.

Также я радвижу, вы не поверили мне или документации Datastax, но попробовали это самостоятельно.Это, безусловно, правильный подход.

Но как бы C * удалил без надгробий?Почему это должно отличаться от сценария использования TTL для каждой вставки?

Да, именно так,

C * heers.

Ален Родригес - @arodream - alain@thelastpickle.com Франция / Испания

Последний рассол - Apache Cassandra Consulting http://www.thelastpickle.com

0 голосов
/ 12 сентября 2018

AFAIK, нет большой разницы между надгробными записями и записями с истекшим TTL. В вашем случае принудительное сжатие преобразует TTL-запись с истекшим сроком в надгробную плиту, но она не была очищена из-за gc_grace_seconds. Согласно этой презентации , надгробия / ttl-expired-records исчезают:

  • Никогда прежде ему не было gc_grace_seconds
  • Во время уплотнения, для надгробной плиты / ttl, прошедшего gc_grace, ключ ее раздела проверяется по фильтрам Блума всех других SSTable для данной таблицы
  • Если будет столкновение фильтра Блума, надгробная плита останется, даже если столкновение было ложно-положительным.
  • Если в каком-либо SSTable есть какие-либо данные, даже другие надгробные камни для этого раздела, надгробный камень не будет очищен
  • Если фильтры блума показывают, что на этом ключе раздела нет шансов наложения, то надгробная плита очищается.

Таким образом, технически, могильный камень / ttl может исчезнуть после gc_grace, но это не гарантировано.

...